Also project nicknames and user nicknames were very helpful tokens. If you ever ran into a corrupt project, it’s easy to create a new one w same nickname as previous, even if the project name itself didn’t match.
Users same deal.
1 Like
While Flame’s system seems convoluted/complex, especially for someone new/recent to it, don’t we have to see it in context?
With today’s storage specs and infrastructure, there is very little trade-off between doing a render node that ends up in your Framestore and a write node that ends up on your NVME or 10G NAS folder, because often it’s the same drive underneath. I wasn’t a Flame user during its early days, but I gather that most of Flame’s storage architecture exists because of a centralized fast stone+wire storage pool that was vastly superior to what other storage one might have back in those days, correct?
So if we built Flame from scratch today, it might look different. But it has a 30 year legacy, and some of these things are pretty ingrained. And many of us have built workflows with what exists, so changing it not only is a massive undertaking but also disruptive.
I do like Chris’ RUG proposal to make it easier to have workflows that are basically just all external storage and manage that through policies. So you could setup Flame to completely ignore managed storage if that fits your environment better.
But I would go easy on dinging Flame for what it has today.
Also, working in Flame and working in Nuke is a very different experience from a playback perspective. Nuke may have easier file management, but it does come at a cost that’s not insignificant.
One thing I would love though is a write node that works similar to they way a MediaHub export works. Why can’t a write node support a ProRes export instead of being limited to file sequences? That alone could go a long way to setting up external FS workflows more easily. I your project workflow is primarily based around ProRes video containers (which does perform better than file sequences performance wise), you still have to render into the Framestore, and then export from the MediaHub. Not only a two step instead of a one-step process, but also adds to the use of a managed storage pool.
1 Like
Wait until you see 25 Flame Artists banging on the same 6k material for 4 weeks straight generating terabytes of duplicate data and Chris’ solution will become crystal clear.
4 Likes
you can have the best of both good performance and filebased project management with this however.
if you are a solo artist - sure whatever a little bit more storage and its all neat in its archive - whatever.
What randy said , the overhead becomes too damn high when you have 5 people working on shots, publishing ruuuulez, dwaa exrs rule, its all just so damn great.
1 Like
I think I didn’t word my last post well.
I fully understand the benefits of unmanaged storage workflow in Flame. But while you are all barfing over the status quo, all I was pointing out is that it existed for good reason years ago and that the landscape has shifted since then in terms of what we have for storage. Today we have more options, and Chris’ proposal would make that more accessible for Flame users with all the benefits. Just good to keep in mind that the past isn’t all garbage. After all it got us where we are today. Sometimes external conditions change. That’s all.
PS: Regardless of whether you are a solo artist or work in a big team, I’m very much a fan of a unified folder hierarchy per project and apps that can integrate with that (what Chris calls externalized storage), rather than keeping closed system blobs elsewhere. Even for a solo artist that makes archiving and organizing hard. In the last 11 years I’ve completed 980 jobs, all of which had to be worked, delivered and archived (and tracked in a spreadsheet, which is why I know the number).
3 Likes
If you have a feature request for disabling managed media, I’d upvote it in a second. I’ve Suped now for 3 years in an openClip environment, and it’s awesome.
As far as artists departing from the a studio’s workflow, I provide in depth training, and make sure they know they’re responsible for following it.
8 Likes
Hey Sam et al, they’re up at: FI-03156 and FI-03156
I’m doing them in pieces since they represent different asks. Upvote the shit out of them please.
3 Likes
Upvoted!
Great ideas on how to implement it.
1 Like
since we are on an open clip discussion just curious if anyone has issues with adding the clip back to workspace in the write node so far I have it named with these tokens _comp_v<version###> pretty straightforward and the .clip loads but my issue is the clip it adds to the workspace is always a v01 and shows the versions in the clip extended but the node name doesn’t change and always stays v001 even though I am on v004 or something like that?
I don’t use the inbuilt method–I think @MikeV’s script works better for my needs. I import the write node using the import write node script manually after the first render and just leave it in the comp. After that, the imported openclip is updated under the hood with each new render so no need to reimport. Just double click on it to get to the timeline player and switch versions to your hearts content.
Name-wise I think it’s locked to the openclip pub name and doesn’t update.
Following this thread with interest and have upvoted those couple of excellent feature requests.
I always come back to these central thoughts/questions about Flame. Namely:
What is the main market for the software?
and
What are the best tools for Flame to maintain and grow its market share?
One interesting point is there is not much talk about Flare anymore. If anything, the media management and OpenClip improvements would greatly benefit Flare more than Flame as a tool in a multi-artist VFX environment but am wondering if that is a lost cause now? I’m still considering Flare for an environment such as this but looking at the pros and cons of it versus both Fusion and Nuke, it is a difficult decision to make.
Regardless, there seems to be a lot of Freelance Flame Artists working both internally & remotely for Post Production facilities and I think ANY improvement on the way a Flame Artist can collaborate in this scenario would be hugely beneficial to the product in general. I’d love to see some kind of back and forth publish scenario that optimises whatever media back and forth approach that needs to happen and the integration of OpenClip into this would be a no-brained in my mind.
For open clip to be really beneficial you need flame seats as well as flare.
You could have more flare seats for shot work, but getting around the timeline/conform limitations on flare is a big hassle w/o at least one license of flame.
1 Like
seems like this mechanism is broken and be curious to see with the flame peps if I am way off base it should just add the open clip when the add to workspace button is clicked and the name should change based to the rendered iteration especially since follow iteration is on but the name becomes locked which is wrong in my mind.
1 Like
Understand this completely. I wouldn’t even consider a Flare workflow without an absolute minimum of a couple of Flame licenses. I think I’d stick to no higher than 5:1 Flare to Flame ratio either. Kind of like how you wouldn’t run a larger Nuke based facility without a few Nuke Studio or Heiro licenses. My point would be more that I wouldn’t want the Flames to become a bottleneck with everything passing through them when they don’t need to be. OpenClip certainly helps in this regard.
It would be awesome if someone with a much better coding skill than my non-existent one could somehow build OpenClip integrations with the likes of Resolve and NukeStudio. In the end, that’s where a pipeline TD comes in I guess unless someone here has created something they would like to share. If I ever get a tool built for that purpose, I will certainly share it.
I’ve thought about that a lot. Like more than any normal human should and I’ve got some theories about what directions we could collectively head.
I think the future for a lot of this kind of interop lies with packing open standard containers with data that other softwares can then unpack, ideate upon and push back to the container at will.
In this instance basically using OTIO in a similar manner that one might use USD. So rather than writing an openclip batch could write an OTIO track with individual versions written to stacks within the parent track. That resulting OTIO clip could then be read and adjusted in turn by other OTIO capable softwares.
So we don’t force BMD to write an openclip adapter. We get them to support OTIO. Same with Adsk. Get Flame on board. Get Shotgrid/Flow whatever on board. Everyone pubs those things then because everyone can read them.
I don’t know what the chances are for embedded metadata references (think batch setup path) within the OTIO or if that would require sidecar-esque host application xmls sitting in the same directory as the image data referenced by the OTIO in order to achieve openclip parity but it seems to me that everything should be approaching some sort of consensus around these open standards. Then one can easily glue together all of these disparate softwares without writing a million little converters to and from everyone’s own proprietary format just for interchange.
Pipe dream in more way then one.
2 Likes
The short version being, proprietary tools for image processing and shot setup, open standards for storage and interoperability.
1 Like
I feel the same. On the timeline you can set the name to be dynamic so the it updates but once you match that out it loses the version number.
I’m also not a fan of how the name will always stick to what’s in the XML and you can’t set it to the filename. Off the top of my head, when you render from batch it takes the token which, for us, ends up as 0010 or so as opposed to film_####_comp which drives me up the wall. It might have changed recently though…
Ha! Me too!!!
I’ve posted a few times about open timeline support. I’ve thought about how cool it would be to have a live open timeline/S that lived on the cloud that all parties could point to and as a shot got updated, the information on the open timeline would update with it. In the example of a feature, a VFX Vendor could update a version of a shot, and Editorial, DI, sound and production could sync their timelines so it points to the correct version. With a good Media Management system in place with transcode functionality, potentially systems could automatically grab the relevant version and auto update the timelines.
However, the more “automated” things become the more complex the workflow would need to become and the more break points would be introduced which would be harder to troubleshoot. If we can’t get AAFs and XMLs between software perfectly replicating everything then there is zero chance of the above working.
If I had the ability to publish shots from Flame/Flare and have Resolve & Baselight see there are updated versions and let me pick the one I want to use without having to drop in, it would be a massive step forward.
In the end though, since there is an approval process and editorial generally want to keep control of the master timeline, there is only so much automation that can help in the wider post production process. However, OpenClip in a Vendor or facility workflow could prove extremely useful.
1 Like
I added it to improvement list Autodesk Feedback Community
please vote on it, also be curious if @fredwarren thinks this might be bug category since it just seems so wrong to have a name be v001 when in the clip extension its shows that its on v04 , so maybe an improvement but maybe a bug?
the name shouldn’t be locked it should be dynamic like it is in the timeline , all the behavior should be consistent no matter if your on the timeline or in batch imho