Present: Brecht Van Lommel, Kévin Dietrich, Michael Kowalski, Sybren Stüvel
This is a summary of a video meeting about the direction of USD and Alembic support in Blender and Cycles.
Michael: wants to get features from the universal-scene-description branch into master.
For Blender 3.1: USD preview surface material export
Nice-to-have for 3.1: Symmetrize camera export with import
The remaining features in that branch can be ported in 3.2.
Kévin: has a bunch of new features, is preparing patches already:
UI reorganisation, pretty simple & easy
importing Alembic override layers
support for creating geometry sets from both Alembic & USD importers
an attribute remapping mechanism, including letting users choose which datatype is used and what the domain (mesh points vs. face-corners) should be.
instancing support, loading instances as linked duplicates of objects
Sybren: asks about potential unification of Alembic and USD support in Cycles.
Brecht: Cyces & Blender will keep different implementations for Alembic, as Cycles can be used standalone as well.
When USD support is added to Cycles, it will use a similar approach as the current Alembic support.
Collection-based Import/Export (T68933): Michael is interested in spending time on this.
Actually working on this from the Blender side might be hard, as the people who know about it have busy schedules already. Technical discussions should include Bastien, discussions about priority should be had with Dalai.
Michael will discuss with Kévin to see how he implemented instancing for Alembic.
Brecht: Blender could have different approaches for instancing:
linked duplicates are more natural for low number of instances
instancing on a point cloud could work for of thousands+ points.
Instancing a hierarchy of objects requires a collection.
Kévin: instances can have different transforms, so may need different Transform Cache constraints.
Michael asks about the requirement to keep USD files locked, due to the nature of the current design for loading any animated data.
Sybren: animated transforms could be loaded as animation curves. Reloading data from USD when that changes could be tricky.
Brecht: library overrides could be used here, to override specific animation curves and reload the others.
It is agreed to have more regular meetings like this, to help moving in the same direction. The majority of discussions are still likely to happen on Blender Chat.
I’ve been testing the new @KevinDietrich implementation and so far it works great.
I have two comments regarding Alembic.
When we define the option to have a cache modifier even if the object has no animation, a good practice would be to remove the internal actual geometry, at least as an option, this way we end up with an object that has no weight in the .blend file, and it’s continuously updated, instead of an underlying geometry that has weight in the .blend and you will never use because it’s overwritten by the cache modifier.
Regarding linked duplicates, it has a big flaw that users tend to ignore (or simply not know because it’s not obvious), if a linked duplicate has modifiers it stops being an instance.
I would say that a link hierarchy, with a main object and “followers” could be a solution, but it should retain modifiers as linked data blocks and not as they are right now, or simply pick the modifiers in the first link and “lock” modifires in the others, so they can’t be modified (if modifiers cannot be linked).
Other solution, simpler but not as efficient, would be to put a warning to the user so it’s obvious that the linked object it’s not an instance anymore and will count as real geometry.
Actually I think we could simply not create actual geometry when importing a new file if a modifier is added (either because animated, or because “Always Add Cache Reader” is checked). This could indeed allow for file size reduction. Also it could make import faster as the data is not read directly.
Although, one downside is that the data will always be read for static objects on every single frame change.
Would this always be a problem though? Even if Blender had support for proper procedurals (like Cycles), as soon as you modify the cached geometry, it will need to be a proper object in Blender. Maybe instancing can be streamlined, but given the current design, linked duplicates are the best options. It can still change in the future.
Regarding cache modifier and geometry, yes, avoiding it’s important would be even better, and if you want the actual geometry you can always apply the cache modifier.
Regarding the linked modifiers, yes, with Alembic is solved with procedural, but I was referring to modifiers in general and linked duplicates, for example if you have two objects with a simplify modifier, even if the modifier is exactly the same one, with same values, it counts as two different objects instead of instances, that is what I was referring to
