consolidate meshes, based on a list of DBIds

[wallabyway]

Can you add a command line option to take in an array of dbID-groups (or via a separate AEC.json file) and mesh-merge the meshes ?

The problem:
When I convert the 'advanced.rvt' model, it produces 1000+ nodes, which crashes Unity/Blender/gltf-pipeline and renders slowly in 3js / Babylon.js etc.

If this utility could do "mesh-merge" (same as mesh-consolidation), it would reduce the nodes, to fix the gltf-tooling crashes, and render the AEC model faster. I also realize that it means I can no longer pick individual AEC entities (at least, not easily).

[petrbroz]

I guess by saying "merging" instead of "consolidating", the idea is to simply bundle multiple primitives in a single mesh object, is that right? This would help decrease the number of nodes, but the number of meshes and materials would remain the same. Or are you actually asking for consolidation of multiple objects to a single mesh? The tricky part there would be the consolidation of the individual materials.

[wallabyway]

I was thinking mesh merge... similar to https://github.com/zeux/meshoptimizer/blob/3e4dc26c243d7cc2ac349f8d2b06c487ed836531/tools/gltfpack.cpp#L786

based on this: KhronosGroup/glTF#1699 (comment)

[wallabyway]

looks like gltfpack already consolidates by default, based on material shader.

[petrbroz]

I believe it does. Also, if I remember correctly, @zeux mentioned that gltfpack could potentially support other, less aggressive rules for consolidation. If one could consolidate meshes based on properties of gltf nodes (in our case, dbIDs encoded in node names), that would solve this request quite nicely.

[zeux]

Yeah this is perfectly reasonable - I can implement a separate merge mode (right now there are two, "merge everything possible" and "don't touch anything that has a name") that merges meshes between nodes with equivalent names - is that what you mean by "dbIDs encoded in node names"?

[petrbroz]

In the original file format that we're converting to glTF, "dbIDs" are simply numerical IDs of individual selectable elements that can have certain properties (from an external database) attached to them. We're currently storing the dbIDs in node.name.

The idea here was not necessarily to consolidate nodes with equivalent names, but to consolidate nodes with names belonging to specific "consolidation groups", for example, consolidating nodes "123", "124", "125" into one mesh, and nodes "126", "127", "128" into another mesh. That doesn't sound very flexible/reusable, though... Would it perhaps make more sense to merge based on an "extra" property like node.extras.merge_group?

[zeux]

Ok - I see. In this case it's definitely worthwhile specifying this explicitly.

I'm not sure what the best route for this is. Might make sense to open an issue in glTF repository soliciting feedback for the schema specification so that longer term this solution can be implemented in other tools - it's probably fine to use extras for this similar to targetNames but I just want to make sure.

[donmccurdy]

I guess by saying "merging" instead of "consolidating", the idea is to simply bundle multiple primitives in a single mesh object, is that right? This would help decrease the number of nodes, but the number of meshes and materials would remain the same.

Note that while this would reduce JSON size a bit, I'd expect draw calls and runtime performance of N primitives or N meshes to be pretty much the same.

Added a comment about the tagging suggestion in KhronosGroup/glTF#1731.

[wallabyway]

Hi @donmccurdy - The N primitives/meshes are reduced by the Zeux pipeline.

So just focusing on render performance comparison (skip the file size stuff, since that involves discussing compression)... when I say 'merging' or 'consolidating', I'm referring to http://learningthreejs.com/blog/2011/10/05/performance-merging-geometry/

I'll take the gltf file we produce from our SVF->glTF pipeline, we get 1000's of nodes, accessors and meshes for an AEC model. This is to maintain selectable primitives. We feed that gltf into the Zeux compressor pipeline to get a new glb file. By default the Zeux pipeline consolidates by material, reducing draw calls to the number of state changes for material shader switching (roughly). In the end, the glb file has much fewer N primitives/meshes and significant render performance improvement (especially on Safari mobile, chrome/android).

I hope I understood your comment. Please excuse me if I got it wrong.

The file size and decode times, are small and fast for our testing...
example: a single office floor gltf = 50MB. vs zeux.glb.gz = 4.8MB
load time (TTLP) < 3seconds, second load (TTLP) 300ms (three.js hosted on githubpages)

[wallabyway]

glTFpack does mesh merge that reduces draw calls to, typically 2 (maybe 3), for most things converted from our SVF assets.

Currently, when mesh-merge happen, the dbids (nodes) are also merged, losing the ability to associate a node with a dbid.

Thankfully the FEATURE_ID extension proposal, can store the DBID in custom vertices attributes.

https://github.com/CesiumGS/glTF/tree/proposal-EXT_mesh_features/extensions/2.0/Vendor/EXT_mesh_features#feature-id-by-vertex

If glTFPack put the dbids into a custom vertices attribute, during mesh-merge, then we could retrieve the DBID later.

So during a hit-test, we detect the triangle face, it vertices / custom attributes. This containing the FEATURE_ID and our DBID.
Thus we can have the benefits of glTFpack's mesh-merge (2 draw calls, low-node count, compression) as well as extracting the DBID, thus solving for this problem: KhronosGroup/glTF#1699

Closing

[wallabyway]

zeux/meshoptimizer#573 (comment)