GLTFLoader: Clean up buildNodeHierarchy

[takahirox]

This PR cleans up buildNodeHierarchy() in GLTFLoader.

Changes

• Move node hierarchy building and Skeleton initialization to .loadNode() from .loadScene(). With this change
  • .getDependency('node', nodeIndex) will return a node (Three.js object) with children underneath.
  • .loadScene() will be much simpler
• Make Three.js object children in the same order as gltf nodeDef.children. Fixes GLTFExporter reorders children in groups. #15561

[donmccurdy]

Any idea why we have the outer IIFE (starting with the return ( function() {... on line 3132? This is nested deeply enough that it's hard to read for me; removing the IIFE might help, or perhaps moving some of the skin-related code into a helper function here.

[takahirox]

Seems like from #15350

[donmccurdy]

.getDependency('node', nodeIndex) will return a node (Three.js object) with children underneath.

I agree that's cleaner, but I do have one concern. If the scene graph looks like this...

scene
  └──mesh1
      └── mesh2
           └── mesh3

... and each mesh has its own textures, are we going to request those textures serially? It looks like the child meshes will not begin loading their textures until the parent mesh has finished. Similar issue if each mesh referenced a different .bin file, but that's uncommon.

Maybe this is uncommon, and meshes usually are children of non-mesh nodes?

[takahirox]

Good point. Let me try to think how to resolve...

[Mugen87]

Any updates on this PR? It seems the concerns of @donmccurdy are not yet addressed, right?

[takahirox]

Yes, you're right. I've been a bit too busy so give me time. Or does this PR block any other PRs?

[Mugen87]

Not that I'm aware of. I just wanted to check the status of this PR 😇 . Sometimes, issues are already solved with different ones...

[mrdoob]

Closing this for now.