Layering

This guideline will cover the basic concept of "layering" USD files in a single Multiverse Compound and a practical guide on how to use layers in your workflow.

Alembic layering limitation

In Multiverse you can layer both USD and Alembic files, however, unlike USD which can truly handle sparse overrides, Alembic always requires the presence of topology and mesh definition. So if you want to layer multiple Alembic files, for example one with UVs and one with animated mesh points, make sure they are written with their topology, while in the case of USD you don't have to worry about it.

If possible, we recommend you to use USD, please also read the USD or ALembic documentation.

Basic Concept

Think of layers as "Photoshop layers", but instead of dealing with pixels you are dealing with 3D data. These are just few examples of data that can be layered:

• UVs over a T-pose model geometry (topology, static mesh points and normals)
• Animated mesh points over a T-pose model
• Material assignment over any of the previous
• Material shading networks over any of the previous
• Overrides over any of the previous

The result of Layering is actually an in-memory composition where the previous example layers are combined on the fly and you see a result live in the viewport and in the renderer. You can at any time if you wish write out a single compound and its layers into a composition: when you read it back you'll see a Multiverse Compound with a single layer. We call this consolidating a single compound: make sure to enable the Write as Compound Layers option when doing so, this option is available as of Multiverse 7.

In Multiverse, we generally use layering for handling different parts of an asset because in a typical production workflow there would be multiple departments that handle different tasks such as Modeling, UV, Look Development, Animation and so. Eventually the output of each department will be combined using Layering in Multiverse to produce the final asset.

Check out the Multiverse Pipeline for a data flow chart diagram representation.

Practical Example

First we start with an asset authored by the modeling department: it's in T-pose character and contains UV, display color and material assignments.

The animation department, who has received this model, outputs an animated USD file and we can layer it on top of the model, relaying on the topology and UVs of the T-pose, and applying the animated points and normals written by animation (note that normals are not needed if you are rendering the same mesh as subdivision surfaces as the original normals will be discarded).

In a production pipeline multiple teams work in parallel, and it is possible that the lighting department will need to receive updates.

First of all, because the lighting department works with USD files, according to your asset resolving pipeline you will be able to pull the latest changes for these assets by simply opening or reloading your scene.

These changes can be non-destructive.

Let's make an example: imagine the position of the necklace object was updated: the relevant department did output an override USD file for the new position of the object and add the new file as a new layer on top of the existing ones in the Multiverse compound node.

It is important to understand that this layering works for every type of data: so don;t think only about layering animation (transformations and positions) but also layering material assignments, attributes, variants selections... anything. Last but not least remember that when using USD for layering you are free to write sparse overrides without worrying about topology.

The Importance of Hierarchy

When layering multiple data related to the same asset, in order to make data layer and override nicely, we need to ensure that the hierarchy is compatible.

As we can see from the image below, after adding 2 additional layers, the final hierarchy remained the same:

This brings to the following question: what happens if we add a new layer, but its hierarchy does not match the. existing one?

Let's say we have a static model and we want to add a new layer for animation data. If the hierarchy does not match, the animation won't work. Instead the two hierarchies will be merged. The image below shows a simple example of layering a sphere and a cube together: from MEOW we can see that since name and hierarchy didn't match they will be composed at the same level.

This layering operation was perfectly legal, but it does not mean that we should compose multiple assets together using Layering: you should instead write a Composition to do so, which is more efficient.

Use layering for the purpose of applying layers and overrides on top of compatible hierarchy.