Sorry your browser is not supported!

I'm writing a wrapper for the PolyVox library and it generates the mesh data for me. Someone said the mesh data was the least efficient format, so I was wondering if it's possible to convert the mesh to a different format because DBPro only supports 65,535 vertices or indices (whichever is highest) per mesh (just out of curiosity, is this a common limit or is DBPro showing its age?).

The mesh I'm testing with is generated with 3332 vertices and 19440 indices. Now it seems to me that I should only need 9996 indices when I have 3332 vertices. Is this correct or am I imagining things? If it is correct, how would I go about converting the data (preferably without using DBPro vertexdata commands because I need to modify the mesh data before it's applied to a DBPro mesh)?

Also, what is the most efficient mesh format (like triangle strip or triangle fan or whatever)?

Any help with this would be much appreciated

Clonkex

19440 indices and 3332 means that each vertex is used in ~6 triangles which is perfectly reasonable. If it was the case that each 3 vertices made a triangle there would be no need for indices.

The 65,535 limit for vertices is because DBP uses 16 bit indices. (These are still fairly common although most modern engines will automatically switch to 32 bit indices when necessary for large objects)

I'm not sure why there's a hard limit on indices, are you sure that's correct?

100% sure. I even sent an email to Lee a few hours ago and he replied saying he'd encountered this problem during the Ultimate Coder Challenge. He said he considered updating to support 32bit indices but a lot of things would need changing and he decided not to do it. If it becomes a major issue during development of FPSC-R, he said he'll consider updating again.

Now I'd like to know if there's a way of converting one type of index-vertex arrangement to another.

Clonkex

My point is that 16 bit indices only limit the number of vertices, not the number of indices. (Each index stores the number of a vertex) so any limit DBPro enforces on the number of indices could safely be lifted.

Converting to a triangle fan or strip will not be possible for anything more than specific simple objects as they simply cannot be represented that way. In both cases every triangle in the mesh must share two vertices with the previous triangle, and those vertices must be specific ones, it can't be any two.

You can separate it into multiple objects but it's a little complicated:

- Divide the indices into N blocks making sure you divide on a multiple of 3 so triangles are kept intact.

For each block:
- make a list of all the unique vertices that block references. (Basically add all the index values into an array but excluding duplicates)

- Renumber the indices in that block. Eg. if the index has a value 3, find where 3 is in your array and use the position as the new value for the index.

- Copy all the vertices referenced by the array into a new object. Eg. if array(1) = 3, then copy vertex 3 into a new object as vertex 1.

- Add the previously adjusted indices to this new object.

Now you have a new object for each block. As long as you specified a large enough value for N it should not exceed DBPro's limits.

Nope. The way Lee stores indices must limit the number. I.e., it must be an array of some kind using only a 16bit WORD as the index.

Well, that is, unless IanM made a mistake when creating his Matrix1Utils. I'm using MAKE OBJECT NEW from M1U. Actually I'd like to remove the requirement for M1U as I'm writing a plugin and I want to have the plugin create the meshes itself (with the option for the user to do it as well, of course). How would you create a new mesh with using Matrix1Utils? Memblocks maybe? In that case what is the format I'd use?

EDIT: The plugin I'm creating makes it very easy to simply split the mesh up smaller, but I was hoping to allow fairly large meshes if that's what the user wants. Plus, lots of smaller meshes = more draw calls. It could potentially end up with around 200,000 smaller meshes.

Clonkex