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" [email protected] 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//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 [email protected] 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//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 [email protected] 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//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. :)