Alembic Layering RFC

[John Burnett]

Hi folks,

 

Our pipeline within Blizzard Cinematics depends upon an internal caching library/format that supports the concept of layering multiple files for a given single logical entity (e.g. for a given mesh, the topology can come from one file, UVs from another file, and animated P from yet another).  This flexibility has prevented us from migrating to Alembic in the past, which have wanted to do for some time.

 

To fix this, we've worked with Lucas Miller to add this functionality to Alembic itself.  This includes:

 

- Extend the core Alembic code base to support layers.

- Include test data files to show layering capabilities.

- Update the existing example tools, plugins and applications to support layers where appropriate.

 

This work is ongoing, but we wanted to get this in front of the community to solicit feedback.  The current state can be seen in this pull request: https://github.com/alembic/alembic/pull/78 .  We'd love to hear from folks here before we get much further to see if there's features we're missing or should otherwise change before officially merging it in.

 

We are also planning to have a Birds of a Feather event at SIGGRAPH to have a meaningful discussion around this topic and others.  More details on that to follow.

 

Regards,

John

Cinematics R&D/Tools Supervisor

Blizzard Entertainment

 

[Deke Kincaid]

How similar/different is this then layering in USD?

http://graphics.pixar.com/usd/overview.html#USDFeatureSpecification-Layering

--
You received this message because you are subscribed to the Google Groups "alembic-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lucas Miller]

Hmmmmm, I suspect conceptually they may be similiar.

Going over that link, it's a little hard to figure out what USD can
and can't do.

Instead I'll list some of the things Alembic layering will be able to
do, please provide any feedback if you would like to see other
features.

You can add additional properties to a shape. (UVs to a polymesh that
is lacking them)
You can override properties. (override static points on a polymesh
with animated points)
You can add new objects. (add a shape to an existing hierarchy)
You'll be able to prune objects. (don't like a subhierarchy or
specific shape?, it can be removed)
You'll be able to prune properties. (bad normals messing up renders,
it can be removed)

Lucas

[thepilot .]

Hi,

Probably already covered by overriding properties, but merging a abc with materials & assign them to shapes.

[Alex Suter]

From messing with it a few years ago USD can internally refer to other files and layer things on the fly when reading it. So you'd have one usd file that does your scene composition which refers to the assets, animation files, textures, etc.

Would this new system do that?

[Barnaby Robson]

This is super interesting !  I scanned the pull request but couldn't
find the test data files mentioned below. Please could you point
to them directly, if they exist ?

Actually I more interested in the high level API that demonstrates
how layering is achieved. From what I can gather, it looks like this
change introduces a new 'backend' which is the 'Layer' backend.
I'm assuming this means that layering must in some ways be
invisible the highest levels of the alembic code, so I'm wondering
how deep you need to go to create a layer.

Thank you !

On 07/11/2016 09:47 AM, John Burnett wrote:

- Include test data files to show layering capabilities.

-- 
Barnaby Robson - Technology - SF - x63761

[Lucas Miller]

Almost.

Having a file define your layer stack was something we've talked
about, that would take care of the animation files/uvs/textures part
of a single asset.

Referencing multiple other Alembic assets hierarchically from an
Alembic file is a slightly different but interesting discussion.

[Lucas Miller]

> This is super interesting ! I scanned the pull request but couldn't
> find the test data files mentioned below. Please could you point
> to them directly, if they exist ?

We don't have them quite yet, once we have unit tests in place, they
will be a good source of examples.

> Actually I more interested in the high level API that demonstrates
> how layering is achieved. From what I can gather, it looks like this
> change introduces a new 'backend' which is the 'Layer' backend.
> I'm assuming this means that layering must in some ways be
> invisible the highest levels of the alembic code, so I'm wondering
> how deep you need to go to create a layer.

We are planning on adding a way to do this via the schemas. If you
look at OPolyMeshSchema you can see the direction we are moving for
authoring the sparse properties. For some of the other operations
(prune) we will provide convenience functions to write it.

Lucas

[Stephen Parker]

Would this work in the same fashion as GTO? Could one concatenate many partially defined Alembic files that overlayed/merged/filtered into a single file from the command-line?

[Lucas Miller]

Yes, AbcConvert in the pull request already attempt to do this.

[Barnaby Robson]

Ok .. I'm getting slightly confused.

It appears as though this RFC will allow you to layer in
alembic properties from other files. Is that correct or no ?

If the above is correct and there aren't restrictions on where
in the hierarchy you can create layers then what stands between
this and a full blown reference system ?

[Lucas Miller]

You declare what files you want to layer together up front, not while
traversing the hierarchy.

Lucas

[Barnaby Robson]

