KnobScripter is awesome… it makes editing Python knobs WAY easier.
Changing a gizmo to a group is as easy as opening the .gizmo file in a text editor and editing the Gizmo Class to a Group Class… just one word.
If you want to load it in a Nuke menu, you can keep it as .gizmo and do the usual to make it show up in the UI. You can also rename it to a .nk file and pass the path so it can be imported from the file menu.
Amazing, thanks again!
hey @john-geehreng just trying this out on windows but I cant get it to update the openClip.
I think its due to dependencies on flame stuff like
getMediaScript = "/opt/Autodesk/mio/current/dl_get_media_info"
going to try to dive deeper into this, i think for me just having a write to openclip from a read node would actually be preffered.
with @milanesa script i am also not getting a updated openclip on windows at least but no error.
The following foldpython3 O:/p1p3/dr1p_nuke/dotnuke/gizmos/createClip.py --clip=P:/XXX_development/pipetest/metadata/100.clip --folders=P:\XXX_development\pipetest\100\comp\out\pipetest_100_comp_v002\pipetest_100_comp_v002v03
The get media info script is not installed: file /opt/Autodesk/mio/current/dl_get_media_info missing
so right now this doesnt work on windows machines or linux machines as it requires flame to be isntalled? ill try to grab that d_get_media_info script off a flame machine…
ok obviously dl_get_media_info is a executable and not a python script. darn it, so no updating openclips on the good old wandoze then
Bummer. This can definitely be done in a more portable way. Im sure someone has done already.
This may be even easier. But wasnt the idea to update a .clip coming out of the Sequence Publish Export?
Im not in Flame much these days, but I can take a look if someone supplies examples of a sequence exported .clip and the desired result.
will do!
Yea i feel like the update a openclip is like publishing, so write first, then read back (and qc) then update openclip with this render from my readnode type thing…
at least for me 
I want to just push this back up and see if anyone has come up with a portable way of reading/writing openclip xmls ?
Ironically I’ve never used the open clip creator that comes with the software…
i dont know what the point of it is really either, i just want to be able to read a openclip in nuke and then write a new version to it …
Doing it as a post render action in deadline sounds reasonable
If anyone is interested I can post our shotgrid configs for public consumption. The nuke publisher pushes out updates to flame published openclips for shot renders, which is handy.
No nuke openclip readers in place just yet but eventually that’s the plan.
Just let me know.
definetely interested
Got some example .clip files? With and without versions updates?
Here is an example of using pattern browsing and openclip:
*Preamble:
In order to use pattern browsing to view multiple ‘nuke_comp’ sequences without drilling into subdirectories I can park in my job root directory and use:
option A:
shots/{name}/media/renders/{shotName}_nuke_comp_v{version}/{shotName}_nuke_comp_v{version}.{frame}.exr
Or I can use:
option B:
shots/{name}/media/renders/nuke/comp/v{version}/{shotName}_nuke_comp_v{version}.{frame}.exr
I can wrap either option in xml to create a pattern based openclip using a text editor or openclip creator.
Here is option A pattern based openclip:
<clip>
<handler>
<name>MIO Clip</name>
<options>
<ScanPattern type="string">/JOBS/my_special_job/shots/{name}/media/renders/{shotName}_nuke_comp_v{version}/{shotName}_nuke_comp_v{version}.{frame}.exr</ScanPattern>
</options>
</handler>
</clip>
I saved it as:
/JOBS/my_special_job/shots/shot_0010/openclip/output_clips/shot_0010_nuke_comp
Here is option B pattern based openclip:
<clip>
<handler>
<name>MIO Clip</name>
<options>
<ScanPattern type="string">/JOBS/my_special_job/shots/{name}/media/renders/nuke/comp/v{version}/{shotName}_nuke_comp_v{version}.{frame}.exr</ScanPattern>
</options>
</handler>
</clip>
My job tree looks like this:
JOBS
│
├── other_jobs
│
└── my_special_job
│
├── other_directories
│
└── shots
├── shot_0010
│ │
│ ├── batch_setups
│ ├── media
│ │ ├── renders
│ │ │ ├── shot_0010_nuke_comp_v0001 (option A)
│ │ │ ├── shot_0010_nuke_comp_v0002 (option A)
│ │ │ ├── shot_0010_nuke_comp_v0003 (option A)
│ │ │ ├── shot_0010_nuke_comp_v0004 (option A)
│ │ │ ├── shot_0010_nuke_comp_v0005 (option A)
│ │ │ └── nuke
│ │ │ └── comp
│ │ │ └── shot_0010_nuke_comp
│ │ │ └── v0001 (option B)
│ │ └── sources
│ │ └── shot_0010_layer_01
│ │ └── v0000
│ │ └── P006YNIY
│ │ └── shot_0010_layer_01
│ └── openclip
│ ├── output_clips
│ │ └── shot_0010_nuke_comp
│ └── segment_clips
│
│
├── shot_0020
│ │
│ ├── batch_setups
│ ├── media
│ │ ├── renders
│ │ │ └── shot_0020_nuke_comp_v0001 (option A)
│ │ │ └── shot_0020_nuke_comp_v0002 (option A)
│ │ │ └── shot_0020_nuke_comp_v0003 (option A)
│ │ │ └── shot_0020_nuke_comp_v0004 (option A)
│ │ │ └── shot_0020_nuke_comp_v0005 (option A)
│ │ └── sources
│ │ └── shot_0020_layer_01
│ │ └── v0000
│ │ └── F004MN99
│ │ └── shot_0020_layer_01
│ └── openclip
│ ├── output_clips
│ │ └── shot_0020_nuke_comp
│ └── segment_clips
│
│
├── shot_0030
│ │
└── ├── batch_setups
├── media
│ ├── renders
│ │ └── shot_0030_nuke_comp_v0001 (option A)
│ │ └── shot_0030_nuke_comp_v0002 (option A)
│ │ └── shot_0030_nuke_comp_v0003 (option A)
│ │ └── shot_0030_nuke_comp_v0004 (option A)
│ │ └── shot_0030_nuke_comp_v0005 (option A)
│ └── sources
│ └── shot_0030_layer_01
│ └── v0000
│ └── F004MN99
│ └── shot_0030_layer_01
└── openclip
├── output_clips
│ └── shot_0030_nuke_comp
└── segment_clips
n.b. i edited {frame_number} to {frame} in all instances.
I zeroed out timecode before I exported my versions from nuke, relying solely on frame numbers to align versions.
Now the openclip works in a limited way as expected, including multiple resolutions, but not sure about timecode or offset variations.
Every time a nuke render follows this same render pattern your openclip will have access to the versions.
The pattern browse string permits viewing the individual clips in MediaHub but does not identify related versions.
You can use the pattern browse string to create pattern-based openclips with openclip creator or you can write the relevant strings in a text editor.
You can install openclip creator on non flame workstations or you can define your patterns and use a text editor on pretty much anything.
It shouldn’t be too difficult to script.
Finally, using my directory structure as an example, I can add a new pattern in MediaHub and this will reveal all of my ‘*_nuke_comp’ openclip files:
shots/{name}/openclip/output_clips/{name}_nuke_comp
UPDATE
In my limited testing the pattern based openclip supports independent frame ranges per track.
e.g.
v0001 is 1001-1050 (50 frames inclusive)
v0002 is 1011-1040 (30 frames inclusive, 10 frame tc offset)
v0003 is 1021-1030 (10 frames inclusive, 20 frame tc offset)
v0004 is 1016-1045 (30 frames inclusive, 15 frame tc offset)
v0005 is 1021-1050 (30 frames inclusive, 20 frame tc offset)
All tracks align on the correct frames, and ‘missing media’ gets displayed accordingly.
I only had 50 frames in the original source material so i didn’t experiment with extra heads or extra tails.
In a purely flame environment, this activity normally requires re-importing the openclip to gain access to extra heads, tails, bigger resolutions, etc.
This pattern based openclip technique should provide simple functionality for many basic collaborative environments, where renders, shot lengths & edits change frequently.
The Sequence Publish OpenClips are not pattern based, but version explicit… And we are looking for a portable way of updating those correct? So Nuke can update them without the need for the dl_media_info command.
thats what i want at least, because pbrowsing massive amounts of files and versions is painfully slow, i want to use openclip as a sort of publish-database of sorts.
thats sort of the idea here I recon like a ledger of versions and where they are.
ill send you some openclips once i am at the box @milanesa
https://transfer.replayboys.de/share/VgoUOdgj
there you go, including renders and plates , just grabbed some free stock from pexels.
included all the things from a very standard flame sequence publish. should be good to test.
I dont need anything with that segment openclip, its kinda useless for me, its a batch needs this workaround afaik.
my personal high level wishlist for nuke:
less important:
→ be able to load the output-openclip as a source , maybe like a little gui where it shows me all the versions in the openclip and then have a button to create a read node from it?
The key thing:
→ have a script or ideally a node to “publish” a read node to the openclip, I personally dont need a write node that has this included, just a way to click on a read node and say publish to openclip with a way to write a new version, i am sure there are advanced fun things we can think about like the version-name or whatever else we can throw into a openclip.
next step for me would be looking at it and trying to implement the publish into deadline… but thats just pure convenience.
once this is sort of a thing the openclips become a central database for all shots/image assets which is insane we could let nuke or deadline auto-generate dailies based on reading the openclips or whatever, so much room for fun.
in my mind it would “just” be a portable way using python/ XML parser-writer?
havent tried this at all but maybe there is usefull stuff
Ok thank! Will take a look when I have a chance.
Sequence Publish openclips are certainly not pattern based.
I stopped using Sequence Published openclips is because the batch to which they are related is broken.
(This issue was recently solved but the fix has not yet been released.)
If you wanted to automatically update your Sequence Publish openclips with After Effects or Resolve or Nuke you could write a separate pattern based openclip, which would automatically update when new renders are manufactured from elsewhere.
In this scenario pattern browsing is trivial since the software is restricted to specific parent paths.
Pattern browsing at root levels is like watching tectonic shifts occur in real time - it’s faster to grow a beard.
If you are not afraid of exposing your publishing template, I’d be happy to help you define template openclips that could be generated in a shell script with a single command, or probably converted into a python script.
I was thinking the same. Why not swap the sequence publish .clip file by a pattern based one? But I don’t work with these workflows in a regular basis, so not sure what the implications are.
I guess you just have to really respect the naming conventions then.
If you mean ‘swap’ meaning unlink a published timeline then re-conform with pattern based openclips? Yes! Absolutely do that.
It’s not difficult to keep your published timeline, and not difficult to keep a second one that’s full of pattern based openclips.
As for naming conventions, yes, it’s a good idea to systematize your work.