If you’d like to archive as something other than uncompressed, please upvote this feedback request:
FI-01367
-Ted
For most of our projects, if Flame would do Prores4444 in archive, that would suffice in spades, and we wouldn’t have to manage archives as tediously.
That’s just trading one set of problems for another arguably. Is there no way to crack the code of exporting motion vectors as a multilayer exr @fredwarren @Slabrie?
I’m baking uv maps but there must be a better way.
@mybikeislost (love this guy) turned me on to https://pixelmania.se/products/nnflowvector/?v=0b3b97fa6688 yesterday.
It’s amazing…
These are fantastic. I used them on a job maybe 4 years ago and was blown away. Swedes…
I’d imagine if enough people asked for an ofx they might be inclined.
I hear you but they’re incredibly handy and needed sometimes. Having people not sure them seems a bit rough. Now having 20 iterations of a batchgroup w/ a shit ton of vectors, yeah…that’d be an issue.
So are you removing the action that created the vectors once you render your UV map?
MotionVector stuff in Flame is quite broken. I’ve documented this multiple times, both publicly and privately to ADSK. They shot their load several years ago. They would have to start from scratch, and it isn’t happening.
Yes. Sometimes many. A multichannel exr is a pretty clever way to get them all in one place as well. After that’s written I just trash the action and the motion vectors.
Ah, ok. Clever.
I wasn’t aware that we couldn’t export the motion vectors into a multichannel exr though. That’s weird and very frustrating.
Many years ago there was a low limit to the # of EXR layers flame could support. I was making a batch that would bake an STmap for every frame. They increased the limit to I think 100.
one of the issues is that the channel count is dynamic. A year+ ago I spent some time experimenting with this. Even writing them out is complex as no two shots are equal in the data structure. Which then makes loading them hard, and ADSK actively blocked the path to putting them in the cache folder where you reconnect them. You can load them back in, but you cannot put them in the cache where the node would recognize them.
There does seem to be some weird stuff under the hood which makes them harder to wrestle than is obvious. Which is what may need a sizable overhaul.
But the bigger problem is that Flame is accumulating more and more of these tech debt piles at a rate faster than they clear them. That’s an unsustainable trajectory and it will likely only get worse not better in terms of resources. Hard to see sunshine at the end of this road.
Not sure what the right answer is here: skinny Flame up and drop those tech debt anchors overboard, leaving some of these areas to other apps and tools, and focus on a high-performance core, or let them linger in semi-vegitative state, and still being useful here and there with tradeoffs.
With the big architecture break made in 2026, one pathway could be to make 2025 a legacy feature release that is maintained for the foreseeable future and receives OS and driver updates, and becomes the host for things like Motion Vectors. And then skinny 2026 up dropping quite a few things and making it a tighter, well functioning app that is positioned for what is next in this ever faster changing landscape.