-
Notifications
You must be signed in to change notification settings - Fork 69
Discussion on Environment Authoring Workflow
Our Set Authoring workflow is currently built around a set of recursive scene files, analogous to USD layers, which are referred to as “Stages”. They are named according to their level in the Stage hierarchy (examples are from Lego Batman):
| Name | Level | Example |
|---|---|---|
| SuperSet | 3 | Gotham City and it’s environs |
| Set | 2 | Gotham City District |
| Section | 1 | City Block in Gotham City |
| Setpiece | 0 | individual building in a City Block - Leaf node. A Setpiece contains geometry and maybe materials. |
We author these stages globally - they are usable in any shot. There is another level called ShotSet which is shot-based, which allows Sets or SuperSets to be referenced/instanced in. Additionally, many departments such as tracking, layout, FX add their own level of per-shot Set overrides
The stage files are just a simple hierarchical structure of nodes with attributes e.g
- name
- transform
- optionally/except at the leaf node - an assetidentifier (name based reference to an item in the next level down of set hierarchy...so a Set contains references to Sections etc)...
We have quite strict rules for what can be included at each stage. A superset can only contain references to sets, a set can only contain instances of sections, a section can only contain instances of setpieces etc. In theory this is configurable
..so it's not unlike a simpler, special case USD.
When authoring sets, we normally start with a library which contains a list of all of the existing set assets. We can choose to modify an existing Set , or create a new one. In all cases, we drag the set from our library browser into Maya where all of the hierarchy and geometry is created. There are several different “loaders” which can create the setpieces in different forms e.g:
- full Maya geo
- Alembic GPUCache
- proxy geo of various kinds
- renderable geometry with full shading and any procedural FX
When we translate to Maya, transforms in the Maya hierarchy which are root nodes of stages get a copy of the data from the scenery file (e.g the the full pathname in the scenery hierarchy)- so, if we're careful to only translate one "stage" at a time to ensure we only have to deal with a single layer, we can generate a new scenery file from the data we have in maya. This means we can just use maya’s tools to perform our set of Environment Authoring Operations (which artists like to use maya for - the familiar manipulators, ctrl-D to duplicate etc).
A sample of those operations:
- duplicate and/or instance parts of the hierarchy (ctrl-D)
- Add, remove, rename group nodes
- Add, remove, rename stages , setpieces
- Move, transform groups, stages or setpieces
- Add/Modify attributes
- Choose variants etc
As long as the relevant scenery attributes (including references to setpieces etc) are intact, we can reconstruct a scenery file on demand. There are a few special cases like duplication for which we need to do something special - we intercept the relevant maya event and execute some callback. Let's call this the "breadcrumb" approach - we're reconstructing a new scenery file from data stored on maya nodes for one stage at a time. This works easily as the scenery format doesn't contain much data.
We’re working on “Geometry Translation & Editing” in USD at the moment - naively using this for environments would let us take entire chunks of hierarchy and geo in USD and convert to maya, where we could perform our “environment operations” above.. However as we are translating the composed/flattened USD Stage:
- we lose references, other composition operators, and layering info from the original USD stage (The layering problem could be solved if Maya had some mechanism for layering data - there are both new and old "Render Layers" APIs, but anecdotally, these are not expressive enough to be able to describe the USD data)
- It's not very scalable, as we will hit limits on maya transforms and meshes fairly quickly
If we translate just group nodes and not shapes (which refer back to the original USD mesh) to maya, for a single stage (as per scenery) is this enough for us to be able to:
- perform the operations of interest above? What happens if we ctrl-D on something like this, or rename nodes, does it behave?
- write back using the "breadcrumbs" approach?
This would require the development of a custom bidirectional Set translator to and from maya
Potential problems:
- USD prims can contain lots of attributes, relationships etc (unlike the Scenery case which is fairly constrained)- if we translate from USD to maya and back again, we'll need to maintain these, either by keeping a reference to the original data, or a copy, and deal with any instances/duplicates appropriately. One solution would be to constrain the data we store on those grouping prims to be data which maya can easily read and write
- A (more USD centric and future) workflow might be to be able to select individual groups or setpieces in the AL_USDMaya Proxy Shape viewport (like we do now in our set overrides workflow) and be able to perform the operations on them maya-natively (e.g duplicate) and convert each of these back into a USD equivalent operation(s) where it exists (sounds like we would need a hook where we could implement our own operation). It might be possible to do this already with maya events, but could get messy - sounds like something Autodesk might want to help us with? This approach would also minimise the amount of geo being brought into maya which would be good for scalability. It might work for duplicate, but probably not for something like re-organising hierarchy where you really need to see the hierarchy in maya.
- Rather than duplicate USD Info in maya, or store a reference to it, could we use GUIDs on each prim to track match between translated objects in maya and their source? We would have to generate new GUIDS after instancing/duplication etc. Might work if we don't intend editing many of the attributes in maya.
- USD support for overs of rename/reparent/duplicate etc - Would this support make anything easier?
If we drag and drop elements from the library, we could probably target either Maya or USD for these operations? (mostly calling a function to add some hierarchy in either case?)
In the workflow outlined above, we would like to be able to target different layers e.g have a layer UI that allows us to select the appropriate SuperSet/Set/Section to target when making changes. Or perhaps it's more appropriate to try and specify "Target changes to my owning SuperSet/Set/Section - as each translated prim can only belong to at most one of each".
We already support this for transforms and visibility etc - you import a set, choose a layer to store any overrides, and make changes. In our Set pipeline, we don't normally allow the addition of new "setpieces" in override layers, although we do support various kinds of geometry replacement/substitution.
-
There’s a talk from Siggraph 2017 by Jens Jebens and Damien Grey called "Evolving Complexity Management on “The LEGO Batman Movie”" which describes the current pipeline in detail
-
Similar in some ways (but not in others!) is Dreamworks system Tiber