Alembic export of "Only Selected Objects" with unexpected output #97275

New Issue

Michael Heberlein · 2022-04-12T12:37:21+02:00

Michael Heberlein commented

2022-04-12 12:37:21 +02:00

System Information
Operating system: Windows-10-10.0.19044-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 472.12

Blender Version
Broken: version: 3.1.2, branch: master, commit date: 2022-03-31 17:40, hash: cc66d1020c
Worked: unknown

Short description of error
Exporting an object with animated visibility as Alembic cache with Only Selected Objects checked or unchecked should generate the same caches from my repro scene, but doesn't.
Related task: Looks like the "selected objects" option isn't using the new depsgraph builder from https://developer.blender.org/T75936 ?

Exact steps for others to reproduce the error

load attached file (spinning cube, visibility toggling off at frame 100 and on at 200)
A: export Alembic cache with Only Selected Objects off
B: export Alembic cache with Only Selected Objects on and the cube selected
import into e.g. Houdini and compare:
- cache A is animated until frame 250
- cache B stops at frame 100

blender-vis-selected-abc-houdini.blend

**System Information** Operating system: Windows-10-10.0.19044-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 472.12 **Blender Version** Broken: version: 3.1.2, branch: master, commit date: 2022-03-31 17:40, hash: `cc66d1020c` Worked: unknown **Short description of error** Exporting an object with animated visibility as Alembic cache with `Only Selected Objects` checked or unchecked should generate the same caches from my repro scene, but doesn't. Related task: Looks like the "selected objects" option isn't using the new depsgraph builder from https://developer.blender.org/T75936 ? **Exact steps for others to reproduce the error** - load attached file (spinning cube, visibility toggling off at frame 100 and on at 200) - A: export Alembic cache with `Only Selected Objects` off - B: export Alembic cache with `Only Selected Objects` on and the cube selected - import into e.g. Houdini and compare: - cache A is animated until frame 250 - cache B stops at frame 100 [blender-vis-selected-abc-houdini.blend](https://archive.blender.org/developer/F12997979/blender-vis-selected-abc-houdini.blend) ![blender-vis-selected-abc-houdini.png](https://archive.blender.org/developer/F12997978/blender-vis-selected-abc-houdini.png) ![blender-vis-selected-abc-houdini.gif](https://archive.blender.org/developer/F12997980/blender-vis-selected-abc-houdini.gif)

Michael Heberlein commented

2022-04-12 12:37:21 +02:00

Added subscriber: @Michael-Heberlein

Philipp Oeser commented

2022-04-12 13:13:10 +02:00

Added subscribers: @dr.sybren, @lichtwerk

Philipp Oeser commented

2022-04-12 13:13:10 +02:00

Changed status from 'Needs Triage' to: 'Needs Developer To Reproduce'

Philipp Oeser commented

2022-04-12 13:13:10 +02:00

There is the principle of "invisible can never be selected" in blender, so in that regard, there is some background to this, but I would assume there are better ways to deal with it in the scenario of exporting.
The object not coming back to being selected after returning from being invisible is also an issue in other contexts, so not sure if this will really be considered a bug.

@dr.sybren: what do you think?

There is the principle of "invisible can never be selected" in blender, so in that regard, there is some background to this, but I would assume there are better ways to deal with it in the scenario of exporting. The object not coming back to being selected after returning from being invisible is also an issue in other contexts, so not sure if this will really be considered a bug. @dr.sybren: what do you think?

Michael Heberlein commented

2022-04-12 13:36:51 +02:00

Thanks for your answer, Philipp.
Is there a workaround that we could use in production today?

We're animating in Blender but want to use our existing Houdini lighting/rendering pipeline.
Every character should have their own collection of geometry to be exported as Alembics, including animated object visibilities.

Could we run the export operator in something like "isolated contexts" and keep the "selected objects" option off?

