Chatter observed on the airwaves: The world is ending.
Underground control room: I don’t see a ticket, everything seems alright…
1 Like
We have a busy studio. Our main client is Sony Pictures Studio. They DO NOT give a fuck why they don’t have what they want NOW. We can not survive the “bucket full of surprises”.
WFH development is not working for Flame. The beta cycles are not being properly tested, and they are definitely not properly testing in a centralized, collaborative multi-flame/burn studio environment. During the initial 2026 beta cycle, I identified 3 absolute critical failure bugs, that happen basically with just launching the software. Literally, click the app icon, fail. And yet ADSK did not catch these. How do you not even test launching the software?
I’m tired of waiting 10 years, for poorly, half-implemented features, that really should be no brainers.
With 2025, it is the pain I know. But at least I know I’ll be able to deliver tomorrow, not a bucket of surprises. There is not a single feature in 2026+ compelling enough to take that risk.
1 Like
I think there is a valid question what workflows (in terms of scale) are part of the automated test suite, and if they’re representative of the full breadth of what is done today in production.
But this absolutely nothing to do with WFH development. RTO an inability to lead in a changing world, and an ego trip for people who like seeing busy floors and their power as a leader. I’ve worked remotely for more years in my career than I have worked in the office, including big tech companies. And long before there was WFH there was globally distributed teams. My old team at HP in ‘99 had 2 engineers in Colorado, 1 in the UK, and 8 in Bangalore. And we shipped on time and to high quality. A Product HP still sells today.
Test cycles for apps the complexity of Flame don’t happen on individual workstations, whether at home or in the office, but in large automated suites in labs, which can totally be done remotely, and is generally fully automated.
So please remain focused. Hold them accountable if the test cases are representative and why they’re not catching these problems in due time.
Any software is being released with a few known (and documented) bugs. That’s the nature of making a release schedule work. Just like you will have a few clips may have been done in non-ideal fashion because Sony wants that clip NOW.
I’ll make another one today.
WFH inherently turns people into “undies” dudes. I vastly disagree with the concept when it comes to collaborative innovative work of any kind. And I believe we are seeing the affect of it in this thread now.
Sure you can have call center people, and other mindless boring jobs WFH. But not this.
The ADSK guys once explained to me that to even get a desk at the MTL office, they needed to schedule it ahead of time, which meant they also needed to schedule access to a linux machine, which was going to be Teradici’d in anyway. And as far as I see, they don’t really have any studio style testing lab that replicates the more complex installation environments like we run.
For about 6-8 months after 2026 initial release, I kept complaining that Flame would crash on a Burn render. I provided a thousand logs, tried all the stuff they asked. No progress. It finally got to the point where I had to setup a whole dedicated isolated infrastructure, ( NAS, Flame, Burn, SW DB, FreeIPA server, Teradici) on separate VLAN, and give access to MTL. They spent almost 2 weeks logged in, and it was eventually “fixed”. It took 8 months to be taken seriously. Thankfully I had some extra hardware to accommodate this level of intervention. It took many full days to create this mirrored infrastructure.
I can’t do it anymore. I’m done. I’m done banging the drum and beating my head against the wall.
Paint corrupts itself frequently.
MotionVector Tracking implementation was totally flawed from the beginning. It invalidates itself all the time. It tries to render Cache on surfaces that are hidden all the time. High float values totally break the tracking. Gmask vector tracking breaks often if you have more than 1 mask per node.
We have certain trees that only render properly on Burn, but not locally. And certain tree that only render properly locally but not on Burn.
The amount of “there is a bug, so you have to do this work around” for us is insane. We have a junior guy, that I’ve been teaching Flame. He is a smart young optimistic dude. And he can not believe the caveats I’m having to teach him, to the point where he has sometime asked us wether he should continue to learn Flame as it doesn’t seem like a viable future platform.
And after all of this hassle with 2026, what do we get? A 2 column database of UUID and Frame Path. But the actual slow part of Flame “library” operations is the thousand of temp files Flame must write out for everything. The clip library crap, the .volatile crap. This is what is slow and In-efficient. All this hassle, and things are slower. I really had high hopes for proper DB integration, and we got the bare minimum viable product.
But in the end, it’s all I know. It is the only job I’ve ever know, since I am 19 years old. I was once that young, questionably smart, guy. Now I am old and bitter, and definitely not optimistic. So I’ll ride it out for the unknown timeframe of the future on the King, Flame 2025.
3 Likes
I think the ticket creation request is missunderstood.
The number of people impacted by an specific issue is really relevant to provide the necessary resources and evaluate how critical it eventually became.
Each ticket represent one impacted customer and the full issue context could be investigated, compared with others and validated.
Sometimes, different issues have similar effects and have not finally the same cause.
It takes less time to open a support case that complaining in a forum thread(no oftense), and more effective, I can assure. That said, we all can share our thoughs and opinions freely and that doesn’t mean that the reality is how we see that.
I totally hear you on this.
I myself am not experiencing the problem. I’m just an informed observer. But sometimes you’re just standing in a room and watching people squabble. And your realize neither side is is hearing the other that much, or understanding what’s going on.
Do I think that all the affected users should submit tickets and provide data (where possible) - absolutely. That’s the official process and is so for a reason. And it shouldn’t be by-passed for pure convenience.
At the same time this thread has been going for weeks and months. And the constant reminder ‘you need to file a ticket’ appears at this point in time equally ineffective in getting closer to an understanding or solution.
Meanwhile there is plausible evidence of a major issue that makes some 2026 installs unusable in production under certain circumstances. That isn’t just node A isn’t working as designed. This is the project is bound to fail kind of stuff.
Which is why I shared my story earlier, that once there is a deadlock in standard procedure, and the house is on fire by all accounts, it may be wise to not be too stubborn on procedure, and start thinking of other ways of resolving the situation.
This is not just a defect, that is something that could seriously dent Flame’s future if not solve by some means. So time for some fresh thinking.
This is actually a typical corporate disease. Everything is done according to the process, even if the process is more important than customer needs. If it is a small and micro innovative enterprise without a strong sense of customer crisis, it may face bankruptcy and closure. However, in large companies and even listed conglomerates, professional managers or employees may be more concerned about their own future and promotion, rather than the perfection of a certain product. If they do not follow the process, it may actually affect their work and income. We should work together with a heart of understanding to solve problems. I believe there is no simple complaint, the essence of complaint is to expect better solutions.
So,to close this great conversation, could the users who reported issue open a Support ticket ASAP before we ship the whole dev team using the Autodesk airplanes fleet? 
4 Likes
Better send the fleet just in case.
25504564 God speed.
Thanks for opening the ticket. The Support team will ask you to provide the Full Diagnostics and a copy of the project home without the media cache. Please provide these ASAP.
1 Like
Done.
1 Like
Small update. Completely wiping and reinstalling my Linux box with 9.5 and 2026.2.1 has removed both the “Initializing Editdesk” pause, strange performance problems and seemingly any library latency issues I was seeing previously on Linux but continue to see on Mac.
Small victories.
1 Like
lobotomy ftw
1 Like
This was a fucking Poor-Things style brain gutting man.
Obviously, the tricks are lifecycle management and business continuity for projekts.
I’m with Alan on the idea of ephemeral workstations: projekts first, labour middle, hardware last.
Is it uncomfortable?
Yes, it’s like going to the dentist or having your broken arm in a cast.
But stuff gets better when we embrace the future (where I fundamentally disagree with Alan) while retaining only the best parts of a legacy.
Moving on.
I’m also happy that the Flame team are spending time and resources on documentation.
2 Likes
Totally agree, and to be clear: I’m totally down to rip apart boxes and start shit from scratch for an upgrade whenever. I don’t work managed so it takes little time to get a box going from scratch.
My issue here as that there was never indication that it would have to happen. If there was a disclaimer that said,
“Hey to be safe, clear your system off before running 2026” or,
“Don’t easy-upgrade Rocky and install 2026”
I would have said, ok, have to carve out some time for that and then done it. Instead it was SUPRISE and Oscar the grouch in a KFC bucket on fire.
1 Like
100%
Except
Trust Nobody
My 2 cents nobody asked for 
12 machines that are forming the core of the work. 8 artists doing comp and sometimes proj management, 3 editors/juniors running proj management, updates, deliveries. And me in the corner doing anything required at the moment and writing tools and automations.
8 dell preicsions with u.2 15tb drives for cache, junior z8 machines with 55tb arecas.
All machines are on same RL version, all machine groups share hardware. Highly managed infrastructure.
We run 2025.x with small hiccups, deliver projects, share work. Everything is OK. I would love to update to 2026 because of python improvements. Coming from Nuke I hate that nodes are not just accessible through API and I need to check which attributes I can work with on daily basis, but I understand it’s difficult to add a working API after 6 years of development for a garage company like ADSK. Blackmagic is also shit there.
I tried to update to 2026 but
- I did not manage to set up machines to see each other over the network. Documentation is more of a joke but we tried for a few days and didn’t really get anywhere. This is an absolute must for me. The whole workflow is artists sharing setups, timelines and work. This should work out of the box to be even taken seriously. Mind you when I have some free time
I will go back to the project - ML upscale does not work on source images over 1k. I would think with 24gb vram it should not be such a problem. Especially that it works a treat in Nuke on same machines.
- DKU does not ship with correct drivers for the AI tools. We had to manually find tensor drivers to match. That might be also NVidia problem, again I understand it’s difficult for small companies like that to get everything buttoned down.
- Stability issues. Artists are running self contained projects in 2026 to test it and are all reporting various issues not present in 2025 that much what you guys report about lagging etc.
- Projects from 26.2 not being visible in 26.1, just a random thing but I’d expect minor versions to be cross compatible.
- Testing on 6 machines that share hardware, os and installed software (bonus of being part of a bigger studio with really tightly controlled environment) presented different issues that cannot be replicated between machines. At least 2021 and 2025 were consistent
So we are frozen with 2025 just like we were frozen with 2021. Even if it means that the only thing I know about timewarp through API is that it exists
2026 is a sad joke (the product version, not the year, although reading the news in January does not fill me with confidence). Looks like an untested alpha release to me but maybe I’m biased expecting software to work so I can deliver projects.
2 Likes