By the way, I added another variable take to the summary above.
@BigRoy, if not wedge, is take a better term for the “variations”?
Found an explanation of the term from Cinema4d.
1 Like
True, but as some producers would say ''when artists refuse to do it, they are out of job". Realistically we never had any troubles with people not doing it. I just know that if given a choice they certainly drop some requirements
Of course. I actually really like the idea and it kinda goes with what we are discussing here, which is making it easier to connect remote freelancers to our pipeline when they work for us, which would be holy grail of outsourcing. Send a shot away let them to their thing, and get it published back to studio from whereever they are. But that’s for another discussion.
Very very similar to Houdini’s takes http://www.sidefx.com/docs/houdini14.0/basics/takes
We use these on a daily basis for exactly these purposes.
Lighting output
So it seems output from lighting is quite different from other tasks, like modeling or rigging.
In modeling, there is 1 output with optional extras, such as a turntable or additional formats. Lighting seems to wrap multiple outputs, each with it’s own optional extras. As though an artist is working with multiple models at the same time.
Does that sound about right?
What is an Instance
I’m struggling to wrap my head around exactly what changes during lighting, because that’s where the separation needs to happen; each Instance will essentially be given it’s own physical version on disk, so whatever we choose to become an Instance should be the element of the scene that requires this versioning, the element that can change independently from others.
Does renderLayer sound like a good fit for this? To rephrase the question, is there any variable of the other 7 mentioned in the summary that can change independently such that it requires it’s own versioning, apart from renderLayer?
Tricky, considering that these are handled differently by different softwares, but in maya I’d definitely go for renderLayer. In Houdini renderLayer could apply as well, even though instead of ‘renderLayer’ instance would have to collect mantra node (each being equivalent to a renderLayer)
Not necessarily.
A model could be published into different “versions” like “high-resolution”, “low-resolution” and maybe “proxy”.
Don’t you think?
Yes it does. (As before, only other separation could’ve been camera or “take” as it has been described here.)
I think take is the clearest term for shot variantions. Not someting you would have to explain to every new person you work with.
Currently our output images from v-ray for instance read: layer.pass.####.extension. Might be a good idea to use a . instead of an - just for overview purposes? Feels a little shorter;)
I’ve been using that for years until I ran into issues with some programs that don’t like . in the filenames, Or rather expect anything after a . to be a frame number or extension. Kill me but I can’t for life of me remember where these problems were appearing. Anyways for about a year now we’ve switched to _ separating name tokens and leaving . stricly for separation of a frame sequence and extension.
You could always just playblast versions separate from scene versioning I guess. shot010_v01_v01? shot010_v01_v02 or would that beat the purpose?
Fair enough;) I haven’t run into any issues with this so far, but I get the risk of using seperators like that.