Thanks for your answer, Philipp. Is there a workaround that we could use in production today? We're animating in Blender but want to use our existing Houdini lighting/rendering pipeline. Every character should have their own collection of geometry to be exported as Alembics, including animated object visibilities. Could we run the export operator in something like "isolated contexts" and keep the "selected objects" option off?

Philipp Oeser commented

2022-04-12 14:27:54 +02:00

Alembic export uses DEG_OBJECT_ITER_BEGIN, unsure if there is a way to override context such that only own specified objects are seen there @dr.sybren ?

Own clumsy tries at this failed:

import bpy

override = bpy.context.copy()
override['view_layer.objects'] = list(bpy.context.selected_objects)
override['scene.objects'] = list(bpy.context.selected_objects)

bpy.ops.wm.alembic_export(override, filepath='/tmp/test.abc', start=1, end=1, visible_objects_only=False, selected=False)

Alembic export uses DEG_OBJECT_ITER_BEGIN, unsure if there is a way to override context such that only own specified objects are seen there @dr.sybren ? Own clumsy tries at this failed: ``` import bpy override = bpy.context.copy() override['view_layer.objects'] = list(bpy.context.selected_objects) override['scene.objects'] = list(bpy.context.selected_objects) bpy.ops.wm.alembic_export(override, filepath='/tmp/test.abc', start=1, end=1, visible_objects_only=False, selected=False) ```

Philipp Oeser commented

2022-04-13 14:02:50 +02:00

Added subscriber: @kevindietrich

Philipp Oeser commented

2022-04-13 14:02:50 +02:00

quoting @kevindietrich from chat:

One thing that could work is using a custom property (in the object properties tab) and use this to record the visibility information. In Blender the object then will always be visible for the export to work, but this property will be exported to Alembic, and if Houdini can import it (Maya can import those AFAIK), use it there to control visibility.

quoting @kevindietrich from chat: > One thing that could work is using a custom property (in the object properties tab) and use this to record the visibility information. In Blender the object then will always be visible for the export to work, but this property will be exported to Alembic, and if Houdini can import it (Maya can import those AFAIK), use it there to control visibility.

Sybren A. Stüvel commented

2022-04-14 17:21:01 +02:00

Added subscribers: @JacquesLucke, @Sergey

Sybren A. Stüvel commented

2022-04-14 17:21:01 +02:00

I've worked on supporting the export of invisible objects, so IMO this should work in conjunction with "only selected" as well. What @lichtwerk said is correct, there is the "invisible means deselected" rule, but there are problems with this in practice. I was aware of the impossibilities of actually keyframing visibility (because the object needs to be selected to key it, and it gets deselected when hidden), and this is another spot where this hard rule bites us in the rear.

We could work around this in functions like ABCHierarchyIterator::mark_as_weak_export(const Object *object), which is the place where the selection state is tested. IMO that would be rather hacky, though.

I'd rather see "hide means deselect" rule getting more flexible. That way an exporter could just temporarily disable that for the duration of the export, and the rest of the code can remain simple. This would require a change to BKE_base_eval_flags(), which clears the BASE_SELECTABLE flag on invisible objects, which in turn clears the BASE_SELECTED flag.

@Sergey @JacquesLucke what would you think of something like a depsgraph evaluation option to make this little bit of code in BKE_base_eval_flags() optional?

  /* Deselect unselectable objects. */
  if (!(base->flag & BASE_SELECTABLE)) {
    base->flag &= ~BASE_SELECTED;
  }

Exporters that construct their own depsgraph (USD and Alembic, maybe more) could pass that option and work as expected, resolving this task. For the "allow animating visibility without an aneurism" issue this wouldn't be enough, and IMO that'll require a decent design task first.

