Check the bug status of Paint or MotionVector Tracking. Check how many examples, bug reports, drum banging I’ve made. It is pointless. MTL is on autopilot to retirement at this point. They are at MVP level, Minimum Viable Product. The easy of the easy. The hard stuff is not fixed or refined. My studio will soon be 4 major versions behind because we can not trust the newer software to enable us to deliver anymore. Corporate wins though. They will get our subs for version 2025 until the singularity engulfs us.
The best way to predict the future is for us to create it ourselves. The future of Flame requires everyone to participate in creating and building together.
Overall, Flame is an excellent compositing and finishing system. However, in the current competitive landscape of products and the booming development of AIGI, Flame may really be lagging behind. But this also means that Flame still has a lot of room for improvement and enhancement. Active change or passive adaptation will inevitably lead to different fates and endings for Flame.
In the high-end post production field, especially for creative processing and production of high-resolution RAW clips, AIGC is far from completely replacing traditional digital audio and video productivity systems. So Flame still has its high value. The major problem that Flame faces may be a relatively small user base and limited development resources, which are not enough to support radical reform and innovation. But as the pioneer of nodal synthesis, why did Flame (Infeno) lag far behind Nuke and even Fusion in 3D compositing later on? This is a matter worthy of deep reflection.
Choose it, cherish it, look forward to it, support it, and see a more powerful Flame system every year.
Was forced down this path a few years ago. The time taken and data requirements to move back and forth between conform to grade to online to DCP/IMF creation was such an inefficient workflow it became untenable. Clients wanted to listen to their Dolby Atmos mix for final watch downs & mastering which we couldn’t do in Flame.
Do I like Resolve more than Flame, no, but is Flame so incredibly efficient that it is worth the overheads and cost, also no. We can do pretty much everything we can do in Flame on it plus more. I don’t mean to sound like I am bagging Flame here but it is the reality for the majority of post houses now which is a real shame.
I also think you can’t compare the development of Flame to Nuke or Resolve.
Nuke is The Foundry’s hero product (see what I did there). They need to ensure they are at the forefront of compositing & visual effects. They need to make it the best tool they can as their business model is reliant on it. SideFXs relationship to Houdini is obviously the same.
Resolve is a marketing tool to sell Blackmagic Design hardware. They want it to be a jack of all trades so they can use it to sell their plethora of hardware. Once again, their business model relies upon it being a great reliable tool.
Adobe is probably the most similar to the business model for Autodesk. After Effects and Premiere are still one of their main software offerings though and they cleverly (as much as their user base complains) package their software up so people will use it because they have access to it
Autodesk don’t even have Flame as an easy to find product on their website…
I applaud the dev team for what they do with Flame. From the outside though, it really doesn’t seem that Autodesk care too much about Flame as a product.
We all use the software differently, but as someone who uses more action 3d, particles, and lights than most, I don’t want a ray tracer.
Sure I can think of times when it could be useful, but it leads down a road of feature requests until you have Maya Lite.
I would prefer a way to get action scenes out of flame via Alembic or FBX. Even just a camera export with a few more options (aka something Blender will read) would be huge. That would give us all access to the vast array of great particle systems, modeling tools, and rendering engines that already exist.
Totally agree with your assessment. They’re different companies with different business models. The Black Magic story is more complex, but that was already covered previously at nauseam.
Spot on.
In this limited resource environment it’s totally self-defeating to have each of the big apps be an everything app and mirror each other. That’s like ‘I don’t care about my carbon footprint’.
Focusing on the interconnect of apps and streamlining multi-app workflows where they’re a non-issue is in the best interest of most of the software providers and the users. Let various apps focus on the aspect they’re truly great at, and then make it easy to move parts between them. And yes, it’s a few extra steps, but potentially saves you equal time if not more by not using half-baked implementations, or ones that are years behind.
And yes, Resolve offers enough that some folks can survive exclusively within its orbit. But as also covered previously, Resolve has everything, but neither module is best in class. They’re spiffed up graveyard finds that now pass as workable, and come with a few hundred thousand YT groupies. More like a premium+ seat on a holiday charter airline.
Especially for the work we do, it would be preferable to only deal with 1st class seating at a mainline carrier, and make a connection somewhere if need be.
Don’t entirely agree with this argument and in some ways is detrimental to Flame. I love the concept of being easily able to move between software but the reality unfortunately is vastly different. There are more than enough posts on here complaining about workflows/exchange between different tools. There are also some lacking tools in Flame for a whole lot of Interchange processes. The more times you move things back and forth the more chance something can break and troubleshooting becomes more time consuming. It also exposes users to other software which can lead to the question “Do I actually need Flame as part of this process?” A good proportion will answer yes but I know several post houses where the answer has been No. From what I have gathered, Flame is not an easy tool to build integrations into either so the expense of doing so needs the financial payoff
Like projects, software also has the quality, time, budget triangle that you are trying to balance. As with everything else this is applied to, pick two. Flame will work in certain use cases for sure but arguably is not as diverse as it would have been 5-10 years ago.
it sounds like the user base for Flame is growing so I don’t think it is necessarily doom and gloom. I do think though the Flame needs to evolve and now is the time to do it (even with the 2026 issues) but do they have the resources to pull it off well? Time will tell.
To not digress from the topic though. Ray tracing would be nice to have but with limited dev resources, it is not what I would call a good use of limited development resources. Fantastic idea and would be really useful to some but the whole 3D environment would need an overhaul before that could even be looked at.
I’ll add that it can also be more efficient to be able to put another body to a task that is best accomplished on some other app. Particularly if the other person is as passionate about their tasks on their platform as we are on Flame. I dabble with the 3D portion of Flame rarely. If it’s something complex enough that I need to relearn how to do it, I’d rather just give it to someone else.
Hey everyone — I really appreciate all the thoughtful comments. There have been some excellent points made across the board.
When I picture ray tracing inside Flame, I’m imagining significantly higher-quality shadows, plate reflections onto other plates (including those with displacement maps or PBR surfaces), and enhanced ambient occlusion. I’m also thinking of materials with emissive textures that can illuminate nearby surfaces — all adding up to a richer, more physically grounded composite.
The potential applications for ray tracing in Flame are tremendous — not as a 3D replacement, but as an extension of what we can achieve as Flame artists. I can easily see a future where we’re working with fewer traditional CG environments and more AI-generated plates and environments. That shift would make it essential to have tools capable of generating realistic shadows, reflections, and overall lighting interactions directly within Flame. Since these plates aren’t CG, we can’t simply hand them back to 3D for integration — we need that control ourselves.
I’m not asking for Unreal Engine inside Flame or anything to replace Maya. What I’m describing is ray tracing in Action that enhances the quality of shadows, reflections, refractions, and emissive lighting — all for practical compositing work, while also opening creative new possibilities.
Round-tripping isn’t really a viable solution for this — there are too many Flame-specific tricks and workflows that simply don’t translate out and back cleanly.
That said, I get the sense this probably isn’t on Autodesk’s roadmap anymore, which is unfortunate. It sometimes feels like the bigger concern is whether Flame itself continue to survive — rather than dreaming about what it could still become.
I’m sure the dev team would love to create cool tools if they had opportunity.
I (kinda) totally agree with @AdamF and politely disagree with most of the other comments.
If you (anyone) don’t use flame 3d when it makes sense (as it is now) then you don’t (can’t?) understand why an upgrade (shadows, occlusions, GI ish - md gi doesn’t even work anymore due to unfortunate matchbox upgrades …) would kick some ass.
Going to maya, blender, c4d, houdini … for other things is not even the point. Of course you go to a dedicated package when you need what Flame can’t do well, who even ever questioned this?
This is not about competing with cg apps, but filling the gap. Fixing bugs is a must for sure, but we’re talking about feature requests, not bug fixes, 2 different discussions.
Reduced dev team and budget is another story. But if someone in charge would allow for development, I hope for something that will actually make a nice difference regarding making VISUAL EFFECTS, not just finishing.
Considering many comments, maybe it should just be renamed as Smoke, and call it a day.
I really hope I’m not offending anyone by being unusually salty.
Anyway, hope everyone is still having fun doing what they do.Text
If it’s any consolation, I agree with you. There is a sweet spot between Houdini/Blender and Action where a revamped action (Reaction?) could basically allow for usd import and export, to start with, just the limited tools we have today in action updated to work with say Arnold GPU, managed inside a real 3d viewer/workspace fills a gap that is otherwise filled by hacks on hacks or a push to Nuke or Fusion in Flame’s stead. The aim here is better 2.5d comp integration, not a full 3d package.
Anyone who does highend comp should see the value in that pursuit. It’s painfully obvious. We may never get consensus on which “most important feature” needs implementing first, but we should be able to agree on what is worth implementing regardless of its place in line.
As a side note, in our system, including a lot of different solutions for many needs/fields, Flame is one of the best integrated and most central multi-tool in the toolbox. It’s far from dead or obsolete in many ways. On the ML side, Sammie-roto, ComfyUI and the like are gradually becoming sort of plugins for Flame (in house dev/tools). I don’t think resolve/fusion allows for this kind of integration. We use resolve for ocf transcodes when it’s needed, or media encoder in other cases … easy.
Not sure that’s true. Fusion has a ‘fuse’ infrastructure and community that’s alive and well, similar to Nuke’s toolkit, and links to other apps. And keep in mind that Fusion exists as a standalone app as well. You don’t have to use it inside Resolve. In fact the standalone app (original) is a lot more usable, albeit you lose the timeline integration.
Limited first-hand experience on my part, but have installed and tried it out a while ago. I do know others in this forum who are actively using that.
Just saying that other platforms have similar infrastructure and vibrant 3rd party eco systems like Flame does. Flame and Nuke both suffer from real-time playback in big ways though.
Don’t get me wrong, I love Flame, and I’d much rather be in Flame any day than in Blackmagic software. I’m one of many here who are doing their part to keep the Flame alive. It is an uphill battle, and will require wise choices, and clarity of what the landscape looks like.
In my mind Flame strength is its performance, efficient workflow, and a few unique features that nobody has matched, like connected conform and publishing. But it seems less differentiated when it comes to nuts and bolts of pixel manipulation. You can do many things elsewhere, maybe just not as easy or as fast. Which means the criticism that ADSK is focusing on unsexy infrastructure instead of coolness of pixel mongering, may be ill-placed in terms of keeping Flame relevant and competitive.
And noting that I heard the distinction between Flame 2.5D improvements for shadows and other parts of Action via modern raytracing tech vs. full 3D in a box. That does make sense. The thread may have taking an odd turn based on terminology and assumptions by those reading. So yes to that feature request with that clarification.
PS: Did a quick look in Fusion about available Fuses. Nothing earth shatteringly relevant to this discussion, but just for context:
PS2: I had Claude look for examples of AI integration for Fusion. He found this example, a background removal Fuse, which uses the equivalent of PyBox to run AI models. Fusion also supports OFX plugins, so the recent experiment to run ML via an OFX plugin from Fusion obvioulsy translates too.
This is a very interesting perspective. I think like most of us here every project I’ve had lately has had some sort of AI component, and I am finding myself turning to actions 3d more and more as part of this.
Also given how easy it is to generate meshes that would be good enough for shadow casting from the img→3D models, I could definitely see finding a use case for ray tracing in that capacity.
I think if we had Full Raytracing Action but with only a small percentage of the development resources that were required to do the job, we could call it FRAction.
Jokes aside I look at USD, OTIO, OCIO and ironically python/pybox, Postgres and publishing as these essential pieces of Flame’s development moving forward.
OCIO gives flame facility-wide color policy adherence which is the lowest hanging fruit of integration into a pipeline.
Integrating OTIO support could give flame editorial touchpoints into a pipeline and final begin to scrape off the needs for constant archiving and wire to move editorial from place to place.
Creating a new action that imports and can export a USD becomes another key entry point to a pipeline where work can be ideated in one place and continued in another.
Postgres, python/Pybox and Publishing ultimately are the methods this data can transferred, stored and interchanged with the pipeline and directly with other softwares.
All of these areas should be in various stages of development/refinement and all are key to moving flame forward.
The staying power of this request for Ray tracing/path tracing is soooo long standing and is intrinsically linked to usd development that it feels like a two for one special.
