Let’s give this is a try.
The aim of this approach is to mux a diverse group of element types into a single openClip with the ability to dynamically view and load the metadata associated with those diverse types. This technique relies on establishing an id range for element types that gets directly mapped to the version number alongside a plain text version prefix.
We’ll start by setting up a few ground rules. First version ranges:
Comp 1-99
Precomp 100-199
Roto 200-299
Denoise 300-399
Why is this important? Openclips have two parameters that are of importance in this instance. A path and a version number. If we want to store all of these element types in a single openclip, they’ll need to have both independent pathing and non-overlapping version numbers. Independent pathing is obvious… if I overwrite path/to/comp_v1 with roto then the image data for the comp is gone. If I try to append an openclip with two unique source data paths but with the same version number I’m effectively doing the same. Since in order for our element types to coexist we need to have non-overlapping version numbers, these ranges are important.
Next, we’ll establish our prefixes. This is easy, we’ll use:
COMP for comp
PRECOMP for pre comp
ROTO for roto
DENOISE for denoise
Why is this important? In openclips when we select a version to view it will show us the complete version name not just the version number. So using our ranges above, it won’t just show us 100 for our first pre comp version, it will show us the entire name so if we prefix our version number with something more informative than v–say PRECOMP_v that’s what will appear in the version selection popup in the open clip, or in this example PRECOMP_v100.
Now how does it all work in practicality?
From a standard shot name publish I’ve been assigned to do some roto shot honk_080. It’s got no versions of anything associated with it–its current batch setup is v00
We navigate to that shot on disk from batch and load it’s 00 version. First thing I do is update the write node to follow version and I append the task to the version–in this case ROTO. I’ll also update the batch group name on the desktop with _ROTO so I know what the fuck I’m doing.
I’ll add a mask tracer and roto some bits of the car I know I’ll need. Then I change the file write type to jpeg. Why? There’s no reason to write out DPXs in this case for simple roto–especially given that I’m really only going to use those files for viewing as you’ll see later on.
Next I’ll “iterate as” and set my iteration to the first agreed upon iteration in the range for my task which is roto–in this case 200.
I’ll render then and go back to the desktop. If we select the version popup for the openclip loaded on the timeline for shot 080 we’ll be rewarded with the first cool thing about this approach.
The version popup shows us that our we have our 00 version which is really just a reference to our source plate AND a second version called ROTO_v200 which we just made. We can select that version and play it. Flame doesn’t care that it’s jpgs and happily plays it and switches between that version and the original.
So we’ve successfully embedded one element type in the openclip. Now let’s do another. We go back into batch and load the v00 of honk_080 just like we did to create the roto stream. We can see that the batch setup exported at our previous render also updated the name to reflect our version change so we see setups for honk_080_v00 as well as honk_080_ROTO_v200.
In our fresh v00 of the shot, we prefix the version name again, this time with comp. We also append _COMP to the batch group so shit doesn’t get confusing while we simulate multiple artists on a job. We also change the write node to follow iteration and iterate_as to iteration 1, which is the first available iteration in the comp iteration range.
We’ll load an image from disk next, track that onto the side of semi and render our v01 of the comp. After we render, back to the timeline and the version popup for honk_080 and we’re rewarded with multiple asset types in the openclip stream!
From this point both streams can update as they normally would, incrementing upwards from their base number–so the next version of roto is 201 and the next version of comp is 02. So for example lead artist says hey, add the wheels to the roto, roto artist, adds the wheels to the roto, clicks iterate_as and increments for that version 201 and then just renders.
As expected each new iteration, regardless of asset type will be reflected in the honk_080 version popup accordingly.
Now for the fun part. Let’s use that muxed stream for something useful. In the comp batch we right click on the write node and select “Import…:Import Clip to Batch” which is this stupidly useful Login Portal script that will import the selected write nodes’ openclip into the current batch setup.
Once that openclip is loaded we can select it, make sure that in the version selection popup that we have the latest version of our roto selected, ROTO_201 and then hit the “Append to current batch button”
We’re rewarded with a grouped version of our latest roto batch, which we immediately ungroup (well at least I did for this screenshot).
We grab that roto, make some small changes to our car and render or V02 of our comp. Back on the timeline we’re rewarded with a v02 of our comp stream. Pretty fucking cool.
Now I won’t go through setting up the other asset types–but by following the instructions for roto and comp and just adjusting the parameters you’ll be able to get those going no problem. Then the lead can not only load a simple render of a specific asset type like roto as jpgs as opposed to a heavier format, but the lead can also just expand out the setup and make changes on the fly–all streams contained within a single openClip. Shmancy as hell.
This setup could also be adapted for different users as opposed to asset types. Each artist gets a version range, but I think the asset type makes more sense. Hope this helps @Kirk.
Edit: Our default template has output paths including “COMP” between the shot name and version resulting in output paths that look like honk_080_COMP_COMP_v01 and honk_080_COMP_ROTO_v201 when using this technique. This can be solved by adjusting the initial publish settings to not include “COMP” in the pathing. Then your paths and naming will look a little more sane, i.e. honk_080_ROTO_v201 or honk_080_COMP_v01.