I've worked on supporting the export of invisible objects, so IMO this should work in conjunction with "only selected" as well. What @lichtwerk said is correct, there is the "invisible means deselected" rule, but there are problems with this in practice. I was aware of the impossibilities of actually keyframing visibility (because the object needs to be selected to key it, and it gets deselected when hidden), and this is another spot where this hard rule bites us in the rear. We could work around this in functions like `ABCHierarchyIterator::mark_as_weak_export(const Object *object)`, which is the place where the selection state is tested. IMO that would be rather hacky, though. I'd rather see "hide means deselect" rule getting more flexible. That way an exporter could just temporarily disable that for the duration of the export, and the rest of the code can remain simple. This would require a change to `BKE_base_eval_flags()`, which clears the `BASE_SELECTABLE` flag on invisible objects, which in turn clears the `BASE_SELECTED` flag. @Sergey @JacquesLucke what would you think of something like a depsgraph evaluation option to make this little bit of code in `BKE_base_eval_flags()` optional? ``` /* Deselect unselectable objects. */ if (!(base->flag & BASE_SELECTABLE)) { base->flag &= ~BASE_SELECTED; } ``` Exporters that construct their own depsgraph (USD and Alembic, maybe more) could pass that option and work as expected, resolving this task. For the "allow animating visibility without an aneurism" issue this wouldn't be enough, and IMO that'll require a decent design task first.

Sergey Sharybin commented

2022-04-19 09:45:32 +02:00

@dr.sybren The problem with the proposal is that it leads to inconsistency in semantic of flags. If the piece of code is essential from the current design point of view, then after implementing your suggestion a base might be in an inconsistent state when it is selected but is not selectable. One might argue that this is OK since Alembic/USB knows what to do, but there many more stages of evaluated the object can come through. I also don't really like idea of making a precedence of semantic change depending on who cerated/evaluated a dependency graph.

Possible alternatives:

Convince me harder that the proposal is the only good solution in an observable future ;)
Remove the piece of code you've mentioned, move base selection check to an utility macro/function, check for both BASE_SELECTABLE and BASE_SELECTED. Maybe rename BASE_SELECTED to BASE_WANTS_TO_BE_SELECTED, and call utility is_base_selected_for_user_interaction(). Semantically, not literally :)
Allow some depsgraph-specific flags on nodes, so that engines can tag IDs of interest at depsgraph construction tine, and access that information while iterating over the depsgraph.

@dr.sybren The problem with the proposal is that it leads to inconsistency in semantic of flags. If the piece of code is essential from the current design point of view, then after implementing your suggestion a base might be in an inconsistent state when it is selected but is not selectable. One might argue that this is OK since Alembic/USB knows what to do, but there many more stages of evaluated the object can come through. I also don't really like idea of making a precedence of semantic change depending on who cerated/evaluated a dependency graph. Possible alternatives: - Convince me harder that the proposal is the only good solution in an observable future ;) - Remove the piece of code you've mentioned, move base selection check to an utility macro/function, check for both `BASE_SELECTABLE` and `BASE_SELECTED`. Maybe rename `BASE_SELECTED` to `BASE_WANTS_TO_BE_SELECTED`, and call utility `is_base_selected_for_user_interaction()`. Semantically, not literally :) - Allow some depsgraph-specific flags on nodes, so that engines can tag IDs of interest at depsgraph construction tine, and access that information while iterating over the depsgraph.

Sybren A. Stüvel commented

2022-04-19 15:44:04 +02:00

Convince me harder that the proposal is the only good solution in an observable future ;)

NO! Your arguments are too convincing ;-)

Currently the selection state is used to determine the "export set" (i.e. which objects to export). This could be handled in a different way as well, moving the construction of the "export set" to a separate pre-export step. During the actual export the "export set" can then be used instead of the selection state.

> Convince me harder that the proposal is the only good solution in an observable future ;) NO! Your arguments are too convincing ;-) Currently the selection state is used to determine the "export set" (i.e. which objects to export). This could be handled in a different way as well, moving the construction of the "export set" to a separate pre-export step. During the actual export the "export set" can then be used instead of the selection state.

Bastien Montagne added this to the Pipeline, Assets & IO project 2023-02-09 15:40:38 +01:00

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Alembic export of "Only Selected Objects" with unexpected output #97275