-
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 multi-level recursive structures, which are referred to as “stages”. They are named according to their level in the 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.
The stage files are just a simple hierarchical structure of attributes e.g
- name
- transform
- assetreference (to an item in the next level down of set hierarchy...so a Set contains references to Sections etc)...
..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 Etc
When we translate to maya, transforms in the maya hierarchy which are root nodes of stages or setpieces 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
- 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 a specialised bidirectional Set translator to and from maya which we will need to write
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
An alternative (more USD centric) 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.
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?)
-
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 is Dreamworks system [Tiber])http://delivery.acm.org/10.1145/2620000/2614122/a56-low.pdf?ip=110.175.43.69&id=2614122&acc=ACTIVE%20SERVICE&key=4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E91A84F226C8F565B%2E4D4702B0C3E38B35&__acm__=1518909969_15eddaaa4b0e566a0a8be0be55950f14)