So we all love Matchboxes. And quite a few of us have written some. Quite a few of us have also written python scripts for a variety of complex workflows. This has made Flame a better tool.
As I watch the Nuke eco system, there’s a wealth of 3rd party gizmos and nodes.
I’m late to the Flame party and Sparks were already gone. So now all we have is Matchbox and OFX. That leaves a bit of a gap in the middle.
Matchboxes are constrained because they only run GPU code. Great for some algorithms that easily translate into GLSL, but there are other useful things that just don’t run that way.
OFX is of course flexible, and I’ve tinkered with OFX plugin code, but never finished. Because it’s a significant lift. C++ and a complex API. Really more for full-time plugin developers.
The Python API of Flame allows you to manipulate media, timeline, and and node trees. But I don’t think it can be used to actually build a custom node, or did I miss something?
Is there a blank space in the middle where a custom Batch or Action node could be written either in python, or maybe a C/C++ API that is simpler than OFX? Things that don’t need a complex user interface, or maybe just using the same paradigm we’re used to from Matchbox? Maybe even the same API as Matchbox, but CPU based. You get your passes, you access your textures and you return a texture.
That could allow for all kinds of interesting nodes that go beyond GPU code. Of course it could also create yet more clutter.
Before I fill out a feature request, I thought it would be good to check here…
A Nuke Gizmo doesn’t even need programming from my understanding. Isn’t it just a group node with exposed controls of certain values for nodes within it so it appears as a single node?
I think it could theoretically be possible utilising Flame groups, expressions and some kind of dummy control node that you could save in your user bin but it certainly wouldn’t be as elegant as a Nuke Gizmo. Certain things wouldn’t work though and the control node could end up being more clunky than just opening a group node and adjusting within it.
I like the idea of custom nodes. I did play around with matchboxes but found the compiling to be not interactive enough to figure things out.
How about a cpu based interpreter? Like an IDE (interactive development environmet) within batch? Or for the lack of a better example: Shadertoy in batch.
On the simpler end of the spectrum, maybe we could have Nuke’s gizmo like packaging. You have input tabs, your nodes and an easy way to expose variables with your output tabs…
I think if there was a simple interface builder out in place for Flame… something that would allow you to group a bunch of nodes, create some basic ui elements like you can do in Houdini, link those up and save, you’re home.
That same gui building interface would be clutch for inference and matchbox controls…
We have a custom OFX that a guy made for us, which didn’t seem like it was that big of a task for him. Of course, that guy authored Sapphire and is on the OFX steering committee.
There is a matchbox that ships with flame, possibly in the examples folder called something like UI Only that can be used for exactly this.
Dupe its folder into your usual matchbox location, from memory I think there’s 4 files, delete the .mx file as it’s not needed, the glsl file is empty and stays that way as there’s no image processing happening. One of the remaining files holds all of the UI data and you can modify it to do what you need. Give it a new name, label the controls, set max min values then link them to what you want.
Yeah, you can do this, but to be able to name and define your variables you have to make a dummy matchbox. I did it once, but I’m so bad at code it took me all day to create the matchbox.
Having a “gizmo panel” added to the group node where you could define and name variables would be a huge improvement. (see my post above this for the FR)
I recently wrote a pybox interface with comfyui, and pybox is quite hamstrung, and out of date (and very fussy). The only way to interact with it is via passing single frames back and forth, through a common network location. And even then, the inputs and outputs must all be the same format and resolution (so there goes any kind of upscaler, or temporal anything). Plus, it doesn’t support many file types, nor many bit depths for the types it does support.
Having a way to read/write from the media library in python would be quite useful.
Thanks, Alan. I’ve not looked into it, but it seems that it’s python 2.7, comfyui is python 3.1, so it might take 2 scripts. Could be fun though. Thanks for pointing that out, I should have looked closer.
After looking at a couple of the examples, I think you’re right (even though the copyright date is 2016 lol). My point still stands - pybox is in need of an update. Perhaps it would have better uptake.