Most of what is there is wrapping up existing workflows and pre-flight simplifying them for execution.
That’s to say that there’s nothing new function-wise per-se but more an ease of deployment making them feel simple for anyone to adopt.
Likewise the lucid link workflow is nothing new for the most part. People who have been working unmanaged wont really see any massive difference in operation. That being said teams that are geographically diverse like ours have really loved the ease at which we can collaborate. But again, it’s nothing inherent to the Logik Projekt but to lucid.
That all being said, the notion is that from Phil’s base we can build a community driven foundation for unmanaged workflow that shops as well as individuals can customize to their specific needs and get more people working in 2024 and less in 2000.
@cnoellert - Absolutely brother - there’s nothing new here.
Some of these technologies have been around for many years, some of these technologies have new boots and panties.
If you already have something that works, don’t change it.
If you don’t, this toolset might work for you.
Reasons to be cheerful
"A bit of grin and bear it, a bit of come and share it, you’re welcome we can spare it, yellow socks "
@cnoellert - your perspective is not viewed in that way at all, brother - your long history with the software, industry, and deep involvement and connections with many innovators and actuators is incredibly valuable.
I respect and value your opinion and perspective.
No offense taken here brother - I appreciate you, your insight and all of your support and help.
@BenV - Thank you brother.
Another productive session.
California → Norway → Chile → California realtime openclip roundtrip.
And collaborative accretion of metadata archiving from linux and two different flavors of macOS in three different countries.
Indeed indeed, this is definitely the way to roll. Just makes sense if you ask me.
Thanks for doing this Phil, you made something that can make peoples lives better. Making working in Flame far far far more effcient then it is out the box or how it’s currently used in most places.
At least in all the numerous studio from the biggest to the medium sized to the smaller boutiques to the one man startup shops I’ve worked at in my relatively short yet enjoyable career in Flame.
I think this helps remove multiple Time Bandits as they run around stealing our day and evening with multiple extra steps that add up very quickly even before the inevitable misstep within said steps.
As you said, let people go to the beach, hang with their kids, go to the park, meet some friends etc etc etc.
As I mentioned I used the pre Logik-Projekt branded version on a small four day job where I did a bunch of shots. It was purely shot work and still it worked great!
Actually I would say things were not a hassle, my job, desktop, library, saved desktops, etc. Where always organized and staying organized in this was the natural way to go/super easy. It would be more work to not be organized.
Batches much more organized.
All in all aside from this resulting in working faster also everything went very smoothly and so there was no stress in that regard! Double bonus.
@BenV - Quick!
Sneak in that guilty pleasure of Pasta/Ice Cream dinner brother.
Thanks again for all of your help, encouragement and support to date brother.
I appreciate you!
We are learning to do good things.
does the workflow break if one of the rendered versions you are trying to pull into the timeline from nuke has: different resolution? different timecode? different duration?
@TimC - Not so far, but I’m not pushing it very hard - I have no idea how nuke works.
I have tried different resolution, different file type, different color tag, shorter handles, and none of these variations break the openclip so I call that a win.
I’m exporting the frames at 1001 - end.
The OpenEXR files have timecode which can be read by flame.
I have not tried to change timecode in Nuke because I don’t know how, and have not learned a robust way from any of the nuke artists that I have encountered. (I’m sure Xavier Bourque knows - because he knows pretty much everything)
So I’m taking the small win.
I’m sure with the right application of determination and grit it could be kneecapped and left for dead.
Dang! My Trial License for nuke ran out yesterday.
I think the resolution for renders is 1920 x 1080 but otherwise it opens the nuke files that I generated.
The read nodes (flame openEXR exports) can still be versioned with ‘ALT-up arrow’ or ‘ALT-down arrow’, and the menu.py script that I wrote for nuke appears to still work, even if the suffix is now .nknc and not .nk
@TimC - the offer to take a look still stands - drop me a line if you want to go through it together.
The biggest hangup with open click workflows at large facilities is either metadata changes like timecode or frame range or resolution changes from render to render. For example, an image sequence with time code followed by the sequence without time code or time code set to zeros will result in infinitely long clips in the open clip and it’s a bad time. It typically requires manual intervention to manually delete problematic, sequences to the media hub or otherwise.
Sadly, timecode does indeed get injected and creates million frame offsets.
Let’s see if there’s a clever way to fix that (other than never using nuke…)
I found a node called copy metadata which allows you to steal metadata from one read node into another (in this case timecode) - so I’m just waiting for a new render to populate the open clip.
Align to zero on import will bring everything back into line…albeit with the first frame of every version being…well, 0. It’s not an actual solution really, but it solves the issue when you run into it.
I’m sure that there is some way to steal just the timecode and frame_rate but I just don’t know how to use nuke.
In the meantime, this appears to be a way to get pictures into a library.
This! There are still too many artists, that I know of, to be not in 2024 and rly hope this project will help reducing that.