To skip all the details stuff, cuz you're busy people, go down to THE BIG QUESTION below. You can always come back here if you're asking “why does this guy want to do this?”

Here we run all submissions to the render grid via a python program that has numerous parameters. The entire purpose of it was to ensure that how the animator saved the hip file has nothing whatsoever to do with what is submitted to the grid - all necessary information to render a sequence is provided by the command call. This eliminates such common mistakes as saving with an autogen turned on/off, the ROP that is used for final had a param changed for a quick test and was neglected in being reset, etc. A brand new ROP is created at submission time, along with various states being set based on the command line arguments. This eliminates a *lot* of problems.

Enter “takes”…

Takes are amazing, make no mistake. We want to include them in our pipeline, however we've run into a snag. The nature of take's implementation are at odds with the methods we use. It almost *requires* the user to save the hip in a particular state. That's a non-option for us. Regardless of whether or not a given take has a given parameter set, the user may want to set that via the render call. The way we currently do it is this:

1. Note ACTIVE_TAKE upon loading(this might even be ‘hip’).
2. Switch to the parent “hip” take, where everything is enabled.
3. Do our thing - display the correct objects, set flags, allow for user pre and post includes, etc.
4. Switch back to the original take from step 1.
5. Submit.

Now this works reasonably well, except for a lot of things like object display. Typically in a take, you'll toggle the take display of an object so you can see it while you work. Problem is, now it's attached to the take, so the display state of that object overrides what you may want in step 3, above.

We've figured out we can address that with

takeinclude -u -d /obj/*

being run in step 1. This takes the display state and removes them from the responsibility of the take so when switching to “hip” and back, it respects “hip”'s settings. However, what about all the other channels, like matte, phantom and all the other channels in the SOPs below?



THE BIG QUESTION:

The problem here is that anytime the animator wants to quickly toggle something or alter something in a take, they need to add that channel to the take, thus that take now aggressively *sets* that value over top anything we may want to do with scripting. Is there a way to very quickly and easily, in one line, do something along the lines of:

takeinclude -u -d /* *

but completely recursively? That way we can use all the settings that were set when the animator saved things, but we have the ability to work *on top* of that with freedom. That seems to be the simplest solution to our problem(which, if you've got the time, you can read about, above).

Unfortunately, takemerge'ing the take into the hip with a “force” doesn't work either, because a given take can consist of many other settings from it's parent's takes, which wouldn't be included here.

Thanks!

J.C.

Hi John,

This coincides beautifully with an RFE I have to either have takels report take heirarchy information in a usable way, and/or for there to be a new "takeflatten “ command which would flatten the entire take heirarchy down to the hip level.

Currently I force the artists to put all the parent takes on the line - which is counter-intuitive. i.e. - you must specify ”takemerge hip a b c d“ if you want ”d" to actually set the chosen take and be able to opparm random parameters.

Perhaps we could have a command that allows a takeset to be run in hscript mode and allow opparms to be executed without having to takeinclude them - like a takeautoinclude.

Long live Takes!

Just between the three of us, there does happen to be an auto include mode for takes in a forth-coming version of Houdini. In which case, your work flow could become something along the lines of:

1. Add new take to the active take (though you could just use the active take).
2. Enable auto include mode
3. Do your thing.
4. Submit.

I guess it's also a workflow thing. Due to some bugs in 7.0.xxx I struggled using Takes on Elektra, with some success (and some failures).

Also, we (R+H) have wrapper scripts when Houdini is loaded that have to be modified since if you load a .hip file when it's not on the Base take, scripts can suddenly fail since they can't modify things that you'd expect them to be able to modify.

At R+H queue submissions are handled within Houdini by a special ROP, so ti's fairly easy to make sure any ROPs that are for q submission have a “takeset xxx” as part of the pre-render field.

Also, so far it has been up to the TD to make sure that any specific take is “render ready” and if you want to do quick tests, you do it in a different, “test” take. If a “render” take fails to render, it's the TD's fault but there's really no excuse.

John, I'm curious, how is the data that creates and configures the new render ROP entered? At some point, a human has to say “these are the parameters that need to be set thusly to render” so why not build that into a Take, making sure to call it “_render” or something?

Perhaps I'm missing something

Cheers,

Peter B

Thanks for all the responses, guys. Ondrej, the auto-include mode you mention would exactly fit the bill for us, eliminating hacks like manually enabling *everything* and letting us use the command-line specified take as the starting point to apply the rest of the params. Since you suggest it's forthcoming, I don't think I'm going to blow my brains out trying to hack around this…enforcing some rules as Jason has done will be the workaround for now. Hopefully the beta's coming soon , and that will tell me whether or not it's really close on the horizon.

I still think Jason's RFE is a good one, though. Those take generations can be a real bugger to navigate and here we don't like a lot of rules for animators. The more rules, the more likely they'll be broken(accidentally or not), and then more failures. We like to assume nothing except the animator knows how to use Houdini.

Peter - here the TD is essentially the render submission line. That's the thing that takes all the params that are (admittedly arbitrarily) chosen to be things that one might want to submit with any given render pass. Add to that a pre/post include option, and the command line is all-knowing - what will render is clearly defined there on the line, and it's consistent. We wanted to completely avoid the typical problems in the past where an animator might accidentally save a hip with the wrong object displayed, the wrong SOP set to render, etc. Using takes to do that puts things right back into that camp. With a script line, it's right there in text, and typically for a given pass you never change it once you've got it setup properly. One line is easier to read then manually hunting throughout a hip looking for all teh variables. It's OK to have a “fiddle” take - but if the user does something valuable there, they need to stuff it back into the official take. About the only way the animator can screw things up is spelling a group name incorrectly or accidentally deleting the wrong channel, that sort of stuff. I've just added the –take param and have suddenly run into this collision between that “assume nothing” mentality and the opposite with takes.

You can look on the Digital Assets site, under Scripts or Other I think, for gren.py - that's a version of this program that I had submitted.

Cheers,

J.C.

The autoinclude functionality sounds like it'd do just what we'd want - thanks for the clue, Ondrej.