glTF-Blender-IO: Selected object doesn't get exported when its parent is not selected
I work on a scene, and I wanted to export only a specific mesh from it for testing, so I selected the option selected objects in the exporter settings. I noticed that it produced a “corrupt” glb file, which is too small to be valid. The following errors are shown in the validator:
If I select all of the object’s ancestors as well, it gets exported flawlessly. Here’s the test scene, if anyone wants to try: test.zip
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 16 (9 by maintainers)
We’d have to resolve world transforms differently, and that’s going to give very unpredictable results with animation. I’d prefer to say that inclusion of a child implies inclusion of its parents. Maybe if the parent is a mesh, camera, or light, the parent node is written but the referenced mesh/camera/light is not.
My current thinking is this: Most Blender exporters have an “Export Selected” checkbox at the top (including FBX, OBJ, DAE), and ours should be no different. It should filter the export list to just the selected object(s), and preserve the parent/child relations where possible, but still export even if a selected object has un-selected parents (such objects become children of the glTF scene).
I propose this behavior:
When “Export Selected” is
false(un-checked), export all visible objects (more on visibility below).When “Export Selected” is
true, export all objects that are both selected and visible (even if parents are not selected and/or not visible).Visibility in this case is a reference to the eyeball in Blender’s “Outliner” view (the list of objects in the scene). This wasn’t used as much in Blender 2.79, as people mostly used the old layer system there, but visibility has become a big part of the workflow in 2.80. Entire collections can have their visibility toggled with a click, or members of a collection can have visibility toggled per individual object. A major part of the power of collections is not the ability to select them, so much as the ability to toggle visibility and rendering options for a known grouping of objects. Once you get used to collections, you’ll find yourself toggling the visibility of entire collections all the time.
There’s a slight API difference, in Blender 2.79 the API to get visibility was
!bpy.data.objects[n].hide, and in the copy of 2.80 Beta I’ve got, it appears to bebpy.data.objects[n].visible_get().So I propose that the right thing to do now is to always filter by visibility (don’t ask the user, just do it. They turned those objects off for a reason, and they know how to turn them back on). Then, if the user ticks the “selected objects” checkbox, further refine the filter to only include visible selected objects.
I’ve seen this too. And worse, if you place an object inside a collection, and use “only selected”, the selected object won’t export because it has a parent, namely the collection itself.
I think there’s a definite strong use for both. Collections allow for flexibility and persistence to a Blend file. Export selected allows for quick usage and debugging, and doesn’t force people to create collections just for the glTF exporter.