Is there any requirement that the properties you add from another
file can not have sub-properties or anything like that ?

[Lucas Miller]

No, there is no such requirement.

Lucas

[Barnaby Robson]

Ok great ! Then I think your list of:

- adding new properties
- overriding existing properties
- pruning existing properties

is all you need to successfully layer files.

I can tell you that we would immediately want to use something
like this and the lack of layering is one of the top reasons for us
wanting to switch to USD.

One immediate use case is for FX to hand off a small portion of
a giant alembic file. ie. they only want to hand off the part of the asset
that has been destroyed and not the entire thing.

I'm really interested to know more about the "up front declaration of
layers" aspect and how hard that is to work with in production.

Thank you for doing this !

[Lucas Miller]

> I'm really interested to know more about the "up front declaration of
> layers" aspect and how hard that is to work with in production.

It just means you need to know what layers you are combining together
at read time:

https://github.com/tyanalunas/alembic/blob/master/lib/Alembic/AbcCoreFactory/IFactory.h#L72

Lucas

[John Burnett]

We're going to get to the layer stack file "soon", but I'm imagining a utility that does something like the following:

# Create catalog.abc referencing layer1.abc and layer2.abc
abccatalog --create catalog.abc layer1.abc layer2.abc

# Print the list of abc files referenced by given catalog.abc
abccatalog --list catalog.abc

# Create self-contained, flattened outfile.abc given a catalog or set of layers
abccatalog --flatten outfile.abc <catalog.abc|layer1.abc layer2.abc ...>

...the main benefit of having these catalog files is for applications that don't directly support picking multiple abc files.  In theory, an app would just have to build against the new Alembic and change nothing else to get basic layering support.  It's a goal to make it so this new version is binary compatible with 1.6, so in theory if an app's Alembic support comes from a dso/dll, you could build just that yourself and get layering without waiting for vendor support.  In theory.

John

[Spiff]

So sorry you couldn't find the info you were looking for, Lucas! I think the top-level USD pages are possibly too high-level, and don't enumerate enough of the nitty gritty details. Will try to adddress that for the siggraph USD github launch.

I won't pollute this forum with lots of USD talk, but will confirm that layerStacks in USD provide all the features you mention, plus a few more we've found useful for scene assembly. All of those overrides are also expressible over referenced files for scene assembly, as well as within and over "variantSets" that package up switchable variations in assets and scenes.

Anyone with USD questions please feel free to ask at https://groups.google.com/forum/m/#!forum/usd-interest

Cheers,
Spiff

[John Burnett]

Thanks for the info Spiff, and just to be clear on our side, we are keenly interested in USD as well.  For us, the Alembic layering is an additional and more expedient way to offload some of our internal code to open source libs.  From there, we're eyeing USD to potentially take over our overall layout data/pipeline later on.

Cheers,

John

[Barnaby Robson]

Would it be possible to support a feature where you can specify
a location inthe hierarchy you wish to merge ?

Say you had 2 caches like this:


Cache 1 Cache 2

+ / + /
| |
+---+ A +---+ D
| |
+---+ B + E
|
+---+ C


Could you add a directive such that when you layer cache 2
you get something like this ?


Merged Cache

+ /
|
+---+ A
|
+---+ B
|
+---+ C
|
+---+ D
|
+ E


We could use that when we are building sets. Right now we
bake the set in a separate process but it would be very nice
to just merge on the fly at read time.

[Lucas Miller]

How would you specify where D and E need to go to fit in with cache 1,
and how would that be different from creating:

+ /
|
+---+ A
|

+---+ C
|
+---+ D
|
+ E

Where A and C don't have any data on it in cache 2?

I ask, because some possible solutions may introduce complexity that
might not actually be needed for your specific case.

Lucas

[Barnaby Robson]

Well I was thinking that abccatalog, for instance, could take an optional
argument which is the new root. Something like this:

abccatalog --create catalog.abc layer1.abc layer2.abc:/A/C

But I guess I'm maybe trying too hard to turn this layering system into
a reference system, and maybe that takes this into a world of crazy hacks.
Maybe it's best to forget any notion of referencing and changing of
hierarchies
and leave that to a proper reference system.

By the way what happens if in the abccatalog command one of the
layer files you layer is in fact another catalog file. Can you have
nested cataloging or would that be an error ?

[Ryan Galloway]

On Wed, Jul 13, 2016 at 5:10 PM, Barnaby Robson <bro...@ilm.com> wrote:

By the way what happens if in the abccatalog command one of the
layer files you layer is in fact another catalog file.  Can you have
nested cataloging or would that be an error ?

