first post so hello
I’m trying to simplify the workflow and want to lean heavily on openclips.
Our pipeline is automated and shot based which makes it quite unfriendly for Flame artists. Shot renders live in somewhat complicated paths and with no pipeline integration for Flame we needed to find a solution that will save them at least some time. Hence openclips.
We have scripts that create .clip files from 3d renders and/or Nuke comps and update them when new version is published. The problem is 3d renders.
When I update an openclip with a render that has more passes than previous versions (eg. v001 is rgba, zdepth - v002 is rgba, zdepth, specular) the clips do not version properly.
Do you guys know of a way how to retain versioning in such a situation?
That’s a tricky one. Openclip and pattern browsing seem to look for subsequent versions that are exact matches (save for versioning), of the initially created/imported clip. A change in folder/filenaming syntax, or in this case, added render passes breaks it.
I wonder if you crack open the .clip file as txt, if you can ascertain where/how the number of 3d layers live, and see if experimenting with (#) n-type ordering might give it some flexibility? Just thinking out loud…
@PandaVfx
One cool feature that I was oblivious to until just recently was the context option in batch, “Replace From Media Hub”
You might already know this but right click on a clip and select “Replace From Media Hub” will take you to the location on the server of that clip and you can replace it with the update.
No need to navigate through deep tunnels of verbose folder structure. You just come up a level or two and select the newest render.
Not as elegant as an openClip i’ll admit but helpful.
It may not work for arbitrary named AOVs (like PLOs) but you can create the initial .clip file accounting for upcoming known passes. I think @La_Flame did a tutorial on this method.
Actually I had no problems in getting CM to work in openclip. I create the .clip file myself, completely bypassing Flame so it’s… barebones , only stuff I need without all the bs that FL puts inside.
That will only work if you know what passes will be needed. Our rule of thumb is rgba + zdepth and then adding stuff as needed. Problems come when 3d artists make unannounced changes to the layer stack
I tested that adding layers to the current version doesn’t break so I need to test if updating previous versions with empty new passes will work.
I would recommend using Pattern Browsing for the multi-versions workflow involving new passes being created. if you create an Open Clip referencing a Multi-Channel EXR, you have to define the channels per version so they can be seen in Flame. That could be difficult since new 3D renders could contain new passes, which would not be seen in Flame if not in the Open Clip.
Pattern Browsing would be able to get the new passes without issue.
One could also create Open Clip referencing a Pattern, removing the need to define all channels.
All in all, Flame will correctly update Batch scene when a new version of Mult-Channel clip is provided. We perform channel name matching so connections remain and new passes not connected are available. Channel name matching is also don when replacing a clip in Batch.
, only stuff I need without all the bs that FL puts inside.