Three.js: GLTFLoader: Scene hierarchy not consistant between Chrome and Firefox.

[pikilipita]

I just found out the order of children in a traverse 'traverse' loop in a (glb file):

object.traverse( function ( child ) {
//to something with child
});

is different on Chrome and on Firefox.

Actually, on Chrome, the order seem to be random ( is different each time the page is refreshed)

Tested with a glb file exported from blender,
on Chrome & Firefox linux and window 10, with three 112

Is this a known issue or is there a work around for this?

using threejs 112 & GLTF loader as of today's version : 2020/02/28

[Mugen87]

Can you please demonstrate this issue with a live example?

Object3D.traverse() executes the callback in a fixed order by traversing the hierarchy top-down. If the order of execution varies, the object hierarchy is actually composed in a different way.

[pikilipita]

here's a live demo ( see in console )
https://lune.live/demos/glb-traverse/

and here are my results: ( Chrome on left, Firefox on right )

differences in ordering starts from object 14th

[Mugen87]

I've checked both parsed glTF scenes in Chrome and Firefox. Like I said before, the object hierarchy is different. Object3D.traverse() works as expected.

It seems GLTFLoader composes the scene differently depending on the used browser.

[pikilipita]

direct link to the file: https://lune.live/demos/glb-traverse/assets/transported_blender_2-8_10_fix.glb

the same hierarchy differences can be reproduced in this gltf viewer:
https://gltf-viewer.donmccurdy.com/

( I've renamed the issue title )

[donmccurdy]

Neat model! 🙂

This seems to be the same issue as https://github.com/mrdoob/three.js/issues/15561. I thought we'd fixed it, but I guess the conversation there went off in another direction... I'm going to close that issue and move the discussion here.

EDIT Oops, no that's GLTFExporter not GLTFLoader. But it might still be related... https://github.com/mrdoob/three.js/pull/15587 was a proposed fix at the time.

[takahirox]

Oh sorry I made PR #15587 including this fix but it had a response time impact and I didn't have time to think how to resolve, and ended up closing the PR so far.

I think it's good to first fix only this issue. IIRC I explained the root issue in #15561, not hard to fix. Please feel free to try.

[pikilipita]

Would you have a time estimation on when the fix will be applied?

[donmccurdy]

No, sorry. You may want to traverse the tree and sort the objects by name in the meantime.

In general, lookups by name would be a more stable way to find particular objects.