Ah, that’s right. I keep forgetting about this menu because it’s hidden away. You have to right-click into empty space, and it defaults to ‘no’ on keyframes. Had to go back to the manual to figure out where it is.
So some of these options will need to get exposed in the OFX in the release version.
Definitely early days in this feature.
exsctly .
I am not a OFX dev, but is there any OFX that reads tc from the source? i mean even if they just expose another field to put in stsrt timecode manually if they have to.
There’s nothing preventing it (here’s the main reference of the API: OpenFX API).
Though based on this discussion from a few months ago amongst key players, it seems that it doesn’t exist universally and they’re proposing a new meta data definition that would provide exactly that.
I think some folks on here are actively involved in the OFX standards and could comment. It just came up in a different topic.
awesome, so there is a potential way this could work.
thats just great!
Yes. The OFX API has a mechanism where Image and Clip info gets passed along with the action. It’s in this clip info that the the source tc would have to be included. From what I saw in this discussion, it’s not currently standardized, but could be.
To get there, two things have to happen - in two variations:
A) Without metadata standard on source tc
BMD would have to define a source TC attribute that this effect utilizes. This would be a plugin specific attribute.
Then ADSK & Foundry would have to be convinced to pass this along if they see the Resolve render plugin.
B) With a new metadata suite adopted
It becomes easier:
ADSK & Foundry would have to be convinced to support this updated OFX standard and always populate these metadata fields (for any plugin that might use them)
The second is more likely, as it’s not an effect specific implementation and benefits any OFX plugin, not just BMD, which could always get people worked up.
Disclaimer: This is based on reading these conversations on GitHub and the OFX API docs. I don’t have any specific first-hand knowledge. But we can dig deeper as we do have some connections to relevant folks.
I think one interesting question - in case anyone knows?
Why did BL only ever support BLG instead of a full BL UI like there is in Nuke and Avid? Flame is the only knee-capped version BL color out there.
Was there a technical reason? Seems somewhat unlikely as Nuke OFX and Flame OFX interfaces should be pretty similar. Or just lack of interest, politics? Was it on ADSK’s account or on Filmlight’s account?
Having the Resolve renderer will be great for folks working in bigger pipelines that rely on Resolve for color. Not sure what the BL/Resolve split is in bigger pipeline?
From a pure color tool perspective, I’d still prefer BL as a plugin than Resolve, especially since you would get the whole UI and actual live update color tools.
I think the BLG plugin wasnt ofx but native? i could totally be wrong!
there is no reason that i can see why resolve doesnt jusr show the ui, this seems like the first step in that kind of direction, maybe?
Time will tell…
I can only answer anecdotally.
When I was working for FilmLight, a lot of decisions that I listened in on with regards to Autodesk and Flame were purely political. Some however were based on market adoption and workflows.
This was especially true when Flame Premium was being positioned (together with the included Lustre and Smoke licenses) as a one stop shop for all your needs. The appetite wasn’t there to to feed that narrative what-so-ever and increasing a competitors edge—at this point they were still very much in competition—even a little, wasn’t looked kindly upon. Especially when there was even the slightest chance that it would invalidate a need for a BaseLight hardware install.
FilmLight was and very much is a hardware company. Like BMD they have to make a calculation and the result of their calculation is turn-key systems and hardware first for numbers, then software for adoption as distant second. They fiercely value their IP and guard it heavily and have managed to remain in business by coldly and to some barbarically financing that business through their hardware.
Lastly, from the development standpoint, there was more synergy with the Foundry back then and with BaseLight mainly getting traction in long form it was believed that those tools—BL editions and BLG support specifically would better fit into those workflows. Hence the beefier Avid and Nuke plugins and only the weakest of support in Autodesk.
It’s a different landscape now and there are different people at the helm. People who I very much respect and admire. I don’t know that there will ever be an appetite to course-correct but who knows.
These were never official responses and only my thoughts and observations.
Thanks, excellent perspective and makes sense given the landscape.
i can dig a bit but i was always told by BL that flame API just doesn’t allow access to many things under the hood, hence the handicapped BLG plugin.
didnt flame also not support OFX for a long-ish while?
Baselight is accessed through Pybox. Just chiming in, in case this clarifies anything.
Hello fighters
we would like to use BLG, we have flame 2024.2.1, do you have any experience with BLG workflows on this version of flame. It has some benefit for working on advertising spots, where there is a lot of pressure for time.
thanks for the answers
Sorry, I think your question should have been on a new thread.
In my experience, you will spend so much time troubleshooting the BLGs that any advantages are more than cancelled out.
thanks
just tried this out. pretty cool that it passes the power-windows through
yea most things come through, its just that the alignment makes no sense at all
you can really only use it right now as a advanced showgrade which is fair enough.
how do you mean “alignment” @finnjaeger - it’s not avail in other DCC’s yet?
Keyframe alignement.