Small studio - New Pipeline

Hello! Great forum!

I work at a small studio and we do product visualization (stills/movies). We have limited time/knowledge to focus on pipeline development and therefore our pipeline is very basic and not very robust. I will try and rebuild parts of the pipeline to make it better. I hope to get some suggestions/tips from you guys!

We do all our stills and video work in maya and nuke (with some editing in after effects).

This is our workflow at the moment (see attachment). We have scripts for publishing and automatic shader assignment.

The problem with our current way of working is that maya render layers keep breaking in the lighting scene. (probably because of all the shader assignments going on in each render layer)

I guess one solution would be to assign the shaders before they get referenced into the lighting scene? But then I would need to publish one shaded model for every shader variation right? And that would make things a bit messier in the lighting scene (more models to worry about)

What’s your thoughts on shader pipeline after lookdev is finished? What would be the easiest solution for a small studio?

I will later try and post my progress and solutions so that others can benefit!

Cheers!

I can’t open your attachement fsr? I’ve had some success with renderlayer shader overrides, rather than using a standard shader override, instead create an attribute override on the shadingGroup.surfaceShader attr for each render layer. So the shader override become a shader->sg connection override. It makes it much faster to switch between layers in heavy scenes, and it also respects stuff like displacement nodes that may be connected to the SG.

Thank you for your reply!

Do you mean making an override here? (see attached)


I’m not sure I’m following exactly what you mean. Would you do overrides on every “surface material slot” for every shadingGrp? Would you do the overrides only to create the shader variations?

I’ve updated my attachment in my previous post, hope it works better now!

Cheers

Yes exactly. So something like
masterlayer: phong1 -> sg.surfaceShader
renderlayer1: blinn1 -> sg.surfaceShader
renderlayer2: holdout_matte -> sg.surfaceShader
etc

If you use mental ray you may instead need to override sg.miMaterialShader, or if redshift sg.redshiftShader etc…

It is fewer nodes and connections than a normal renderlayer shader override, especially when there are many objects in the scene which share the same shader. Unfortunately the viewport doesn’t really recognize that the shaders swap out when you switch layers so the viewport representation gets a bit messed up. But that was a small price to pay for shader overrides that worked, and didn’t take 20 minutes to change layer

// edit if your shader variations are simple colour changes as in the diagram I would be tempted to just use render layer attr overrides on the .color attr on the shader and save yourself the bother entirely of shader overrides :slight_smile:

Sounds interesting. Thanks for the input!

1.In the render scene: Would you reference the asset with all shaders already assigned? (shaders get assigned in the lookDev publish)

-Let’s say I reference in the “black” version of the product.
-Assign the product to a render layer
-When I want my shader variants I duplicate that layer and then make the shadingGroup overrides you mentioned.

  1. Or would you reference the model and shaders separately, assign the “black” shaders to one render layer and make overrides for the variants?

I’m guessing option 1 is the way to go? (option 2 is pretty close to what we already have)

Whether to separate shaders from the model depends on how you want to design the workflow. Maybe it’s important to have separate model and shading artists working in parallel on the same asset? Maybe the modelling is done in a separate app to the shading? Maybe it isn’t and your look dev artists need to do UV tweaks on the model as they work on the shaders. It’s hard to comment knowing nothing about your workflow, but I’d say unless you have a good reason to separate the shaders and the models into separate files then save yourself the headache keep them together in the asset. Otherwise prepare to support: face based shading assignments, different shaders assigned to different instances, displacement (and other) nodes that may also be plugged into the SG, something to rebind shaders to meshes when they inevitably get renamed.

Hello!

I’ve now rewritten most of our pipeline based on your advice. It’s working great so far and no render layers breaking. We are now exporting the model with shaders already assigned (from the look dev scene). And in the lighting scene we create color variations in each render layer using a script.

Many thanks for the advice!! Never thought of using SG overrides for this.