This question was raised briefly during the Flame 2024.1 Logik Live, but I don’t think we had a comprehensive answer. Diving into the world of matchbox code, the question came up again. I may be missing some details not covered in the previous forum threads or documentation.
Matchbox shaders are central to Flame. They’re based on OpenGL. The documentation indicates that Flame Linux supports OpenGL 1.30 and Mac supports OpenGL 1.20. The most recent version of OpenGL is 4.6, which seems to be the end of the road in favor of development of the Vulkan API, which Flame 2024.1 just adopted, in parallel to Metal. There are GLSL code snippets like various blurs available online that rely on functions that only work in newer versions of OpenGL, but may not work in current Matchbox shaders.
With Sparks having been deprecated, OFX and Matchbox are the primary ways of extending Flame, with Matchbox being much more accessible in terms of coding effort.
Can our ADSK friends provide some information on how the Matchbox roadmap looks from here, with OpenGL fading into the background? I’m not familiar with Vulkan - but reading high-level description it doesn’t seem to be backwards compatible. Adding to that, how is this affected by larger divergence between Linux and MacOS in terms of graphics APIs.
One possible option - which seems similar to Resolve’s DCTL, is to create a OpenGL interpreter that lives inside the Flame code, that translate OpenGL constructs into actual back-end APIs. Adopting OpenGL as a quasi pseudo/intermediate language for matchbox scripting.
That would provide OpenGL script execution, that is in reality layered on top of Vulkan & Metal. I suspect some of this is already in place as OpenGL is no longer available in recent Mac OS releases. That may explain why there is a support difference between Linux/Mac for Matchbox.
That’s a bit of work, but certainly viable, and would make existing shaders backwards compatible. However, it would be nice to have any such support at least updated to newer OpenGL versions so that more powerful algorithms can be put into the shaders.
It would also be nice for those who might be inclined to do more advanced coding to have access to Vulkan directly inside shaders.
I saw one of the devs get tagged on a siggraph Vulkan talk on LinkedIn where he talked about the rewrite. He specifically mentioned that they addressed this in a way that people could keep writing matchbox. I will find the video when I’m near a computer later and link it here.
The other open question: The slide in the video shows that Flame is now translating from GLSL 1.2 to 4.6 as the first step in the abstraction. Is there a way to write shaders to GLSL 4.6 standards with access to all the new functions? Of course may not be backwards compatible with versions of Flame prior to 2024.1 which would be limitation on those shaders for a while.
Example: In one blur algorithm I came across, it wanted to use the round() function, which only starts in 1.3, not 1.2.
Not a burning problem, but if feasible would be nice.
At present on the Mac shader-builder does not report any syntax/semantic errors while compiling. Linux does. That makes it much harder to write shader code on Mac. I realize some of this may come from the abstraction layers that converts old-GLSL into other intermediate forms, and those translation utilities probably don’t run a full syntax/semantic analyzer but some basic regex reformats, hence that behavior. It’s however a massive tax on the shader author. You almost have to write it on Linux and then just test it on Mac. That would be even worse if the Linux version loses these error messages to in future versions due to the graphics abstraction layers in 2024.1 and forward (I’m still on 2024 on Linux right now, so haven’t checked).
With Flame 2024.1 and Vulkan, we now cleanup matchbox GLSL shaders on load time to make sure they are compatible with the more modern Vulkan API for backward compatibility.
We did not plan upgrading the supported GLSL version for Matchbox in Flame 2024.1, although this is definitely something we could plan for a future release if there is enough requests from the community, so I highly suggest you open a Feature Request for this.
