Page MenuHome

Objects not exported to Alembic if disabled in render
Confirmed, NormalPublicBUG

Description

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 430.64

Blender Version
Broken: version: 2.80, 2.82 (sub 7), branch: master, commit date: 2020-02-12 16:20, hash: rB77d23b0bd76f
Worked: 2.79

Short description of error
On any object, when the toggle "show in renders" is disabled (the visibility option), alambic export seems to work, but we try to import it, nothing appears, even with the "Renderable Objects Only" turned off

Exact steps for others to reproduce the error

  1. Open the above blend file
  2. Export to Alembic with "renderable object only" unchecked
  3. Import the Alembic file, or list contents with abctree test-279.abc
  4. See that there are three cubes in 2.79, and two cubes in 2.80+

Event Timeline

Richard Antalik (ISS) changed the task status from Needs Triage to Confirmed.Apr 20 2020, 7:22 PM
Richard Antalik (ISS) added a project: Alembic.
Brecht Van Lommel (brecht) changed the subtype of this task from "Report" to "Bug".
Sybren A. Stüvel (sybren) renamed this task from Objects not exported in alambic if disabled in render to Objects not exported in Alembic if disabled in render.Tue, May 12, 4:39 PM
Sybren A. Stüvel (sybren) renamed this task from Objects not exported in Alembic if disabled in render to Objects not exported to Alembic if disabled in render.

The underlying issue is that as far as the dependency graph goes, the object doesn't exist because it's disabled for render. I see two solutions:

  • Allow the depsgraph to evaluate invisible objects as well, or
  • Get the Alembic exporter to do its own evaluation.

@Brecht Van Lommel (brecht) @Sergey Sharybin (sergey) do you have any opinions about the nastyness/desirabililityness of either?

What isn't fully clear to me so far is what is the expected behavior: what is it (per design) what should be put to the output?
Dependency graph will cut off a lot of objects if, say, collection is not visible. This saves a lot of memory and evaluation time.

So, imagine you have 5 high-res animated characters, and you only want to export one of them. How does this work? How to set up scene for this, how to set up export options?

From technical side of implementation it is easier to add some sort of options (or a callback, or a subclass, depending on what and how is to be controlled) to the builder so that objects of interest are marked as "visible".
Just to stress it: you must be careful about what you consider visible, to keep memory footprint as low as possible, and to have export process as fast as possible.

Never do own evaluation, as you can not do it reliably.

What isn't fully clear to me so far is what is the expected behavior: what is it (per design) what should be put to the output?

I don't know exactly. It was part of the original Alembic patch (D1783), which didn't have any design document. It's simply a check on object->restrictflag & 4 (i.e. on OB_RESTRICT_RENDER) . That's all there is to it. The rest of the code just exports the object transforms, and calls DerivedMesh *dm = mesh_create_derived_render(m_scene, m_object, CD_MASK_MESH); to get the mesh for exporting. As a result, it's now expected that invisible objects can be exported.

From what I understood, the general wish is to be able to have something invisible in test renders, but to still include it in Alembic exports. This can indeed include the export of both a low-poly and a high-poly version of a character, even when only one is visible at any one time.

On a technical side, it is starting to look more and more like what view layers were intended for. One view layer for rendering, one for exporting. As the visibility toggles are per object, and not per view layer, the visibility of the objects should then be handled by enabling/disabling collections instead. Do you agree @Sergey Sharybin (sergey)?

I don't know exactly.

Well, this is the first step to do before jumping into discussion of how bad evaluation of invisible objects in the dependency graph is.

It was part of the original Alembic patch (D1783), which didn't have any design document. It's simply a check on object->restrictflag & 4 (i.e. on OB_RESTRICT_RENDER) . That's all there is to it. The rest of the code just exports the object transforms, and calls DerivedMesh *dm = mesh_create_derived_render(m_scene, m_object, CD_MASK_MESH); to get the mesh for exporting. As a result, it's now expected that invisible objects can be exported.

This describes legacy approach which had serious design limitation. For example, it wasn't possible to have, say, boolean operand of shrinkwrap target to have different subdivision resolutions in viewport and render.

From what I understood, the general wish is to be able to have something invisible in test renders, but to still include it in Alembic exports. This can indeed include the export of both a low-poly and a high-poly version of a character, even when only one is visible at any one time.

While this is plausible scenario, it feels you need more than just include objects for both low and high poly character. You wouldn't want to individually toggle visibility of all objects character consists of individually, there needs to be some parent object (which will represent collection in Blender terms).

On a technical side, it is starting to look more and more like what view layers were intended for. One view layer for rendering, one for exporting.

For lighting/rendering tasks I don't think you need to separate export view layer. You need to use same exact view layer you use for rendering, with all objects (and only them) which appear in the final frame. Probably, ignoring all indirect dependencies for saving up space and increasing streaming performance.

In fact, I would say you shouldn't have separate view layer for such scenario: keeping two view layers in sync will break sooner than later in a real production.

For the scenario where you want to have both low and high poly mesh having an separate view layer simplifies configuration and communication of options in the exporter settings. But I am still not sure what is the actual real life workflow in here.

As the visibility toggles are per object, and not per view layer, the visibility of the objects should then be handled by enabling/disabling collections instead.

Yes, for export you want to toggle visibility on collection level.

What isn't fully clear to me so far is what is the expected behavior: what is it (per design) what should be put to the output?

Exporting all objects can be much slower, but as long as it remains optional it seems reasonable. I think it is useful to be able to export all objects + their visibility settings. So that in another application, you'd still be able to e.g. switch between different LOD levels or variations.

For this to be a smooth user experience Blender visibility settings should then map well to Alembic / USD. Since often in production scenes there are many helper objects that should never be visible. Or e.g. only one of two object variations should be visible at the same time.

But even if that's not fully supported, I can still imagine cases where users would want to just export all and solve any issues on import into the other app. Basically cases where you want to transfer the scene to another application as closely as possible, rather than bake the geometry for rendering. For example to do a physics simulation.

So, imagine you have 5 high-res animated characters, and you only want to export one of them. How does this work? How to set up scene for this, how to set up export options?

I think visibility settings and selecting which characters to export are different problems. For the latter, I think T68933: Per-Collection I/O data for re-import/export is the proper solution. Then if you create a collection with the character(s) to export, you could still have the option to export all objects within that collection, or only the visible ones.

I think visibility settings and selecting which characters to export are different problems.

In theory yes, but currently it feels like visibility controls both.

Is the solution then:

  • Have an option to export all objects, providing Alembic information about visibility (and from DEG side it will be solved by "forcing" visibility to truth in the builder which seems most isolated change, which wouldn't add "overhead" to the evaluation)
  • Have an option to only export what renderer/viewer "sees" (which seems to how it is currently behaving).
  • Have option to specify collection(s) which are to be exported (which is outside of the scope of this report, but is aligned wit hthe brief information from T68933).

(question mark :)

Yes, I think that sums it up.