Hey Gang,
if you use sequence publish in Flame in combination with OpenClip, how do you manage to implement Nuke in that Pipeline? Is there a way (without nim or shotgrid) to get nuke to write versions to an OpenClip?
Cheers!
Max
1 Like
Hi Max,
I haven’t done it specifically with OpenClip but I’ve totally done this with pattern browsing. You just have to make sure that the pattern matches. It might work with open clip if you publish from Flame and let Flame make the initial open clips.
1 Like
Hey Andy,
thanks for the quick reply! Pattern Browsing ist just not that fast… Browsing in the MediaHub ist not that fun… What do you mean by:
It might work with open clip if you publish from Flame and let Flame make the initial open clips.
?
No problem. What I was thinking was that if you did your initial shot publish from flame then flame will generate the open clips. Once that’s done, as long as you render to the same path and with the same name/versioning scheme you should be able to see those new versions in your open clip clips in flame. I haven’t done this personally but it’s easy enough to test.
Re: pattern browsing…once you set the initial pattern then it’s as simple as right clicking on your clip and scanning for new versions.
But how would the OpenClip update, if there is only a new render but nothing done to the OpenClip it self? As far as I know, you need to feed the OpenClip with the information of the new version…
yes I know Pattern Browsing, I thought I could be even more convenient, if nuke would also update the OpenClip
Looks like you’re right. I just did a quick test to see if a versioned up sequence would be recognized by the orig open clip and it doesn’t work. Pattern browsing worked on it, though.
Sorry for the confusion! I know that Autodesk has an open clip creator app with documentation. Maybe that can help you out.
Yes we can have Nuke update our openClips and yes we use NiM.
Not what you asked I know. But it isn’t even Nuke’s NiM connector doing this. It needs to be rendered through Deadline so it is a little harder for me to really know what is happening under the hood but my best guess is it needs to add a tiny line to the openClip script with the latest render name and location.
Pattern browsing is your best, none scripted option and it is an excellent feature.
Implement once at the start when you import the first render and ensure that strict naming conventions and timecode is maintained. Any change to frame length or file name quickly messes it up for you.
Initially the pattern required to look inside a folder and stack all of the render versions can be a little confusing and it depends on your workflow but there have been plenty of threads on Pattern Browsing so have a search through some of those if you find yourself stuck 
1 Like
Thanks Andy, I will check the clip creator app and see what it can do 
I see… the last company I worked for they used NiM to do that, which worked perfect. But I guess they programmed it that way…
Maybe we will try to script something, so that there will be an entry added to the OpenClip, but I need to check if my colleagues can do that, because I can’t 
Thanks for your input
I could look into this. Im interested in doing something similar. So basically you want to add versions to an openclip created from flames sequence publish?
Hey Milanesa,
That would be awesome
yes that is correct, Nuke needs to add versions to that existing OpenClip.
Cheers,
Max
Here:
nuke_update_openclip.zip (2.9 KB)
No promises is going to work for you… works here.
I am using a modified variant of the createClip.py script from some years ago. Honestly I think it can be better, but dont have much time for this now. I’ll write something more robust eventually.
You need to use the included custom Nuke write node. I have set it up with some flexibility to adapt, but taking into account a folder structure similar to what Flame spits out from the Sequence Publisher.
The rendered image will default to this path
<render dir>/<version>/<shot>_<name>.<version>.<padding>.<extension>
The createClip.py will look in this folder by default:
<render dir>/<version>
The openclip path will default to:
<render dir>/<version>/<shot>.clip
Unless specified in the write node
One of the things the createClip will do is to keep adding version to the openclip, even if its the same version and path. This is one of the things it should be fixed eventually. So I have included an option to enable the update.
Hope at least it give you some ideas.
BTW the createClip.py it works as a standalone tool… just pass the --help flag for instructions.
A
8 Likes
This is great stuff @milanesa
Thanks. Will take a look
Updated zip file with a couple of fixes in the write node.
Also, forgot to mention that the update happens right after the Write node finish rendering.
1 Like
Wow, this is amazing.
Wow @milanesa Thank you! I will check that on Monday, sounds promising
I’m picking this back up and it’s working. I demoed these in my Logik Live, but I don’t spend much time in Nuke these days, so I have a couple of questions:
-
Is it ok to bury the entire python script in Python → After Render?
-
What’s the best way to distribute it? From what I’ve gathered, it’s a gizmo so then you can get it to pop up in the toolbar.
You can find this gizmo below or in the Logik Portal under Add Version to Open Clip which includes these scripts:
open_clip_write_node.gizmo.zip (3.2 KB)
I don’t see why not. May be a bit odd for editing with Nuke native tools, but you can always use something like KnobScripter for it.
For distribution I would change the Class to a Group instead of a Gizmo. That way it doesn’t need be ingested as a plugin on Nuke startup. Other wise it will fail if the .gizmo is not found in the NUKE_PATH locations.
1 Like
Thanks @milanesa! It was definitely odd editing the script with Nuke native tools, but KnobScripter looks likes a handy tool.
Is this what you’re talking about for creating a group? Grouping Nodes.
Then would I distribute a .nk file?