Export meshes from Blender to GLTF as Three.Group

Questions
,
1

I have a blend file with a number of meshes, stored in different collections.
I would like to keep that hierarchy when exporting to GLTF, with the collections as THREE.Groups.

I am aware that Collections don’t transfer. When adding an Empty (let’s call it container) and parenting the Meshes to it, the hierarchy stays intact but container is now an Object3D rather than a Group.

It should be possible to export as a Group, as exporting a multimaterial Mesh results in exactly that.

(I need the Meshes to be part of a Group to align with the logic of the app the GLTF is being used in. Using the generic Object3D might result in false positives.)

Is there a way to force a number of Meshes to export as a THREE.Group?

2

Not that I am aware of, no.

Groups are intended to imply grouping, but empties in blender are not implied to be groups… they could be markers or any other utilitarian use.

3

Yes, using Empties was an attempt on my part to force a hierarchy. Which works but not the way we would like :smiley:

4

What is the problem that requires specific hierarchies?
Maybe there is a higher level approach.

If you’re already editing files to introduce hierarchy changes, could you perhaps use a blender “Custom Property” on the object to flag it as special (automatically gets exported into the object.userData of the output) ? Or some kind of naming convention?

5

The use case is that there are multiple meshes that should respond to the same manipulations like scale, pos, etc.

I was thinking along the same lines as well, but was looking for a way to avoid userData in this.

Most models are being delivered by a pool of modellers around the world. It’s a lot easier to brief them on parenting meshes to Empties (or group equivalent) than telling them to manually change the custom properties on all relevant meshes :slight_smile: And if for whatever reason meshes need to be reordered you’d only have to reparent them.
customData in this case is not impossible, it just introduces a larger margin of error when dealing with lots of models and meshes :expressionless:

For now my approach is traversing the Scene, filter out any Object3Ds that is not a Mesh, and keeping everything that has children. While technically not THREE.Groups, they do behave the same in all intents and purposes.

6

Right so the problem here is that GLTF is already using parent/child hierarchies to bridge differences between modelling software (1 mesh + multiple materials) and GLTF (1 mesh = 1 material).

There is an additional constraint with GLTF in that, if it is performing quantization of the vertex format… (converting 4 byte floats to uint16 or some other more optimal datatype) this also requires inserting parent nodes to rescale the model back to it’s original domain… so in that case you will see like:

root = (group)->
    child rescale transform (object3d)->
         child mesh,
    child rescale transform (object3d)->
         child mesh

My gut instinct here is to use some kind of naming convention… like:
theParentObject.name = ‘car_root’
that you can key off of.

1 Like
7

I agree, naming conventions would be best.
Here’s hoping this feature will be added to Blender’s GLTF IO :slight_smile:

1 Like