I’ve been vibe coding a bunch of nodes for ComfyUI and it’s absolutely amazing. I vibe coded a Gmask node for Comfy, but mostly it’s just boring but important stuff for naming conventions and file system ordering and some basic time remapping.
I want to start doing the same for Flame, but guess it will be a bit more complex. Just wondering if anyone has any tips or potential gotchas. Where would I even start? Creating Matchbox nodes right? Any top tips much appreciated, before I break my Flame
Hey Rufus,
I did some matchboxes in the early days with chatGPT with some struggles. But with Claude it is much easier nowadays. Give it the samples from Autodesk and also the uncompiled matchboxes from the Portal.
You could also have a go at creating an OFX. I’m told it’s easier than before while giving you more capabilities, but depends on your chose application, of course.
What’s on my list? Well, I’m planning to create a more general, usable particle system…
Make me an OFX plugin compatible with Autodesk Flame 202X.X on <OS> using the latest OpenFX SDK. I need it to do.........
I recommend using OFX because it can do almost anything. It is basically like being able to have a whole other app running within Flame that has a built in Frame Input and Output mechanism to Batch. We have some very unique in-house plugins, and they can be GPU accelerated. Both Claude and Codex are well versed in OFX so you don’t really need to give it prior work.
Over the last six months, I’ve built so many Matchbox shaders with Claude that I’ve lost count. I’ve created a Flame pipeline tailored to my specific needs, as well as standalone Mac software that fits my workflow perfectly. In my experience, the best approach is to have Claude organize everything neatly on GitHub ideally using a separate repository for each project. Claude can actually teach itself new skills, this is crucial because it eliminates the need to research what you want every single time. If something fails and gets fixed, the skill updates so the error doesn’t recur. It’s worth establishing these skills before building anything, it takes time and consumes a LOT of tokens, but it pays off. It’s also incredibly helpful to have Claude communicate with the Flame console. I don’t give it direct permission to execute commands itself, instead, I copy the code it generates into the console and send back the output. This way, Claude knows exactly which API calls to use to manipulate specific elements within Flame. When starting a GitHub hosted project, my strong recommendation is to have Claude generate a HANDOFF.md file listing all changes made once the basic script structure is in place. Then, open a new chat and create a branch to work on just one specific section, this saves a massive amount of tokens. Once that part is done, simply tell it to push to main, and you can continue in a new chat with a new branch. The HANDOFF.md gets updated, and the new chat only needs to read that file, saving even more tokens. It’s truly impressive what can be controlled via the Flame API, the possibilities are limitless. I haven’t managed to break my Flame setup yet.
One good question to ask as you dive in: Am I making a personal tool for my specific workflow, or for specific project I’m working on, or am I enhancing the Flame ecosystem for everyone, solving some of the gaps I see, but that I know others have discussed as well.
It shapes how you design the tool and how you build. And if you’re up for helping others use it and fix bugs if needed. If you support both Mac/Linux, older versions, etc.
No right/wrong answer. You will get vibe forum glory points one way or the other.
I’ve had great results writing OFX in both claude code and codex. Both can one-shot matchboxes very quickly in my experience but as Alan said you can basically do anything with OFX.
This is important too. Many of the tools I made, the original plan was to open source. But then I realized I am making something so specific to me and my infrastructure, that trying to accommodate the global usership, would be a software developer job.
It’s interesting that we mostly all come to this same conclusion.
Making stuff that works for everyone is very difficult and mostly thankless.
Makes one wonder how the flame dev team focus on anything at all.
I think there’s a simple bifurcation in dev. You can quite easily set out to make a tool that works for everyone but quickly understand that you’re not solving a problem that exists for everyone. You’re writing something that enhances your workflow and solves an inefficiency you see. Maybe others have the same issue maybe not but it’s something that’s plagued you enough that you decide to take matters into your own hands. If it works out to only be for you, that’s ok. You’ve made your you-to-flame-pipeline more efficient and well done.
The second area is when you set out to dev something that fills a hole that you know EVERYONE has. That’s when it gets complex and you have to start thinking of how others will use things and what they will ask for. I’ve found in those instances, limiting the scope of the project is key. Very distinct objective, locked feature set and clear scope of work. It’s crucial to not get caught up in the “how long is a piece of string” development trap. These projects are difficult even when the objective is obvious and the scope is well defined simply because it’s just not enough to just think like “you.” You need to think like the person you disagree with and let’s face it, that’s fucking rough especially if you’re the stereotypical egomaniacal Flame artist we know we all are to some degree.
I personally think @MikeV has a heart of gold for having both authored as many incredibly useful tools as he has created over the years while at the same time not murdering anyone. It’s inspiring.
And the circle is complete. Stop complaining about Autodesk not developing as fast as you with your specific software.
It’s not about “as fast”, it’s about flawed and sub-par implementation. As you say, a circle of shit.
I’ve used Claude Code to make all of my Matchbox shaders. Works great and I shared most of them with the community. They might be specific to me but I thought sharing might possibly benefit one other person.
I’m also working on OpenFX tools with Claude Code. It’s going fine… a lot more complicated but a lot more potential. You can basically run anything visual you want through OpenFX.
I’m happy to share my workflow either via Youtube videos or maybe a Logik Live if people are interested.
Yeah I think it would be a great subject for a Logik Live @andymilkis @Jeff .
Thanks for everyone’s replies, super super useful. Obvi will just feed it all into Claude Code and get going.
I would be happy to share all I create with the community. Also happy to share my Comfy Custom Nodes. Just trying to push comfy in to a more traditional VFX type workflow.
I guess the place I’m coming from with Flame nodes is just the little things mostly. I have a bunch of requests on the Flame Feedback Forum that I think would be useful and not too difficult to implement. But they sit there for years not getting voted for because everyone votes for the big ticket stuff. Anyway as it stands with Comfy, I can knock basic stuff like that up in 10 mins. So if I could do the same for Flame would be great.
Also having used comfy for a while now theres some really useful tools and workflows that I would like to implement in Flame.
Great discussion.
It also highlights what my worry is about the vibe coding trend.
On one side it’s amazing that you can build your own hyper optimized pipeline that makes no compromises, makes you faster than ever.
On the other side, what makes this Flame community grand, is that people share their additive keyer setup (or your favorite non-platform feature) made out of standard components. Everyone can use it, and we’re all better off.
With the onset of vibe coding, there no longer is one Flame solution. There are 500 individualized Flame solutions. And someone might jump on the SOS Discord channel with an ask for help solving a problem. Or someone might post the next additive keyer setup. But it relies on a vibe code component, oh and there is no Mac version, and oh, it doesn’t support the file format your footage is in. Someone might have time to explain it, but not time to adapt/fix it. It also makes it harder to work on someone else’s Flame/project if suddenly your favorite vibe package isn’t there, and you’re not allowed to bring it with you.
With the power to write code for yourself, the community becomes weaker. The energy stays in your suite, rather than being shared.
It also makes it harder for ADSK to make a good roadmap. If everyone solves for themselves, it’s harder to see what the next platform feature should be. And Alan may stop complaining about ADSK, and they may go off and do other things instead.
I’m fascinated and excited by the opportunities. But I also hope that some of us who can afford it, will continue to make this community stronger. Including making code they build multi-user, or maybe spending a weekend or two solving a problem we all would love a solution for. This will take more than ‘happy to share my vibe coded xyz’.
If there is one good thing that comes from all of this though - I think there is a broader understanding of what it takes to develop software, and that it’s both simple and hard at the same time. At a minimum this will make conversations we have with ADSK better.
There’s never really been “one” flame solution. Not really. Definitely not in the sense that there is a “correct” way of working in Nuke versus going rogue. That’s largely in part to the different ways in which Flame is used. Nuke by comparison is a hammer for nails. One you get into Nuke Studio that changes a little but if we’re being honest, not really and not for many. That’s partially what makes Flame unique. Flame dev would likely be amazingly much faster if it didn’t have to support all of the different workflows in all these different areas.
Can you imagine if everyone just worked unmanaged/published how much further we could come along with all of those workflows? Right now, at the core of the user base there is a fundamental schism in how people simply store and interface with their working data. Like the core of the user base is bifurcated at a foundational level.
That’s a bigger issue than whether or not you have your hooks. If I had to go back to working managed I would be low-key lost while I relearned not having instant access to every version of everything I processed without having to hunt for anything. What an awful way to live.
If only we could go back in time and remove all requests or suggestions to cache motion vectors.
What a mistake…
Hope in 5 years we can say we made it better, not worse.
In 5 years god only knows what any of this looks like. I will say this though in addition to my other comments:
Flame has historically also been plagued by typical classism-esque issues of economy. In the old days if you could afford the extra 250K for the license and the additional 250K for the extra large Onyx with the bigger IR graphics or later the extra RM10 and HDIO board you could do things that someone else couldn’t. Back then it was 12bit and grain (and run the built-in calibrator in the Barco Megacal), or later HD and SD io.
The cost of most full spark packages was prohibitively expensive. Often times a shop might have a couple licenses of Sapphire but only one of Ultimatte, or some other specialty plugin. Rarely did every machine have everything. And rarely could every machine DO everything. There were mixes of Octanes and Octane2s and Flints on O2 and big Iron Onyxs. You could easily create a setup in on place that couldn’t render in another–or even playback on another.
Creation of specialty tools for these machines in those days was nearly impossible and financially impractical–flash forward to Linux and later to Mac and things have certainly changed but not the development end of things by thrid parties. As the number of seats has dwindled the incentive for outside dev has hit an all time low and I believe what you’re seeing now if a massive knee-jerk reaction to being the red-headed step child for SOOOO many years.
Finally people have ideas AND can realize them. That doesn’t mean that we shouldn’t have some sort of notion of what we’re putting out into the world but I do believe the idea that simply because people are vibing their way to a happier future with these tools we are some how endangering the future is a bit of an alarmist perspective and lacks a tiny bit of historical perspective. At the core I get what you’re saying of course…
You’re right, we come from different backgrounds and with different stories to this.
It’s great that writing code is now within reach of everyone here.
I’m hoping the blend mode for vibe + platform might be ‘screen’ instead of ‘add’. B + A(1-B).
Present world conditions show it takes a lot to build communities, but they are fragile and dent easily. Hmm, too alarmism. Scratch that…
Vibe away. Mind the community when feasible. B > 0.5.