Design tools for render and composite pipeline

[eestrada]

For most of our films the pipeline for model/rig/animate has been fairly well defined, but our pipeline for the second half of the pipe is pretty weak. Asset management and shading are getting much stronger, but rendering and compositing are still poorly defined; people can put their renders anywhere/everywhere and use what ever format they want. Compositing is similarly ad hoc.

This issue is more about design and planning than actual coding.

[bkingery]

For every shot there is a versioned 'compositing' folder. I was thinking that we could implement a checkin/checkout for nuke?

We could also put a 'renders' folder (or something of the like) in the shots folders.

[eestrada]

I was thinking along the same lines for compositing. In the tutorials section of the wiki i put a link to the Nuke python dev guide. From what i can tell the python UI code is similar to Houdini so it shouldn't be too hard to dive in. Toolbars are less common in Nuke so we may have to do it as a menu.

The next question is enforcing render locations/formats for lighting artists. I was thinking we could possibly modify the presets for the Mantra node to use environment variables or something. Maybe we just hide the whole "Output" tab on the mantra node and only have a dropdown box with two options: "mplay","To disk". To disk will have the disk location based off of the location of the scene file or something. On Feb 26, 2013 4:37 PM, "bkingery" notifications@github.com wrote:

For every shot there is a versioned 'compositing' folder. I was thinking that we could implement a checkin/checkout for nuke?

We could also put a 'renders' folder (or something of the like) in the shots folders.

— Reply to this email directly or view it on GitHubhttps://github.com/byu-animation/byu-animation-tools/issues/90#issuecomment-14147115 .

[bkingery]

As long as that doesn't hurt the artists troubleshooting abilities. I know people like to render to disk for testing/troubleshooting purposes....

we could perhaps also include a "To User Folder" option... or we could just make the "To disk" part of it part of the final render settings....

I don't know, just some Ideas.

[eestrada]

Good ideas. This is why I started a "Design" issue so that we could figure out solutions for these sorts of contingencies.

We could also figure out a checkin/checkout system for renders so that lighting artists can created backup version by checking in/out their scene files. However, I worry about that sucking up disk space crazy super fast.

On Tue, Feb 26, 2013 at 4:59 PM, bkingery notifications@github.com wrote:

As long as that doesn't hurt the artists troubleshooting abilities. I know people like to render to disk for testing/troubleshooting purposes....

we could perhaps also include a "To User Folder" option... or we could just make the "To disk" part of it part of the final render settings....

I don't know, just some Ideas.

— Reply to this email directly or view it on GitHubhttps://github.com/byu-animation/byu-animation-tools/issues/90#issuecomment-14147908 .

Ethan Estrada

"Education is a progressive discovery of our own ignorance." - Will Durant

[bkingery]

Are you talking about checkin/checkout for the lighting files (if so that is done) Or are you talking about backing up the rendered shot files? (I think this is the one you are talking about, which yeah, would suck up space pretty fast)

[eestrada]

The second one (rendered image files). Although, I know for me, when I light I usually keep 3-4 different versions of my renders around anyway. If we just did the same thing that we do with models and throw out the old renders past the most recent 3-4 we could keep disk usage reasonable. I just want it to be organized in some fashion. If lighting artists know where their renders are landing I don't think there will be an issue for troubleshooting. I just know I end up using poor naming conventions and placing renders in odd places when not forced otherwise (and most lighting artists are the same). Making the renders part of the checkin system along with the lighting makes sure that the most recent render is always readily available in the pipeline. We should talk to Dan and see what sort of system they had a Pixar. I can also talk to my brother and find out what the rendering pipeline was like at Imageworks and Dreamworks in this regard.

On Tue, Feb 26, 2013 at 5:21 PM, bkingery notifications@github.com wrote:

Are you talking about checkin/checkout for the lighting files (if so that is done) Or are you talking about backing up the rendered shot files? (I think this is the one you are talking about, which yeah, would suck up space pretty fast)

— Reply to this email directly or view it on GitHubhttps://github.com/byu-animation/byu-animation-tools/issues/90#issuecomment-14148752 .

Ethan Estrada

"Education is a progressive discovery of our own ignorance." - Will Durant

[nstandif]

For the rendering pipeline, it could also be useful to output the mantra log somewhere, too. Often times, things never render and go unnoticed because of bad shaders, dlps, geo, etc. I'd like to have it separate log for each frame, but it'd be fine if it were in a single file as long as it's there somewhere.

[eestrada]

@nstandif I agree about render logs. HQueue does have the render logs of each frame based on the verbosity level of the mantra node that created the initial IFD file. It would be nice, however to find a way to dump this on disk so it is easier to do things like grep and diff log files. I doubt these files would take up more than a few hundred KB apiece at the very worst.

[eestrada]

Did some general Nuke pipeline stuff in merge #115. I think we can bend Nuke to our will a little more, but for now we can at least load custom scripts, plugins and gizmos. :)