GLTFLoader: Non-deterministic order of children

[epreston]

Description

Recent changes to GLTFLoader no longer loads child objects in an predictable order.

Object hierarchies from GLB files have loaded in predictable order for a few versions. That is no longer the case.

We now need to interrogate the properties of each sub object in an array to correctly assign meshes and bones. Not sure if this should have been the case and I have been relying on undocumented behaviour by assuming consistent indexes and ordering of components in arrays.

Recent optimisations in loading are great but I've lost more cycles interrogating each node in the hierarchy than I've saved.

Reproduction steps

1. load a model with GLTFLoader on r147 with 2 children, mesh and bones
2. assign mesh and skeleton using the predictable indexes of the children, in this case 0 = mesh, 1 = skeleton
3. confirm working correctly
4. upgrade to r148 and load the same object using the updated GLTFLoader
5. note skeleton is now index 0, mesh is index 1 in the children array
6. assign the wrong objects to the wrong values, embrace sadness

Code

// issue
this.armature = {'some object loaded with r148'}
this.mesh = this.armature.children[1];  // indexes are no longer predictable could be 1 or 0
this.skeleton = this.armature.children[0]; // its a 50/50 guess now

// fix 
this.mesh = expensiveTraversalAndChecksForMesh(this.armature.children); 
this.skeleton = expensiveTraversalAndChecksForSkeleton(this.armature.children);

Live example

• i don't have a live example

Screenshots

No response

Version

r148

Device

Desktop

Browser

Chrome

OS

Windows

[epreston]

Maybe its forcing the order in glTF node.children as commented here. #25058 (comment)

There was concern about inconsistent node order, but, it has been consistent on all browsers (win, osx, ios) over (safari, chrome, edge, firefox) since r142 in my project. Consequences would have been very visible in our use base.

[donmccurdy]

It's definitely our intention that the order of children should be deterministic. That said, we can't always guarantee order will be unchanged from one release to the next, so if you're able to use other means to identify things (name, type, .userData, ...) I would strongly recommend that approach.

Looking at the code it's not obvious to me why the order wouldn't be deterministic now, and I can't reproduce the issue in my own tests, so if you're able to share an example (or just a .glb) that would certainly help!

/cc @takahirox

[Mugen87]

Looking at the code it's not obvious to me why the order wouldn't be deterministic now, and I can't reproduce the issue in my own tests

I've also checked the issue and could not produce a non-deterministic behavior with GLTFLoader. Every time I load glTF assets their node hierarchy is the same.

I guess the OP referred to the fact that the node hierarchy has changed between releases. That is true because of the latest changes applied to GLTFLoader. However, these were necessary/reasonable. That said, I don't expect to see changes in the future influencing the node order again. #25058 aligned the order in three.js and glTF so I think that is the behavior we want to retain from now on.

Maybe we should add a note to the migration guide for r148. Something like:

GLTFLoader now ensures the node order in loaded scenes matches the node order in the glTF asset.

[takahirox]

the node hierarchy has changed between releases.

My speculation is this, too. And I think in the latest release the nodes order is deterministic while it didn't in the older releases.

Maybe we should add a note to the migration guide for r148

It sounds good to me.

[epreston]

Yes, it has changed between releases. Between r147 and r148.

It was deterministic since r138 (maybe r136) releases. It may not have been in GLTF file order, or whichever order has been applied as of r148.

[Mugen87]

Okay, I've updated the migration guide. The issue can be closed then.