Yeah I’ve spent so much time in the past trying to make a ‘perfect’ connected conform the publish workflow and republish shot is really no different time wise. I’ve always preferred to spend the time up front to get things right, if possible.
Thanks again for your feedback!
Hello! Me again!
First off, thank yiu @cnoellert and @Josh_Laurence for your excellent explainers on this workflow. They have been incredibly helpful!
BUT
Am I correct in assuming you cannot use artist nicknames in your clip names in a publish workflow?
Or, if you are doing so, where are you stashing that token?
Hey @kirk ,
We don’t use the artist nickname token in our workflow but there is no reason that you can’t.
You can inject the token into the media path pattern but keep the OpenClip pattern consistent. Each user will write a unique render sequence (only diff would be the addition of their user name) but update a single open clip.
You could make this happen in Sequence Publishing using the Output Path Pattern.
Hi @kirk!
In my mind, the ideal place to put the <user nickname> token would be in the version field in the publish dialog so that the versions would also pickup the nickname. Since that field is pretty rigid in that it only allows the <version> token, that never flew. @fredwarren and I chatted about it back in 2017 and he confirmed you can add the token in the output path.
We did experiment with what @PlaceYourBetts is talking about but we then abandoned it for a individual color scheme in the saved desktop to help the lead refer back to the last artist that touched the shot. Each artist picks a unique color. The downside is it’s not in the filenames or setups, but it’s a really fast way to know who to reach out to and keep the names that much shorter.
Well, if it were up to me we probably just wouldn’t worry about them, but currently artist nicknames are embedded in the render name and that’s useful when dealing with a large number of shots and a large number of artists. I’m pretty confident that trying to eliminate that info from the process would be a non-starter, and this workflow is already a bit of a lift.
Separately, shots are sometimes broken up into many tasks, and that would need to be accounted for (hence the write node question from the other day), both in terms of how to incorporate pre-renders and their associated setups into a publish-style workflow, and figuring out who did what when reviewing shots and dishing out feedback.
More broadly, what I am trying to achieve is the promise of the publish workflow in terms of seamlessness and improved quality of life for artists with fewer metadata mistakes and less hunting for renders for leads, but without giving up any of the benefits of the current workflow (mainly speed and reliability). Just like me, the publish setup seems powerful, but fragile, and in a big organization with a ton of machines and a large number of artists, I think it’s important to study the thing pretty carefully if only to know what to do when something goes wrong.
I’m testing all of this right now, thus the questions, but initial findings suggest that in situations where one is just delivering shots and not a complete timeline, you wouldn’t have to archive at all at the end, and that alone would reduce a TON of artist workload. Add in all the cool glue and clips just showing up where you need them and it’s something that deserves the duest of diligence. Thank you for helping me get this far with it!
Great to know. Thank you!
It’s a good thing to have a play around with @kirk .
The whole Sequence Publish thing was a revelation on par with the connected conform for me.
Export your shot sequence (all of your shots) to a folder structure of your choosing.
Have it create v00 batch group setups which include writeNodes customised to your liking and rendering to the correct destination in your custom folder structure and it will make the OpenClips for every shot and have these imported back into your timeline once the Publish has completed.
Sounds almost too good to be true!
How we have dealt with different tasks and pre-renders…
We make a small tweak to the writeNode that comes preloaded with the v00 batch group.
By modifying the Shot Name found bottom left (circled in green bottom) you can use the token <shot name> to modify the render pattern, openClip and even setup in one go. It helps if you also add the <shot name> token to this writeNode name (green circle top)
If you add something like _preRender1 to the Shot Name (or _cleanUp) you can get it to create a new render sequence and a new OpenClip all with the same folder structure.
If you also Include Setup (underlined in red) that OpenClip can be pulled into a batch and expanded the same way a BFX does. It will effectively append that preComp setup into your current batch.
For example the senior can start the main comp while an assistant does the clean up. When required, the main artist can import the clean up OpenClip and use that in the setup. This OpenClip can contain future versions and if required it can be expanded so that parts of the setup can be accessed.
That’s excellent! Thank you!
On your note about user nicknames, I did notice that appending the token to the Output Path Pattern results in a clip that, when you alt-hover over the segment, shows you the artist name as part of the clip path. That may do the trick, but I also may be called upon to surface that info in a more obvious manner.
Regardless, I especially appreciate the visual aids. Helps penetrate this thick, dense skull of mine.
Ahhh! This is where renaming clip with the Dynamic button switched on will help @kirk
When you version up an OpenClip is doesn’t automatically change the name. Unless you use tokens in your rename clip and have Dynamic switched on.
I use it exclusively for keeping my version number up to date <source version> but theres no reason you couldn’t use the <segment name> and have that update with the artist nickname.
We use a lot of metadata burn in and this helps to keep all of that current 
Haven’t had time to fully write a reply—this weekend’s been hectic, but @PlaceYourBetts, just want to point out that the only reason changing your shot name as above leaves the resulting renders and metadata in the same shot directory but appends a “_prerender” to the directories it creates within that shot, is that at publish you are using <nim shot root> to define your shot root directory in your publish template which later gets variable substituted at publish into the shot name as opposed to remaining dynamic.
For someone not using NIM, a <shot name> token most likely exists in their output pathing meaning that if you did as above and changed the shot name in anyway, at render you would create a new shot in your folder structure. You would need to be using a NIM or the like for your example to work and keep it under a single shot name.
The quickest way to semi-automate would be to have someone write a bit of Python that does a couple things to your write node. First, changed the characters “COMP” in your file paths to “ROTO” or “PRECOMP” or whatever other tasks you need. The second would be appending an artist nickname if you wanted it. As you discovered you can pack a render named pretty much anything into an openclip and they will be considered as a version.
This can of course be done by hand and manually edit the paths but something like @MikeV paint node fix where you select a write node, right click and change it to “PRECOMP” and have the internals just edit your paths is the way to go.
Edit: There is another way to manage these obstacles that’s pretty powerful though, I’ll see if I can write it out today at some point.
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.
Chris! I love your ground rules and pre-pending the <version> number with a whole word! Does each team member do the writefile adjustments or does that only happen from the lead prior to distributing the shot for work? Maybe that’s a way for @kirk to add the artist’s initials - just tell them to prepend their version numbers? Guaranteed not foolproof, but a pretty easy way to inject that info into the render.
Hey Josh, glad you dig it. It doesn’t really matter who makes the write node adjustments as long as they get done–guess it comes down to how well informed the artists are versus the lead, but I see the strongest argument in letting a lead setup and distribute–especially since it’s largely just a save as disguised in a render and because then they can create tasks ad-hoc.
Regarding the artist initials in the version, that could easily be a use case. Like I said there are a couple of different things going on here. The first is setting up different iterative tasks for the same shot each operating within a defined range of iterations. Now, what you define as an “iterative task” is up to you.
For example, Kirk, Chris and Josh could be the artist pool working on pieces the same shot–say doing tracking, roto and comp respectively. Do you subdivide the iterative ranges up by artist then or by tasks? I could easily be then that Kirk gets 200-299, I get 100-199 and you get 0-99 and our prefixes are KIRK, CHRIS and JOSH. That makes sense if it’s multiple artists per shot. But as we discussed the version prefix can be anything. So does ROTO_CHRIS_v<version> make more sense? It may. There’s more info there for sure. It’s up for grabs.
Likewise if it’s just about shot assignment and not multiple tasks/element types per shot one could forgo the iterative ranges and just change the prefix to COMP_JOSH_v<version> or even just JOSH_v<version> because really the ranges aren’t needed, until they are. But that’s the beauty of this system, iterative ranges could be created on a per need basis, which is what I was eluding to earlier. SO you allow the system to get as complex or remain as lean as you want it to be. That’s why comp starts at the lowest range with the other subtasks being given higher ranges that way you can build complexity as needed.
Anyway. It’s a hack to a system that has a lot of power but a lot of holes.
Chris!! Yours is definitely a system with a lot of flexibility, and you’re exploiting it really well with the prepend. The upside of this is that you get an added level of functionality in the same Output Clip. Very very clever stuff.
In our workflow, we don’t use Iterating at all (we rely on the external setups), but that also means we’re working with the Custom Versions which (I think) have a max limit. I think the way you have it set up with Follow Iteration is a great way to circumvent that max.
@kirk - A word of warning… the user nickname token inclusion might break one of the things I really like about publishing in two ways - the unique-ness of each version and it might create hidden renders. Here’s what I mean: User jk grabs a batchgroup, works, renders <shot name>_comp_<usernickname>_<version> and the following results: Interview-sh0030_comp_jk_v001. Then the next artist - jl - grabs it and does something then renders and we get file Interview-sh0030_comp_jl_v001. Both v001 but they’re delineated by initials and not versions. The latest render by jl is the only one that shows up in list of versions because it was last and you don’t get the feedback @cnoellert is getting with the prepended info prior to the version. You also get two renders in your /v001/ directory but only one accessible from the Open Clip. If you’re prepending the initials manually in the version field in the WriteFile, you won’t get a hidden render. Both v001s will show up in the list - but with different initials.
To sum up: if you include the <user nickname> token in the output path (5th tab) then no extra info in the pop up list, and potential for hidden renders. If you manually prepend THE SAME INFO in the Version field - unique versions and it shows up in the pop up.
I think this is why I asked @fredwarren to give us initials in the version field way back when… so we could audit from the pop-up and it was automatically added and didn’t need adjustment from users with different levels of interest in modifying the WriteFile node. But Chris’s solve for that is really great.
