Mesh welder / combiner

[renanse]

FYI, a simple new utility class and demo went into trunk today that enables you to take a group of Meshes and weld them into a single Mesh. Usage is pretty straightforward for now, just call MeshCombiner.combine and pass it either a Node, or a vararg of Mesh objects, or a Collection of Mesh objects. The resulting Mesh will grab its BoundingVolume type and any local renderstates from the first item in the collection. Have a look at the new com.ardor3d.example.renderer.CombinerExample to see it in action, and to see how much overhead there is drawing 2,500 individual boxes vs a single giant welded one.

Ideas for future enhancements currently include allowing you to pass in an EnumSet of StateType to indicate the states that must be identical in order to perform the merge. In such a case, the result would be a list of Meshes.

[jp.lorandi]

That's awesome, we did something like this (we had a 7x7 set of Boxes) and we saw the boost in performance, great to have it available in this form.

What are your thoughts about supporting instancing? I checked out how JME3 is doing it, and they have separated Mesh from the scenegraph, using a Geometry that extends Spatial that can hold 1..N instances of a mesh.

[renanse]

We have several building blocks already (MeshData, which can be shared and is separate from the scenegraph classes, Transform which is that way as well) and I think we'll see more in the near future as you aren't the first to ask.

[MrCoder]

Yes we already have similar kind of instancing through the Mesh->MeshData which can be shared. That's what you get with the SharedCopyLogic (see MeshDataSharingExample).

A good addition to this is texture atlas creation code, which we also have, but is not packaged up for ardor3d just yet.

[jp.lorandi]

About Mesh -> MeshData... Duh! Sorry I asked.

Interesting, we're using Texture Atlases to minimize memory usage on certain drivers, particulary, embedded Intel graphics, where non-power of two textures weren't allowed. What would we be using the texture atlas for? the same thing, or fancy shader tricks for instancing (like sending mat4 for each instance)?

[MrCoder]

To be able to combine meshes with different textures. i.e the new combined mesh get the atlas texture and it's texturecoords offset to point correctly into it for each old submesh.

[renanse]

A good addition to this is texture atlas creation code, which we also have, but is not packaged up for ardor3d just yet.

Good point! That would make it a ton more useful.

[renanse]

Update: The MeshCombiner now supports merging meshes with multiple sections and index modes (a single MeshData can be broken into multiple parts if that wasn't already common knowledge). It will put together as much as it can into as few sections as possible... for example, all quad and triangle sections can be combined into one section, triangle fans though can not be combined into one call (unless they happen to have the same first vertice... not a common enough case that I bothered to even check though.) Triangle strips are also combined into a single section, adding 2 degenerate triangles between each strip so as to allow them to visually look separated. For fun, I swapped the Boxes in the example out for StripBoxes and you can see a nice speed boost when they're welded into a single big trianglestrip. (tip, for best TPS, try turning off lighting - L and turning on VBO - V)

[thecookie]

Sweet stuff. This should help Spaced with all the non animated props (which is all atm!), which usually is split up in a bunch of different meshes. I just need to upgrade our ardor version and adapt to the new picking system, then I can give it a try.

[oskar]

We are generally a bit torn between the available optimization options. Our world mostly consist of hundreds of copies of identical meshes such as tree trunks, leafs, shrubberies, fences and so on. We think this structure might benefit quite a bit from geometry instancing. Some other places have a small number of unique but large meshes such as our big towns and cave system but I don't think these cause any stress on the system so they shouldn't need any optimization for a good while. ^^

A problem we usually face when talking about optimizations is that they seem to come as a complete strategy rather than small incremental changes. And we don't do things that aren't small incremental changes unless it is critical, urgent and impossible to solve with a more agile tactic.

Some general hints on which types of optimizations might fit our requirement of incremental implementation would be great.

Currently our only known bottlenecks are the number of draw calls (every mesh has its own draw call) and the number of animated characters (didnt start using gpu skinning yet but we should do soon and solve that part).