THREE.Object3D hierarchy that results from GLTF2Loader can be quite deep. There may be quite a few places where a node can be merged with its parent or even eliminiated. An obvious example is the creation of the
THREE.Group node to represent the glTF
mesh entity, as in e.g.
In many (most?) use cases,
mesh exists only to hold an array of
primitives (and optionally one of associated morph target
THREE.Group will always have the identity transform, so has no influence on its descendants — but because it can have a unique name as well as optional
extension fields, it is not a given that it can always be eliminated.
For the project I’m working on, our team must cope with complex scenes on mobile browsers, with weak CPUs. Any gratutious transform multiplications that can be eliminated from render loops is very valuable to us. Then again, it’s not clear to which degree the user should be able to expect the glTF hierarchy to be mirrored in the resulting scene graph. It seems particularly unpleasant to perform node-collapsing optimization only in some cases (when no optional fields are present) in a loaded model, so that the user has no way of knowing what topology to expect.
I had mentioned the possibility of an optimizing loader option, where the user opts into a mode where they guarantee their
mesh structs will never have unique names, extras or extensions, and thus
THREE.Group can always be eliminated / merged into its parent. But I don’t know if that’s the three.js way.