FWIW, and this is probably a minor point, but abcview has its own file format (.io) and has been able to do this kind of thing for a while. v1.1.0 can even do contextual overrides on attributes, at least at the scene level. Here's a really basic example, but I think it illustrates the kind of thing you're after:

http://alembic.github.io/abcview/overrides.html

Ryan

[Diego Garces]

This is super interesting to us, as we are talking about doing something to achieve precisely this, so it's great!

I got the pull request code to test it and after a couple of minor issues I was able to set it running and it seems to be working very well. What are the main features pending? Is the current code going to be more or less stable or are you planning on doing big refactorings before the final release? Do you have an idea about when this could be in the official release?

Regarding the discussion about an exchange file format for layers and such, isn't it something that could be handled in the higher level layer than Alembic? It's probably one of those areas where the combination of USD as a description file and Alembic as the geometry cache file could work.

The line between USD and Alembic is super clear, so I think there might be a danger in USD and Alembic trying to solve the same problems in different ways instead of providing a combined solution. What do you guys think about it?

Cheers,

Diego

[Deke Kincaid]

The way I see it USD is still at least 3 years away from being practical for most people.  Yes it is supposedly open sourcing around Siggraph but the point where it is included in all DCC apps out of the box and on all operating systems is 3 years or more.  The scope of USD is so huge it is going to take quite a long time for integration.  It is not a small task for most DCC apps to integrate.

Layering in Alembic is a reality very soon and useful for most of us right away.

[Lucas Miller]

> I got the pull request code to test it and after a couple of minor issues I
> was able to set it running and it seems to be working very well. What are
> the main features pending?

prune/replace, support for sparse setting of data in all of the
OSchemas where it makes sense.

> Is the current code going to be more or less
> stable or are you planning on doing big refactorings before the final
> release?

The top level API that users will interact with (other than
convenience functions for writing certain layered data) is just about
set.
It's meant to be as seamlessly integrated as possible.

The "big" refactorings that are left, shouldn't effect the public
facing API. (few more templates to harden, Sample classes for schemas
should be separated out into it's own files, rework OSchema to be more
like OPolyMesh to allow sparse setting of certain data)

> Do you have an idea about when this could be in the official release?

Soon™, hoping for Siggraph adjacent, or early fall.

Lucas

[timyan...@gmail.com]

It was great to meet and talk to so many of you at the Alembic BOF this week at Siggraph!

For those who were not able to attend, here were some of the audience questions about layering

Is layering a proposed Alembic feature or an actual feature?

Actual feature. The layering pull request is quite functional and is planned to be included in a release Coming Soon™

What can I use layering for?

Layering can be used to combine objects and properties together from an arbitrary number of files. This can be useful when artists from more than 1 discipline are iterating on a single file.

During development, the working example has been to use layering to house UV data. Specifically, one ABC file holds a IPolyMesh instance with position/indices/count data. A separate file holds a partial IPolyMesh instance with only sparse UV data. They are combined together at read time via layering.

If you are currently using Alembic but you have sidecar data files, you may file layering to be a helpful replacement for that sidecar data.

Are there example files for layering?

Yes, we hope to post those soon (after Siggraph)

Also, Lucas Miller has provided a link to the BOF presentation slides:

https://docs.google.com/presentation/d/1oS-BsRe_C-OruofpaLWpYOdzVQG4P658tv49NDSkQP8/edit?usp=sharing

Thanks,

Tim Yanalunas

Blizzard Entertainment, Cinematics R&D

[Lucas Miller]

Annnnnnd the layering feature is now in beta.

For the curious please check out:
https://github.com/alembic/alembic/tree/1.7beta

There may be a few more utilities to add, and we don't yet want to
deem this ready for use in production but we feel like we are close.

Some code examples:
https://github.com/alembic/alembic/blob/1.7beta/lib/Alembic/AbcGeom/Tests/PolyMeshTest.cpp#L359
https://github.com/alembic/alembic/blob/1.7beta/lib/Alembic/AbcCoreLayer/Tests/PropTests.cpp

https://github.com/alembic/alembic/blob/1.7beta/python/PyAlembic/Tests/testLayer.py
https://github.com/alembic/alembic/blob/1.7beta/python/PyAlembic/Tests/testPolyMesh.py#L113

Lucas

[Asen Atanasov]

Hi Lucas,

we are interested to integrate this into V-Ray. What is the current status? When are you planning the 1.7 release?

Best regards,
Asen

> email to alembic-discussion+unsub...@googlegroups.com.

[Asen Atanasov]

Oh I see it is already out. The documentation is for 1.6.

[Paolo Berto]

Here's a quick video of Alembic Layering in Multiverse V5, straight from the Maya UI:

http://www.giphy.com/gifs/3ohc16A8mQYngXqhFK

http://multi-verse.io