Python praise

I give ADSK a lot of well earned shame and shit. But I must acknowledge the immense value that bringing Python into Flame has brought. In my opinion, it is the only thing keeping Flame relevant today. It allows us Artists to expand the capabilities, or straight up fix things that ADSK is unwilling or unable to do.

This is a corollary of the old phrase “Why buy the cow when you can get the milk for free?” Why should they invest in development when they can give their customers the tools to do it themselves and then share it with other customers for free. The more we create our own tool sets, the less motivation they have for developing them. And then why maintain a robust customer service department when customers can just ask Claude. And it’s not just Autodesk. It’s a trend across all industries. Probably not a welcome response but it’s what I see.

Hi Tim,

That is actually a great point. For instance, when you have a ShotGrid enabled project, EVERY export gets registered as a shot. Have a roto ref you want to send to India, that turns into a shot. Single frame markup annotation, that’s a shot. We’ve brought this up multiple times, and nothing. 5 minutes with CODEX fixed it. With all the AI image models, and innovations happening with Comfy, Flame feels like the old paradigm of VFX. The stuff that I and other users have done in just the past 3 weeks is more exciting than anything I’ve seen from HQ is years, I don’t see that changing. Flame is chained by legacy and enterprise lethargy.

From my perspective, I’ve spent 45 years perfecting my craft. I practice it 50-75 hours per week, sometimes even over 80. And I do it with the latest tools and I re-evaluate my workflow with every new version including creating my own toolsets within the application that I modify and build on over the years. I’m already picking up the slack from downsized agencies with ever-shrinking budgets. Not only do I do nearly everything needed to finish several hundred spots per year, but I do my own wrangling, postings and deliveries as well without an assistant. I don’t have time to learn python, or build my own OFX. I’m too busy doing my job. I rely on the vendors I (well, my bosses, anyway) pay a lot of money to. As I approach 70, the one positive I have to say about the future of the business is that it’s looking like a great time to reluctantly retire.

Agreed, I don’t want to have to make the tools, I want to use them.

You can always enable the Element entity and publish to that.

Not the point. There should be a way to skip EVERYTHING shotgun when exporting. Sometimes you just don’t want or need it. Like I said, after years of requests, 5 minutes in CODEX fixed it. Enterprise Lethargy.

I skipped shotgun in flame completely and just use a script to connect batch renders to shotgrid. So i only get what i want when i want it. I love building tools now! I just need testers !

I think there are two things at play here. There’s tools and there’s frameworks. Comfy is a framework. It allows the community to dev tools that run inside of it rather effortlessly. Its purpose constructed to be this shell that people plug into and in that way it is very similar to nuke. You can pass any data type through a connection provided what’re receiving it knows what the fuck to do so with it. That’s similar to Nuke in a lot of ways. If batch had a similar data egoistic policy and say, latents or animation or camera data could be passed between nodes like you pass image data then it’s open season. Then. The framework is modern and open to development. The community jumps in and does their thing. That’s what makes Nuke great and Comfy great respectively while flame has always felt so closed off.

Then there are tools. The foundry like Autodesk makes tools that run inside their frameworks and have largely focused on different problems for their tools to solve. Some overlap but not nearly as much as some of us would like. The dev time for new tools at Autodesk has become much slower and often time focused in a different direction than many of us would like. Hence the sharknado of OFX plugins as of late but even those are hamstrung by an aging framework.

My two cents are the same they’ve been for a while. Fuck the tools, fix the framework. Now more than ever this is the key to longevity in my mind. We’ve proven we can largely build plugins and scripts and other malarkey to hack a moderately unfriendly framework but if the framework were opened and made dev/td friendly like Nuke or Comfy well… in my mind that’s where everyone can really benefit on a massive scale.

Or fuck it we just write our own framework but what a waste.

Hence my request for the “Anything” node. All the exciting stuff is coming from us.

But alas… when even the Framework is broken, what do we do?

Very much agree.

Especially as we hear calls for what ADSK should do this and that AI model/node. Waste of time and energy. Way too slow. Provide some of the foundational ones, and leave the rest to the ecosystem.

The biggest issue Flame has right now is that it’s the most closed-off major platform. It’s Matchbox (very limited in scope) and OFX (works, but has some gaps relative to other platforms - see feature request). Nothing else works.

It’s actually one thing that is the biggest survival risk for Flame at the moment, other than the average age of its user base. This is the worst time to be making it hard for a platform to allow the community to innovate and bridge gaps. When things move as fast as in the last 18 months, frameworks cannot keep speed wise. An ecosystem of community solutions can be the lifeline they need to buy an air pocket. Flame chose to control the ecosystem in the name of quality. It may be its downfall.

Now, few could have predicted what is currently happening, and I wouldn’t blame the Flame team for their choices. But it is up to them to adapt as fast as they can.

Like I said, fix the framework. I don’t use project server but I understand why you need it fixed. The issues don’t effect me but they affect others. Ultimately though I think an evolved editorial workflow that demoted the need for project server in favor of a completely open source editorial management framework, externalized and completely bypassing the existing layer of bullshit we have to wade through to share, ingest, manipulate and export editorial information could kill two stones with one bird.

My inner Bevis though only snorts “Hehe a double-ended Wacom.”

I’ve been debating whether to keep my Nuke license since I use Flame way more often.

In the context of which platforms may survive the current transformation race, it seems wise to keep for a bit longer, especially since it’s a dinosaur of pre-subscription seat.

For every Flame artist I meet there are 20+ Nuke compers. Sometimes being part of a more exclusive group is a plus, unless it’s an endangered species.

I think it far more likely someone vibe codes a viable Nuke before they do Flame because, well, why would you.