Hi All,
I’ve one of those questions that i feel slightly embarassed to ask having been using Flame for so many years. 99 percent of my work is VFX for TV dramas and i’ve never used an “Openclip” should i have? Can someone explain to me in laymans why and for what reason an openclip is used. Is this a game changer that i should have a known about for years. Forgive me if this is one of those OMG he doesnt know what an Openclip does moments but there it is. I’ve asked the question. Thank you in advance. M
2 Likes
As far as I am aware, an open clip is a container that is linked to a bunch of folder names the same with different version numbers. I’m sure there’s a better technical answer.
However, you can do much the same using pattern browsing.
It’s quite useful if you have a pipeline set up in exactly your type of work. We used to use something like it on Doctor Who years ago and then I expect they did something similar of all the other projects when Mill Film became Milk. @Wispy knows all the ins and outs.
1 Like
Here is a rather dry description from the Flame manual:
https://help.autodesk.com/view/FLAME/2023/ENU/?guid=Flame_API_Open_Clip_Reference_html
Open Clip is an XML structured file with the following information.
- Physical location of files
- Metadata information, such as timecode
- Structural information, such as tracks
- Clip versions
If you use OpenClips you can have what appears to be a single clip but with access to multiple versions.
Have it switched on when you you use a write node. Pull the openClip back in and use it in a timeline or in a batch setup as a precomp.
Use it as part of sequence publish and have it recreate the VFX timeline with OpenClips that all connect back to your batch groups
2 Likes
Funny you should say that, in the same boat.
I’ve seen plenty of references to OpenClip publishing in the larger workflows, but being a small operation that never seemed to apply so I didn’t worry.
Turns out they’re really cool and really useful. And I just played with them yesterday to understand them completely.
In effect it’s a virtual clip that can reference the actual clip. Think of them as a symbolic link maybe in Linux filesystem terms, except it has more capability and pass through all the meta data. In reality it’s an XML file that points to the actual clips, but Flame allows you to use it everywhere you could put an actual clip (picture, not sound though).
I still don’t know or need the publishing side. But the useful part of it is on the ingest side, specifically if you have multiple versions of clips coming in from other apps, that being GFX from client or even you yourself working on a clip in another app. Anything that can be versioned essentially.
Where it comes in handy on the ingest side is if there are multiple versions of the same file. You essentially import the OpenClip into the mediahub instead of the actual clip, and then you get a version selector in the UI that allows you to flip between versions in real time without moving segments in the timeline or connections in batch.
Even better, a variation of the OpenClip can act as a watch folder via patterns and automatically detect a new version of the file being saved in a folder and connect it and it showing up in the UI without you having to monger any files. That’s useful for everyone, regardless of pipeline.
Grant had a 3 parts series when that feature first cam out in 2018: https://www.youtube.com/watch?v=c8DlHqMbjos
The way I setup my test, is that switched the folder structure for VFX clips around to having a ‘to’ folder for sending out the plates, and a ‘from’ folder for the returned versions, with datecodes in the next level, and then setup the openclip as a ‘single version’ with a pattern to the ‘from’ folder which automatically watches for new versions I drop into the folder as they come. Sometimes you may have to click update source in menu similar to connected segments to have it scan the folder.
They then show up as versions in the dropdown on the timeline like this.
Similar in batch:
The version number is displayed underneath the clip, and in the ‘extended’ page of the clip parameters, where you also have the dropdown.
Makes it very easy to compare different versions of a file.
To setup this workflow, when you get your original files in, in MediaHub select them, right mouse click and click ‘Create Open Clip’, select the appropriate options. This will then create the .clip files in a folder you designate. Then switch to that folder in MediaHub and drag those files into the library or desktop instead of the camera files.
There’s also a standalone app ‘Open Clip Creator’, but it’s easy enough to straight out of the MediaHub.
4 Likes
Thank you for sharing your findings. I’m now starting get the tingles in my brain to put these openclips to some possible use based on what ive read. I shall look at Grants vids and see if i can hopefully start to gain some confidence in using these in the future.
Great explanation Jan @allklier ! You’re amazing for putting in such details in your posts and this one is fantastic for showing how to create openclips from existing structures.
@Marcus_M, you can also have Flame make the openclips for you by publishing after a conform using the Sequence Publish option in export. This is great for when you’re using Flame to make the content in your outputs. But when you publish, Flame can create a BatchGroup with the correct pathing built in! It gives you a setup with the correct source and a WriteFile node that makes clips in the correct folder. So all you have to do is hit render and your versions show up in the timeline. It takes a little experimentation to make a publish recipe that works for you, but it’ll save tons of time later.
I use openclips on every job (even if it’s just me!) because I think there are a few additional benefits to the versioning which the workflow opens up:
- No reconforming when you get a new render
- Exterior Data management
- 100% Confidence in finding the correct setup used to make a clip
- Tiny Archives.
Here’s my most used recipe:
Sequence Options Tab:
Video Options Tab:
Clip Options Tab:
Have fun!
6 Likes
Just checking from those in the know, it is my understanding that Flame is the only tool that can read or use the OpenClip metadata/functionality. Is this still the case?
BaseLight can as well although I’ve never tried it.
Best,
Chris
1 Like
Surely MillTv to Milk…? 
Openclips are super helpful.
One thing I’ve found handy, especially for bigger jobs, is that the openClip xmls don’t need to live in same place as what it’s referencing. This is a big difference to pattern browsing, which seems similar.
When I publish from timeline or batch, the elements and renders go where they need to, but the openclips go to a hero directory at top of my job structure. This makes it crazy easy to “grab all the comps” or grab all the elem that created a shot from a single source directory , no matter if plates, roto, cg etc.
Works great for large teams but so easy to do, I do it on all jobs. (Assuming you have write permissions to do so)
A
3 Likes
Oopsies
You might be right. I just seemed to remember Will Cohen trying to start the film up again.
I can only encourage freelancers to learn how to use them.
We are migrating to this, and i cann allready with wayy more confidence hire flame freelancers vs before I was really only looking for giving out shots to nuke people.
5 Likes
Hi Finn,
is this so you can get a more uniform workflow with the artists and how they structure shots.
Flames workflow is crazy convoluted with bfx, batch, shared libraries, cached media, framestores etc,
its a giant overhead logistically vs nuke where its a small .nk file that represents your work.
Publishing on the other hand is very nuke like, you have a copy of each batch and stuff flows back to a central timeline automagically, it works well.
it leads to a lot less ovehead, no more archives to deal with, much easier to hand out shots to many artists working collaboratively.
When I see people wiring shots across flames or using anothers flames framestore and stuff it all makes me cry inside from a organisational standpoint, this is just better, way more modern all file based
for me there is no option but to utilize this to the absolute maximum
2 Likes
This is super intereresting to read and something i’ve never really thought about the logistics of. Be great to have a logik live on Openclips one day showcasing there different uses. Seems they are a bit of a dark art.
1 Like
When setup, artists don’t even realize it’s going where it’s supposed to.
No code needed.
I avoid bfx for anything aside from temp work w client.
Batch and timeline publishes only.
Setups from batch are saved to job structure s the renders. This way it’s central w the rest of the job.
Then no wiring between machines. The setups reference the elements directly.
Much cleaner.
1 Like
This is mostly true. The issue still exists that it’s entirely too easy for an artist to create managed media that’s then used in their batches.
Way too fucking easy. Like so fucking easy and familiar that there needs to be architectural changes to the workflow to make it just as easy to not to.
If you were to take a show of hands here—of even people who use unmanaged workflow—most wouldn’t have a method as simple as adding a render node in batch to create a precomp render for example. There’s no one-click unmanaged media that renders to the correct place in the shot hierarchy on disk without potentially overwriting shit.
Like literally 3 people have a trick and I’m maybe one of them. For most folks it’s manually editing paths—copying and updating the paths. Most artists struggle in this instance and it’s hardly surprising. The render they eventually create may be pathed correctly but there are pre-renders and library elements and twml clips that aren’t anywhere other than sitting on some artists stonefs and loading their setup means a gateway read and a fat archive. Barf.
That’s the other part of my reverse user group ask. Default render pathing per module by way of user definable paths represented in system, project, user and batch contexts by tokens. The way I see it, part of the publish process should be dynamically setting write node defaults so that artists don’t have to.
Zooming out to 30,000 feet, in my mind there needs to be a full proof way to shut flame off from the legacy managed workflow completely. Like, enable pro-mode or something so artists don’t have a chance to do the wrong thing in pipeline environments. I refuse to accept that this is the way it has to be anymore to be creative and ideate. I also don’t think that it’s always about allowing the artist to do what ever they want whenever they want and being a flexible system. Sometimes there have to be fucking rules and they need to be followed. It’s too convoluted as it is now and to difficult sometimes to do the right thing for people who aren’t used to it.
13 Likes
i agree so much with that rant
1 Like
We do but it’s via Python…but it kind of goes to your argument as the only way for that to work is to have knowns to base things off of. We use the project name, for example, which has to be the exact same as it is on the server. This method wouldn’t work for a freelancer who isn’t on one of your boxes.
I’m fully behind your request of more tokens and being able to base more things off of those. Great idea.
2 Likes
Hit me up w DM.
I was able to set up a framework for Fotokem that enabled them to consistently deliver hundreds of shots per week on a half dozen shows concurrently No code, just using shotgrid and flame publish. Each sup could then adjust to their taste, but underlying framework was consistent.
Basic idea was to firewall all editorial changes/publishes thru an artist specifically tasked w the in/out of editorial/deliverables. This allowed the rest of the artists to just do shots. As I set it up, I would have the sup go thru and create the templates which ensured that artists were off and running as quickly as possible.
Only addtl elements to be created by artists was precomps which was easily accommodated.
Happy to discuss the details of what made that possible if interested.
3 Likes