Upvote the expression node here…or don’t. Your choice.
Don’t want to sound like I’m forcing you.
5 Likes
1 Like
Sorry for getting back to this late. I posted this morning, and didn’t expect it to take off like this while I spent 8 hrs driving across Montana 
My issue with Matchboxes as they exist, is that some very basic programming paradigms just don’t fit like GPUs run.
For example, there is no easy way to compute an average or min/max of a frame, and then iterate over each pixel and compute the distance, or pass this one-time value on to another pass.
The whole matchbox code gets called once per pixel in the texture, and the only thing you can pass onto the next texture is the result of the previous pass.
In CPU based programming (like python snippet) none of that would be very hard to do.
Which why I was thinking the simplest solution would be a Python based Matchbox node. Exact same API in terms of passing parameters and results, but the code would be called once per frame, not once per pixel. It then runs a python script and do whatever. it needs to do.
Of course not as efficient as a highly parallel GLSL script. but that’s not the point here. It’s meant to augment, not replace.
And yes, Matchboxes are not easy to program. No debugging capabilities. Also you want to run the compiler on Linux, where it gives you error message. The Mac version of the compiler is less usable.
This would be so simple and so powerful. I think I’ve asked about that before too.
Regardless of the custom node concept we should make a feature request for that, if we don’t have one yet.
1 Like
Building an OFX plugin isn’t rocket science. There’s plenty of documentation and code samples. An experienced C++ programmer can definitely sort through this in a day.
But it’s still a significant bar to clear for most Flame artists that are familiar and semi fluent in Python. And that makes me think there’s a missed opportunity in the middle there.
1 Like
@mybikeislost - showed me a lovely tool in nuke called knob twiddler or something.
it basically exposes nodes in nuke so that they can be programmed, turned into gizmos, etc.
now that would be a really interesting tool for flame.
the problem that we face is, nobody wants to waste time on a plugin/ofx/matchbox that has no clear definition and would need to survive flame version updates - look at what happened with PySide6 - three or four people had to go down rabbit holes to fix something they hadn’t broken.
i appreciate that this continued push toward the vfx reference platform is crucial, so it’s an inevitability.
but developing stuff for people to not use, or worse, complain about…
where’s the incentive?
Make a batch, collapse it into a node/compass, add some sliders, expressions etc. and define some outputs all within Flame. Keep it as user friendly as possible for maximum use.
UPVOTED @andy_dill! I think if we could get this working it could really blow up.
I know its not that simple but if made easy for the artist to create, the more likely people will utilise it. Having fumbled through making a few matchbox’s, it’s too time consuming and steep a learning curve, at least for myself.
I’m all for smaller batch schematics and being more efficient. It’s mostly why I’ve made matchboxes. To @philm point, they have the potential for version issues and quirks that I don’t have the time to solve. At least with something collapsable, other people can pickup and improve upon. Try copy and pasting 10 layers of glsl into something other than what it was originally, then make an XML sidecar. It’s pretty painful with little or no knowledge of coding. I’m grateful for the platform to make them but its not ideal.
1 Like
I totally agree!
Expression node is really simple and powerful node in NUKE, also BMD fusion has ‘Custom Tools’ node which is similar to NULE’s expression node.
I think another powerful function in NUKE is the 3D transfrom which can be handled with matrices.
1 Like