-
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 we call “stages”. They are named according to their level in the hierarchy
The leaf nodes are referred to as a “Setpiece” (e.g individual building in City Block)
A Setpiece contains geometry and maybe materials.
The stage files are just a simple hierarchical structure of names, transforms, attributes and references to items lower down in the hierarchy (so a Set contains references to sections etc)... not unlike 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 pathname in the scenery hierarchy)- so 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 parts of the hierarchy
- Add, remove, rename group nodes
- Add, remove, rename stages , setpieces
- Move, transform groups, stages or setpieces
- Add/Modify attributes
- Choose variants etc
….and as long as the relevant scenery attributes 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.
-
We’re working on “Geometry Translation & Editing” in USD at the moment - 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 USD Stage, the USD data gets flattened and we lose references and other composition operators in the original USD stage - unless we can extract some of this data and write it into the translated maya hierarchy (the "breadcrumb" approach - a bit like what we do with our current pipeline). This requires specialised translators to and from maya which would be a pain to write, and as we are also dealing with a flattened hierarchy, it makes it difficult to write back specific data to specific layers.
-
A better workflow might be to be able to select individual groups or setpieces in the 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 UFE might want to do? 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.
-
Another approach would be to translate the entire transform hierarchy minus the geo, have the maya transforms drive the USD transforms, and use maya to do all of the hierarchy manipulation? (need to think about limitations)
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