I currently define the class that will contain the vertices and indices and related mesh information like so:



Actually in the real code I have stuff to support cubic mesh extraction as well but that's irrelevant here. I then do this, except this is normally in a function:



And that all compiles fine. In a different section I assign some of the voxels a density, and using getNoOfVertices() and getNoOfIndices(), I know there's about 18 vertices and about 96 indices. But when I use the size() function of the volume[index].meshData.vertices vector, it returns 0. I can guarantee I'm using the correct 'index' variable.

What does getVertices() actually return? Data or a pointer? If it's a pointer, that may be the issue, because my vector is assigned the value/pointer of getVertices() in one function and I call .size() in another. If it is a pointer, how would I handle this?

Also, what is the actual format of the meshes returned? I mean, how many indices per vertex? Or does it not work like that? I don't understand well how mesh formats work exactly.

I know I should probably understand all of this a lot better before I try to use it, but to be honest this is by the best way to learn; that is, by doing.

Clonkex

It's not exactly clear to me what's going on but I'll give you some general points. Firtly you should have a look in 'SurfaceMesh.inl' where you will see that the definition of getVertices() and getNoOfVertices() are very simple:



So getVertices() returns the actual std::vector which holds the vertex data and it should be valid to assign this to another vector (it's probably not necessary though). getNoOfVertices() just calls the std::vector's size() method as you were doing manually.



In this paricular case the format of a vertex is specified in the 'PositionMaterialNormal' and basically consists of floats representing the position, material, and normal. The vertex data is then just an std::vector of these vertices.

The interesting part is then the index buffer, which specifies how these vertices are connected to form triangles. Every group of three entries in the index buffer represents a triangle. Each index is just a number telling you which vertex to use. You should probably read a bit more about index and vertex buffers here:

http://rbwhitaker.wikidot.com/index-and-vertex-buffers
http://msdn.microsoft.com/en-us/library/windows/desktop/bb147325(v=vs.85).aspx

Note that zero if a perfectly valid index (it refers to the first entry in the vertex data).

I'm not sure if the above helps... just ask if it's still not clear. Oh, and have a look at the BasicExample because it might help clarify some of this.

That's what fixed it for me. It had never occurred to me that I could access the necessary directly through getVertices() function, like so:



That drastically simplified things for me and made my code work I still have no idea why it wasn't copying properly but I no longer care



I understood that bit alright. I actually understood more about how meshes are composed than I thought I did. I just confused myself by thinking that the number of indices (in my case, 96) needed to be divisible by the number of vertices (18), but of course it doesn't. There's only a problem if the number of indices isn't divisible by 3.



Ah good, just as I thought. I was hoping it wasn't something weird that was going to make it difficult to integrate with DBPro, but all is well I often struggle to get my head around seemingly simple concepts until someone else (in this case you) explains it, even if they explain in a similar way. My brain sort of freezes up



I'll do that because I really need to understand what I'm working with. Thanks for the links



It did help, thanks

Thank you for helping me over and over again with dumb little things You're the best support-person I could hope for, particularly with free software such as PolyVox

Clonkex

Thanks, I try to help where I can. I'm mostly trying to compensate for the fact that the documentation is still rather lacking