GLTFExporter reorders children in groups.

[MykhailoShavlovskyi]

Description of the problem

When exporting a model via GLTFExporter, it reorders children in groups (it places groups first and than meshes). For example if my object children structure is [mesh, mesh, group, mesh], the exported object structure will be [group, mesh, mesh, mesh].

Model before export (download here) has a group somewhere in hierarchy

After the export group is placed in the beginning of hierarchy

This behavior is unwanted, as I'm assigning materials based on child index. Would it be possible to adjust the GLTFExporter so it keeps the original hierarchy, in the way that importing and exporting the same model would result in the exact same data?

Three.js version

• 98

Browser

• All of them
• Chrome
• Firefox
• Internet Explorer

OS

• All of them
• Windows
• macOS
• Linux
• Android
• iOS

[donmccurdy]

I think we can probably fix the ordering inconsistency, but just FYI – you can assign names or mesh.userData.materialName = 'foo' and both should be preserved when you load the model back into three.js. That may be easier and more robust than relying on order in the scene tree.

[takahirox]

I guess this issue isn't in the exporter side but maybe in the loader side.

Three.js child object is added here in the loader.

https://github.com/mrdoob/three.js/blob/dev/examples/js/loaders/GLTFLoader.js#L3335

It's asynchronously done in Promise then the order is inconsistent. I'll look into more later...

[takahirox]

@MykhailoShavlovskyi I think #15587 fixes the issue. Can you please test in your side, too?

[MykhailoShavlovskyi]

@MykhailoShavlovskyi I think #15587 fixes the issue. Can you please test in your side, too?

Thanks, it did fix my issue. Although after loading exported model, objects of type THREE.Group are now of type THREE.Object3D. It makes no difference for me, but could you please explain why it was done like this?

[donmccurdy]

@MykhailoShavlovskyi the glTF format does not have the same Object3D / Group distinction that three.js does. They're just treated as generic empty nodes in the scene graph.

[Popov72]

In current version, nodes that have several children meshes are of type THREE.Group but other nodes that have children which are not meshes are of type THREE.Object3D. Shouldn't we always have the same type of node when a node has children?

Mixing THREE.Object3D and THREE.Group for nodes that have children can be a problem when trying to use the .renderOrder property to control the rendering order of objects.

[donmccurdy]

@Popov72 when THREE.Group is used, the meshes are not children in the glTF file — they’re all part of the same “mesh”. Because threejs doesn’t have multiple geometries per “mesh”, they become children of a group in the loader.

How does that affect .renderOrder? Does THREE.Group not have that? I might not understand the difference between the two...

[Popov72]

@donmccurdy Let's say you have a .gltf scene with one root node (R) and two children. One of these children is a mesh (A) with a single primitive, so ends up being created as a Mesh, whereas the other one (B) has 2 primitives, so is created as a Group (BG) which has 2 meshes as children (one per primitive -B1/B2 ).

Now I would like to render B before A no matter what (B is a skybox in my scene). So I set .renderOrder of A to 2 and .renderOrder of BG/B1/B2 to 1.

But it does not work because A having no Group node in its parent hierarchy gets a .groupOrder equal to 0 when sorting (see the projectObject function in the WebGLRenderer class).

Because .renderOrder of groups are taken into account first when sorting objects (see painterSortStable function), the objects are not sorted correctly.

I could achieve what I want if the root node R was a Group object and not an Object3D, which it is currently and which was my initial comment. If it's a Group, I can set its .renderObject to 2 and gets the correct result (because then A will have its .groupOrder sets to 2 when sorting).

Granted, it's specific to my need, but it made me think that having some nodes being Object3D and not Group when they have children is not really correct in the GLTF loader because as soon as someone tries to use .renderOrder to sort objects, it won't work as expected because inevitably some meshes won't have any Group parent and will end up with a default .groupOrder equal to 0, which will screw up the sorting.

In my case, I just set .isGroup to true on the Object3D root node, but that's not really the way to correct the problem in my opinion.

[EDIT]
Another way to correct the problem is to set the .renderOrder of all Group nodes in the hierarchy to 0 - less a hacky way than the previous one.
[/EDIT]

[mrdoob]

Because threejs doesn’t have multiple geometries per “mesh”, they become children of a group in the loader.

Should we make it so threejs supports multiple geometries per mesh?

[mrdoob]

But if we did that, how would the multiple materials align to multiple geometies? Say...

var mesh = new THREE.Mesh( [ geo1, geo2 ], [ mat1, material2, mat3 ] );

Maybe we can make a THREE.CompoundMesh that supports multiple geometries but only one material?

[donmccurdy]

Hm, I don't know what the intended difference between Group and Object3D is, to say whether GLTFLoader should be using either of them this way. I understand that the problem you're running into would be frustrating. We could switch everything to Group, or everything to Object3D, but I have no idea which is "right." Maybe anything that has children should be a Group?

Should we make it so threejs supports multiple geometries per mesh?

I probably wouldn't make an API change like that just based on glTF – glTF puts hardly any requirements on the relationship between primitives in a single mesh. Some primitives could be points, others could be triangles, and still be part of a single mesh. So treating primitives as children of a single Group has been much easier to reason about.

Somewhat related discussion: KhronosGroup/glTF#1278

[mrdoob]

I don't know what the intended difference between Group and Object3D is

Group is "syntactic sugar" but it helps WebGLRenderer know what to expect and how to handle it:

https://github.com/mrdoob/three.js/blob/dev/src/renderers/WebGLRenderer.js#L1253-L1256

If it is a Object3D, WebGLRenderer has to do (and fail) all the checks:

https://github.com/mrdoob/three.js/blob/dev/src/renderers/WebGLRenderer.js#L1253-L1349