Maya pipeline: Scene Assembly, Assets and referencing

Maya pipeline: Scene Assembly, Assets and referencing

Anonymous
Not applicable
1,696 Views
1 Reply
Message 1 of 2

Maya pipeline: Scene Assembly, Assets and referencing

Anonymous
Not applicable

Hey,

 

Story

We've been using referencing in a reliable manner for a couple of years but are in the need for a step up, specifically regarding scene layout and animation scenes.

 

Our pipeline separates an asset's geometry from its shader allowing us to have the same tree hundreds of times where each have a shader variation. As such it is the exact same asset, yet only with a different shader assigned. This is something we've been using succesfully and has been applauded by the team. This way it also allows us to develop multiple shaders for a geometry whilst modeler/lookdev artist work on the asset at the same time, because the extracted data at the end (geo vs shader+texture) is separated as a step in the pipeline.

 

So far we've been rebuilding render scenes after animation based on Alembics and other cache format and then dynamically loading the shader variations through our own proprietary asset management. (As such a piece of geometry is separated from its shader)

 

Goal

What we're looking for now is a way to work in heavy scenery with lots of geometry and being able to still move around and play back in the scene without too much hiccups. And especially have good control over how this heavy scenery is represented.

 

- Switch between representations: low, proxy, locator, disabled or animatable solution.

- Switch between shader representations/variations: e.g. a red car and blue car would be nice to be differentiated in preview even if they are using the same "model" or "rig"

- Load the least amount of data to work. If I only want to see a "gpuCache" proxy don't load the high-res geometry on scene open. (As such hiding in the scene doesn't suffice)

 

Implementation

The Scene Assembly has been looking great for us since it had the ease of use of loading what the artist needs and have them be able to switch between representations so they can work optimally. This is great!

 

The only problem is that it doesn't allow us to take our "shader variation" idea along where the geometry doesn't contain it by itself and it is dynamically assigned (e.g. a red/blue representation) because scene assembly doesn't allow shader assignment.

 

Actually all we'd need is having the assets we make get referenced in into their own container (like the scene assembly root) and be able to switch around its contents (children) based on the choice of representation and support all reference edits onto that representation (like a regular reference). That way we can assign our shader variations with our tools, and also apply deformers or other cool stuff that's possible on references.

 

Is something like this possible? And what's the recommended workflow?

 

0 Likes
1,697 Views
1 Reply
Reply (1)
Message 2 of 2

Anonymous
Not applicable

So I've had another look at the possibilities here at doing a custom plug-in to resolve this.

 

Custom MPxFileTranslator

 

This would allow me to define my own file format that could be referenced that would ensure the correct loaded format and always having a root transform with the same name.

 

By implementing a custom MPxFileTranslator I got quite far since it would allow me to load any file format (.ma, .mb, .abc) in a customized manner. For example I could define my own file format ".asset" being a JSON data structure. This could hold a reference to other files, e.g. "proxy.abc".

 

When it would encounter an Alembic it would load that as gpuCache, when it would find a .ma, .mb it would load it as a Maya file. And at all times these would be grouped under a root transform, root_AST. This way no matter what I would load it would be contained under a top transform.

 

This supports all reference edits (woohoo!) and has the consistency of always having the top transform (no matter what "representation" is loaded). Though the FileTranslator just takes a file from the reference and doesn't now which file it would need to include from the representations (since it doesn't have access to the particular reference node in the scene).

 

Custom MPxAssembly

 

I've also been looking into deriving MPxAssembly but it seems that the lack of relationship support (shaders, deformers, renderLayers, etc.) is native to the MPxAssembly, so even deriving a custom one and trying to hack and include it wouldn't solve the problem. Basically I was unable to get lucky here and find a "way" through where I could enable support for relationship edits and have them stored on the assembly reference like any regular reference.

 

Any pointers?

 

 

 

0 Likes