USD Scene Graph Instancing Export Design #126470
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#126470
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This document is to motivate discussion of strategies for extending the USD exporter to support instancing.
The USD exporter currently provides an experimental "instancing" option which was originally implemented by Sybren. This feature is very useful and powerful, but has certain limitations which I will describe below.
I propose that as a first step we extend the current "instancing" feature implementation to support true USD scene graph instancing, and this will be the main focus of this document. I believe it will be possible to extend the implementation further in a subsequent step to support exporting USD point instancers, and this will be briefly mentioned at the end.
Current Instancing Implementation
Sybren's orginal implementation provides a very elegant solution to allow sharing of mesh data for instanced objects. The strategy is to export the shared mesh data of the instanced Blender objects as internal references to one "original" mesh prim in the USD.
For example, if we have a collection containing a "Plane" mesh object which is instanced twice in Blender, as in the attached
instanced_collection.blend
, the exported USDAinstanced_collection_current.usda
(simplified) might look like this:In this case meshes
/root/Plane_001/Plane_0/Plane
and/root/Plane_002/Plane_0/Plane
have internal references to the full mesh definition in/root/Plane/Plane
(the "original"), so the mesh is defined just once in the USD instead of three time. This feature can greatly reduce the size of the USD file on disk and speed up IO times significantly.However, this strategy does not support true scene graph instancing as specified in the documentation and has the following limitations:
Proposed Implementation
The following changes are proposed to fully support instancing:
For example, the exported USDA with these changes would resemble the following (see the attached
instanced_collection_proposed.usda
):The primary changes in the code would include:
AbstractHierarchyIterator::make_writers()
to allow subclasses to optionally skip writing an object's data or an object's children in the hierarchy. This is needed because instances must be written as Xforms without data or children, as noted above.mark_as_instance()
fromUSDGenericMeshWriter::write_mesh()
, because we will no longer be exporting meshes as references.USDTransformWriter::do_write()
to mark the Xform as instanceable and to add the reference to the prototype when the exported object is an instance.In addition, material export would need to be modified for prototypes to ensure the material is defined in the subtree of the prototype. For example, for prototype
/root/Plane
, the material might need to be written to/root/Plane/_materials
instead of/root/_materials
.Point Instancing
As future work, additional logic could be added to support writing point instancers, but I haven't worked out the details for this. One approach could be to identify instanced objects whose duplicator is a point cloud and handle those with a new type of writer which would write the object's transform and prototype index to a point instancer prim.
Conceptually I think this makes perfect sense. Implementation wise it seems fine as well, though we'll want to be careful to not unintentionally affect Alembic in the AbstractHierarchyIterator::make_writers path.
Questions/Comments so far:
Xform
->Xform
hierarchy? Their documentation uses a typelessdef
with anXform
->def
hierarchy instead./root/_materials
works, at least with your proposed file. Maybe I'm missing the scenario that is problematic?@deadpin Thanks so much for the review!
The
AbstractHierarchyIterator
exports instancer objects as the parents of the instances they generate, which explains the double transform. This may seem redundant if the instancer is generating a single instance, as in this case, but makes more sense if the instanced collection contains multiple objects. In any case, changing this would require reimplementing how the iterator handles instances, so we'd have to consider whether this is worth the effort or desirable.I'm not sure why they left the prim types undefined as "def" in the examples (maybe to simplify the presentation?). In most of the real world examples I've seen, instances are represented as
Xforms
, often withxformOps
to position the instanced geometry.As for the materials: I know it's recommended best practice to include the material beneath the root of the prototype. For example:
https://docs.omniverse.nvidia.com/usd/latest/learn-openusd/independent/modularity-guide/instancing.html#hierarchical-encapsulation
but I don't have a reference to a statement about this in the actual USD docs. I'll keep looking for a reference. However, I've found that if materials are defined outside the root of the prototype, they may or may not load correctly, but I will investigate further.
In general this looks fine to me as well.
At first I was worried that this would break 'obdata instancing' (e.g. several Blender objects sharing the same mesh), but it appears that this is not supported at all currently anyway?
Thanks for the review, Bastien. Yes, you are correct that the USD exporter currently does not support the 'obdata' type of instancing.