This guideline will cover the basic concept of “layering” multiple USD files in a 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 a T-pose model
- MEOW Overrides over any of the previous
The result of Layering is actually a composition where you combine model, animation, material assignments and other overrides. You can optionally write out this composition again, and if you read it back you’ll have a Multiverse Compound with a single layer.
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.
# 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.
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.