Exporting a scatterer to an Alembic archive

[Michel Lerenard]

Hi everyone,

I'd like to propose a way to store a scatterer object into an Alembic
archive. The idea is to be able to save/load a scatterer to and from an
alembic without baking it.
The implementation I will be describing is obviously guided by our
needs, but I'm trying to keep it as modular/generic as possible.

In Clarisse Ifx, a scatterer is a procedural object and I need to keep
it that way through the export, as much as I can : a short video being
more effective than a long speech, here are two mini tutorials on
scatterers in Clarisse:
https://www.youtube.com/watch?v=GiDXPv0lU4g
https://www.youtube.com/watch?v=fHWT1LF2NV8

My idea is to create a new Scatterer object, and to export it as well as
all the objects it can reference, meaning that in the same archive, you
need to export the scatterer object, the object providing point
positions, and all the objects we want to scatter.
The contents of the Scatterer object could be like this:

+ ".pointCloud". A ScalarProperty that holds the path of an object that
would provide point positions (mandatory) and other properties like
normals, colors, etc... (optional). This object can be Points, Mesh or SubD.
+ ".instances". An array property that would tell which objects are
instanced. This array size would match the number of instances the
scatterer creates. We could either store paths to the objects (Mesh or
SubD), or UIDs.
+ ".parameters" A compound property that would contain the values of the
parameters that are needed for the procedural stuff. Given that each
application may have its own set of attributes/parameters, my idea was
that we would not dictate how parameters have to be named, but simply
make sure that they are all in the same CompoundProperty. I prefer this
solution to using arbGeomParam or userProperties as it may help to
standardize names over time. It may sound paradoxical to not want to
lock attribute names and hope that they would converge, but I feel that
we would not be able to agree on a fixed set of parameters names, and
having them in a specific compound should ease remapping.
Typically in this compound property we would store parameters that
control the variance, decimation, etc...
+ ".matrices" (optional) An array property that contains baked matrices
for each instance that the scatterer creates. Useful for application
that cannot recreate the scatterer internally.


Storing parameters allows any application to store a scatterer in a
cache a reuse it later, while having the possibility to bake the objects
matrices allows to transfer a scatterer from one application to another.

What's your opinion about this ?

[Lucas Miller]

Hello!

Something similiar to this was brought up at the SIGGRAPH Alembic
Birds of a Feather.
Several other people are interested in this as well.

I think this could be simplified to a schema that contains an array of
4x4 matrices and an indexed array of strings which point to the
hierarchy being instanced. (not just 1 polymesh or subd per instance,
but potentially a bunch) This hierarchy would often live below the
scatterer object, but could exist elsewhere in the Alembic archive.

I currently disagree with having the .parameters, I think we may be a
ways off of having standardization of how to do this between DCC
packages. Instead .userProperties seem like the perfect place to put
optional "recipe" type information to better integrate with your app.

The original point cloud or mesh feels like part of the recipe, and
could also live under .userProperties.

Lucas

[Spiff]

Coincidentally, we are gearing up to open our PointInstancer schema for UsdGeom, and would welcome comment from the Alembic community.  Please see the design document here: https://github.com/PixarAnimationStudios/USD/wiki/PointInstancer-Object-Model

Strongly agree with Lucas on keeping the "procedural source" description separate from the baked representation schema.  The topic of transmitting live or re-bakable procedurals was recently discussed at length here: https://groups.google.com/forum/#!topic/usd-interest/kvya2ZeiZl0

Cheers,

--spiff

[Michel Lerenard]

Hi,

- If we simplify it to a 4x4 matrices property, I'm not sure we need a
new object: it's almost as using the existing Points schema, which
provides positions, normals, etc...
We simply add the instance property in arbGeomParam or userProperties
and we can get it working.

- I agree that instancing a whole hierarchy is needed.

- Like I said before I don't like using the .userProperties because it
implies that it's really user stuff. Even if applications have their own
internal recipe and can not emulate the procedural part of other parts,
it could be useful when remapping properties to have them in a specific
compound property: it would help sort them. You'd know that if the
property is in this "scatterer" compound, it's been used to generate
the scatterer, unlike the tons of properties that can be found in
.userProperties.
Though I'm feeling that I may be mistaken about the meaning of the
userProperties compound.

- I really like the idea of referencing an object that provides the
point cloud. The less I bake things in the archive, the more leeway I
give to users that are using the archice. In my point of view, if you
want to bake a scatterer into an alembic archive, you don't need a
special object, you can generate the scene using separate objects.
(that's an export mode we have already implemented) The same way we do
not bake the subdivision in a SubD object, I'd like to avoid baking the
result of my scattering.

[Lucas Miller]

> - If we simplify it to a 4x4 matrices property, I'm not sure we need a new
> object: it's almost as using the existing Points schema, which provides
> positions, normals, etc...

A new schema is useful because it can provide a custom interface for
interacting with this data.

Instead of storing the 4x4 we can also break it up into the classic
point, scale, quat, etc components.

> - I agree that instancing a whole hierarchy is needed.

Does the source NEED to be an arbitrary path in the Alembic hierarchy,
or can we reasonably enforce all the sources for a given scatterer to
be child objects of the scatterer?

> - Like I said before I don't like using the .userProperties because it
> implies that it's really user stuff. Even if applications have their own
> internal recipe and can not emulate the procedural part of other parts, it
> could be useful when remapping properties to have them in a specific
> compound property: it would help sort them. You'd know that if the property
> is in this "scatterer" compound, it's been used to generate the scatterer,
> unlike the tons of properties that can be found in .userProperties.
> Though I'm feeling that I may be mistaken about the meaning of the
> userProperties compound.

.userProperties is a catch all for any custom data that you may want
to pass along.
For your specific recipe, I'd probably store them all in a
.userProperties/Clarisse compound so that you can decide exactly what
to store.
Parts that may become standard among applications could eventually be promoted.

> - I really like the idea of referencing an object that provides the point
> cloud. The less I bake things in the archive, the more leeway I give to
> users that are using the archice. In my point of view, if you want to bake a
> scatterer into an alembic archive, you don't need a special object, you can
> generate the scene using separate objects. (that's an export mode we have
> already implemented) The same way we do not bake the subdivision in a SubD
> object, I'd like to avoid baking the result of my scattering.

On the flip side, the less you bake the more you rely on the app
readers to translate these intermediate unbaked results and convert it
into something it knows about. In the SubD case the base mesh is
super useful by itself, for your scatterer example, if you were
pointing at a mesh as the scatterer, the mesh itself isn't as useful
as the points on that mesh.