Gltf-blender-io: Selected object doesn't get exported when its parent is not selected

Created on 26 Dec 2018  Â·  16Comments  Â·  Source: KhronosGroup/glTF-Blender-IO

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:
capture3

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

Mesh_&_Object bug exporter

Most helpful comment

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 be bpy.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.

All 16 comments

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 looked into this. At the moment, the exporter starts with root objects and iterates over them filtering out the stuff that doesn't match selection filters. So if a root object isn't selected, then none of its children will ever be evaluated even if they themselves are selected.

This is also related to my 'Export active collection' issue (https://github.com/KhronosGroup/glTF-Blender-IO/issues/192) which I had to implement in a hacky way.

Basically I think the code needs rearchitecting so that it doesn't start with root nodes and filter out the stuff that's not needed.

  • If 'Selected objects' is checked, then it should retrieve an array of all selected objects in the view.
  • If 'Active collection' is checked then it should retrieve all objects in the active collection. This is done with bpy.context.view_layer.active_layer_collection.collection.all_objects

The downside is that parent-child relationships will need to be rebuilt - because now we have a flat array of objects instead of iterating up the hierarchy.

This is the way the FBX exporter does it, and it seems to be quite well written for 2.80

https://developer.blender.org/diffusion/BA/browse/master/io_scene_fbx/export_fbx_bin.py$3046

I'm happy to help with this but I'm going to need some guidance because this is my first venture into Python and Blender internals.

Per https://github.com/KhronosGroup/glTF-Blender-IO/issues/109 + https://github.com/KhronosGroup/glTF-Blender-IO/issues/192 it sounds like we may want to replace the "export selected" feature with exporting active collections, instead. @emackey does that sound right, or were you thinking we'd have both?

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.

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.

I agree

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 be bpy.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.

Sounds good to me!

I like it - I think this is a great solution.

  • export all objects that are both _selected_ and _visible_ (even if parents are not selected and/or not visible).

I assume this means that if a parent has a child that is selected or visible, the parent is also exported?

I assume this means that if a parent has a child that is selected or visible, the parent is also exported?

I think the hidden parents can be skipped, and the selected children should become children of the glTF scene.

There's a more complex possibility, where a grandparent and grandchild are both selected for export, but there's a de-selected object in between. Not sure what to do with the grandchild there.

I think the hidden parents can be skipped, and the selected children should become children of the glTF scene.

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.

I'm having some issues filtering my export in a good way, i'm not really happy with either the export selected, export visible or export layers solutions. I have a pipeline that exports my scene every time i save the blend file. I save often and want quick feedback on the changes i've made so i don't want to configure the file for export every time i save and i don't want to include all objects in the export.

my options now is to keep all exportable assets in one layer or to make a script select a predefined subset of my scene. The second option however seems to also export all scenes which imo should be its own setting.

With my use case i would like to have the option to only export "renderable" assets. To me it seems like a good analogy that you only export the visible in render rather than whats visible in the viewport. That way the scene can contain variants and references that should be visible but the output is only what would also be visible in the final render.

in short: filter on the "hide_render" property of collections and objects.

Note that there was support for optionally only exporting from layer 0, but it was removed in 1ea67904175854feeebd70cec20d7222f8b4aa97 + 9520626f856ae7390f644c5b6908bb88a760c6f6 — not sure why. Optionally only exporting things with !hide_render seems like a good idea to me and should be simple — not sure what others think. Either way still runs into the issue of what to do when a parent is filtered out but the children aren't.

Either way still runs into the issue of what to do when a parent is filtered out but the children aren't.

I'd suggest replacing the parent with an empty node with the parent name and transformation matrix.

EDIT: Just realised this is the same suggestion as donmccurdys. But yeah I think thats a predictable way to handle it

OK, just wanted to post a bug report, too.
Makes it quite hard to reliably export specific objects, especially as in the current state of Blender 2.80's outliner set to "View Layer" it's impossible to see if an object has parents or not.

Fixed in #1126 (for Blender 2.91)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Quinten123 picture Quinten123  Â·  4Comments

julienduroure picture julienduroure  Â·  5Comments

viperscape picture viperscape  Â·  3Comments

cstfan picture cstfan  Â·  4Comments

rainclaws picture rainclaws  Â·  3Comments