Hello everybody,
When I was testing the latest version I have realized some of the matchbox nodes are not working. They were working fine in version 2025.1.2.
I didn’t test all of them but these are the ones that give an error code on result:
The error message in console is “PIPELINE : CProcessShader::RenderFrame::CreateRenderGraph”.
Does anyone have the same issue or is there a fix for this?
Hi,
I had the same error message with these JB matchboxes:
JB_erodeMatte
JB_lidar
JB_PixelDisplace
JB_autoMatte
JB_timeDisplace
JB_colorRemap
JB_skyLapse
Possibly related to this? Matchboxes not working in Flame 2025.1 - #6 by lefebvf
I checked a few of those y_matchboxes and they are broken for me as well.
Broken on 2025.2 and 2025.2.1, on linux and mac.
I guess I’ll go back to 2025.1.1
This is a massive deal breaker.
I think this list has gotten worse in 2025.2.1
I’ll take a look on my 2025 Mac test machine today. We were just getting ourselves ready for an upgrade.
@kyener @persona Are you seeing thses errors on Mac or Linux? Probably effects both 
This has been going on since the transition away from OpenGL to Vulkan.
In the old days the matchbox code was more or less sent to the GPU as is. Now a lot more processing is applied. And that can break old code. I’m not sure if ADSK is including some or all of the Logik MX in their automated test suite?
Seems like they fix some issues, but then sometimes that creates new ones.
See old discussion: Matchbox Shaders in the age of Vulkan & Metal - #11 by JasminRoy
Re:2025.2 and 2025.2.1
All adsk matchboxes appear to be running without issue, from the middle of last night to very early this morning, right before some ars(hole)onist set fire to the countryside, taking out power, comms and telecoms.
I haven’t tried the logik matchbook tools.
I’m too busy choosing my new 3 bedroom townhouse next to the country club on the land that just became available.
Freedumb.
@PlaceYourBetts I haven’t checked all of them on Mac but Y_Sample and Y_Blurs are not working in 2025.2 & 2025.2.1 - same as @stu
Took a look at the code of Y-Sample. Not readily apparent what broke, might have time tomorrow to dive in deeper.
I vaguely recall something about now being able to define what GLSL version a shader is using in the documentation. Perhaps there’s something related to that? Some functions working in one version but not another…just an idea.
Yes. All the y_* shaders specify version 120, which until 2025.2 was the common denominator and very old.
It got bumped up to 460 I believe which gives access to some extra features like round() IIRC. That was based on a feature request I made about a year ago.
But that’s not it. I made the error go away last night by commenting out one line in the first pass. Just not sure yet what’s wrong with it.
All the broken ones are multi-pass shaders, but that could be coincidence. Several y_* shaders do work fine and have similar code patterns including the version 120 declarations. It’s something more detailed.
Could also be in the XML
I’m having a million issues with this too. crok_patterns no longer works at all. crok_jpeg’s output is totally funky. is this strictly 2025.2? i just upgraded all the way from 2023.
Was able to figure out what’s wrong.
If you open each of the files y_sample.1.glsl, y_sample.2.glsl and y_sample.3.glsl
and remove the first line which reads
#version 120
it starts working again. I assume the same is true for the other shaders.
It must have something to do with how the new versions of Flame translate the shader code for Vulkan, etc.
In the theory I think the version number is supposed to indicate which version of GLSL is used in the script to enable or disable things.
It doesn’t seem to affect all shaders, as y_aov.1.glsl also has that line and works perfectly fine.
I suspect maybe in the past this line was more or less ignored. But now in the new code it matters, and maybe y_sample uses something that isn’t in version 120, it gets ignored, and the whole thing falls apart (indeed the case, see next reply).
You can try this on other shaders. Just make sure you edit each of the pass files, not just the first one.
If this is indeed the problem, there are a few options:
I’d be happy to file a feature request, but if the impact is that big, it probably should be a support ticket instead. So someone who is impacted would need to do that.
@fredwarren for visibility
y_sample uses at least one GLSL function that didn’t exist until 130.
So it would compute if that version statement disallows that function which would then break the shader.
But changing the version statement from 120 to 130 (also previously supported by Flame) does not heal the shader. So there’s more going on. I didn’t do a full inventory of all the functions and which version they got introduced in.
Ahh 2023. It is still my current version.
Nice work @allklier 
So anyone can modify the .glsl file in any script editor and remove the #version 12 statement (or equivalent)
Correct. Any shader which has not been packaged into an .mx file is easy to edit.
Open your favorite editor, go to /opt/Autodesk/presets/<flame version>/matchbox/shaders. This is where all the shaders are stored. In many cases the LOGIK shaders will be in a subfolder named ‘LOGIK’.
You’ll be looking for the files that are <shadername>.<pass>.glsl, where pass is a number, starting at 1 and counting up for each pass, usually between 3 and 8 or so.
Edit, remove the line and save.
This will not update shaders that are already in your batch group. So you need to delete the shader in the batch group, hit ‘refresh’ in the node bin, and then re-add it. Which is unfortunate because you’ll have to copy over any settings.
If you had an old project with lots of broken shaders, you could do the edit in the /opt/Autodesk/project/<projectname>/batch/flame/ folder set. But that is a bit riskier.
Also you have to do this for each version of Flame you have installed, though you can just copy your changes between version. So you edit once, copy forward into each installed version.
Maybe we can come up with a shell script / sed commandline that bulk patches them safely. See if @philm can help with that.
I did a bulk edit to remove the #version120 line. I tested all the y_XXXX shaders to ensure that are working and everything seems to work except for the y_shape shader
Very cool, thanks for jumping in on that. And good progress.
I fixed y_shape, it should be updated on Matchbook. Only tested on Linux tho
What was the issue on this one? I see that it has a few of the #define shortcuts which are possibly ambiguous with the new preprocessor. Or something else?