Difference between revisions of "UsdAssetGuide"

From cgwiki
Line 4: Line 4:
  
 
The clever folk at Sidefx did a fantastic job of taking a brief of 'what is an asset', and implementing it in Solaris and USD. This is my attempt to explain in non-USD and non-Houdini tech terms.
 
The clever folk at Sidefx did a fantastic job of taking a brief of 'what is an asset', and implementing it in Solaris and USD. This is my attempt to explain in non-USD and non-Houdini tech terms.
 +
 +
The plan is to start with a simple asset definition, and gradually scale it up in features and complexity. Once this is done, we might move onto how this then moves into layout and larger tasks.
  
 
=== Basic asset ===
 
=== Basic asset ===
 +
 +
The most simple definition of an asset would be a 3D model. Lets assume we want something more complete than that, and want an asset that contains a model and a material.
 +
 +
As such we need a few things:
 +
 +
* A model
 +
* A material
 +
* A way to assign that material to a model.
 +
 +
On top of these, we'll likely need a few other things:
 +
 +
* Names for the mesh and the material (self evident but worth pointing out)
 +
* Locations in a scene hierarchy for these to go; imagine the Outliner in Maya or Unreal, the Scene Graph in Katana, the Scene Explorer in Max. We should be able to say 'the mesh will be found at /Assets/myAsset/geometry/mesh and the material at /Assets/myAsset/materials/mymaterial' for example. Those scene hierarchies are up to you, but they need to be defined.
 +
* Location(s) to save this asset.
 +
 +
Why the optional 's'? Production pipeline diagrams will show a nice straight line between modelling and surfacing, but the reality is both departments are pushing work down the pipe at different rates at different times. In the simplistic model that would mean every time modelling published an asset, surfacing would HAVE to publish, otherwise no updates would travel downstream. Unfortunately a lot of older pipelines are stuck in this workflow.
 +
 +
But what if you could break that? What if you could specify a location on disk for modelling to save their work, another for surfacing, and have a third location that combines the two? That way modelling could save as often as they want, surfacing could even start before surfacing, and the asset will always get the combo of both.
 +
 +
In USD, it's possible to break an asset into layers, and define different save locations for each layer. In this case we'll define the geometry in one layer which is our final output, save the material into a different layer with its own save location, and import it to the final asset.
 +
 +
Let's go through these steps again in more detail:
 +
 +
* Create a 'main' layer, and store the mesh in it
 +
* Create a layer, define a material in it and a save location
 +
* Reference the material layer into the main layer
 +
* Assign the material
 +
* Write a USD file
 +
 +
Here's how that looks in Houdini's Solaris:
  
 
[[File:Selection_209.png]]
 
[[File:Selection_209.png]]
 +
 +
It's worth keeping in mind that those nodes represent basic USD functionality. The same steps should be possible in any 3d app that talks USD, maybe via scripting, or even outside a 3d app entirely and done purely in python scripting. And just as it should be possible to write that same workflow in any USD compatible app, it should also be possible to read that in any USD compatible app.
 +
 +
YMMV of course. :)
  
 
=== Adding Proxy Purpose ===
 
=== Adding Proxy Purpose ===

Revision as of 21:49, 1 July 2020

Introduction

A few people from Sidefx, Epic, Foundry, Tangent, ALA got together to have a chat about USD. Specifically that there's a bit of a knowledge gap between loading kitchen.usd and having a poke, vs actually implementing USD for a studio.

The clever folk at Sidefx did a fantastic job of taking a brief of 'what is an asset', and implementing it in Solaris and USD. This is my attempt to explain in non-USD and non-Houdini tech terms.

The plan is to start with a simple asset definition, and gradually scale it up in features and complexity. Once this is done, we might move onto how this then moves into layout and larger tasks.

Basic asset

The most simple definition of an asset would be a 3D model. Lets assume we want something more complete than that, and want an asset that contains a model and a material.

As such we need a few things:

  • A model
  • A material
  • A way to assign that material to a model.

On top of these, we'll likely need a few other things:

  • Names for the mesh and the material (self evident but worth pointing out)
  • Locations in a scene hierarchy for these to go; imagine the Outliner in Maya or Unreal, the Scene Graph in Katana, the Scene Explorer in Max. We should be able to say 'the mesh will be found at /Assets/myAsset/geometry/mesh and the material at /Assets/myAsset/materials/mymaterial' for example. Those scene hierarchies are up to you, but they need to be defined.
  • Location(s) to save this asset.

Why the optional 's'? Production pipeline diagrams will show a nice straight line between modelling and surfacing, but the reality is both departments are pushing work down the pipe at different rates at different times. In the simplistic model that would mean every time modelling published an asset, surfacing would HAVE to publish, otherwise no updates would travel downstream. Unfortunately a lot of older pipelines are stuck in this workflow.

But what if you could break that? What if you could specify a location on disk for modelling to save their work, another for surfacing, and have a third location that combines the two? That way modelling could save as often as they want, surfacing could even start before surfacing, and the asset will always get the combo of both.

In USD, it's possible to break an asset into layers, and define different save locations for each layer. In this case we'll define the geometry in one layer which is our final output, save the material into a different layer with its own save location, and import it to the final asset.

Let's go through these steps again in more detail:

  • Create a 'main' layer, and store the mesh in it
  • Create a layer, define a material in it and a save location
  • Reference the material layer into the main layer
  • Assign the material
  • Write a USD file

Here's how that looks in Houdini's Solaris:

Selection 209.png

It's worth keeping in mind that those nodes represent basic USD functionality. The same steps should be possible in any 3d app that talks USD, maybe via scripting, or even outside a 3d app entirely and done purely in python scripting. And just as it should be possible to write that same workflow in any USD compatible app, it should also be possible to read that in any USD compatible app.

YMMV of course. :)

Adding Proxy Purpose

Selection 001.png

Create an asset level variant

Selection 002.png

Creating Render and Proxy LOD variants

Selection 003.png

Adding material variants to LOD variants

Selection 004.png