when i use matchbox —> the noise
it happen like picture (have a square line inside fractal noise)
How to fix it?
my machine is mac studio
Might be how this particular noise function is coded.
If you increase the scale parameter the geometric shapes eventually become invisible (indistinguishable probably more accurately). A value of 25 might do the trick. Or change to one of the other algorithms.
I don’t know this shader or who coded it. But looking at the code, the logic is different than what is described here: The Book of Shaders: Fractal Brownian Motion. Doesn’t mean it’s wrong, just different.
1 Like
I tried it on Linux with the same settings and it was fine.
Interesting - I tried it on a Mac, and not the same results, but another flavor of the same.
uh oh - cisc vs risc and all that, all over again…
x86 and arm…
discrete gpu and embedded gpu…
Assuming this is all 2025, more like different GLSL emulations. Might be all kind of goodies hiding there, on the edges of math to create beautiful noise patterns.
No, i faced this same issue some weeks ago on 2024.1.1 M3 MAX
@allklier - yep, probably - it’s hard to do cross-platform work, especially for GPU stuff…
Even bash doesn’t do the same things on Linux and macOS.
Sigh…
Curious indeed. Tried it on 2025 Linux, and like Tim, no problems there.
The code relies on sqrt, min/max, fract, floor, sin functions from GLSL. These should all be deterministic despite platform.
Something else is amiss here. But that would require a much deeper dive into the code.
@allklier - life is short.
1 Like
Cross-platform consistency has been a problem for a number of decades.
Remember when you needed to buy a supplemental FPU for your pc?
It’s worse now - I would try to calculate how many times worse, but my result might be different to someone else’s…
1 Like
I rarely use anything but linux, bur recently was forced to revise a linux made batch on a Mac Studio. A bunch of the white levels were changed on certain elements like they were clamped.
@ytf - flame project color policy?
Ah, FPU - ancient history, but yes, I do remember. Those were super cool back then.
1 Like
No. It was all rec 709 and properly tagged.
This looks a little like using uninitialized variables, but a brief look at the source I’m not seeing anything that jumps out, but would have to analyze it a lot closer…
1 Like
Found a few issues, but no clean fix in the code in the time I spent.
There are two fbm methods of same name, one with vec2 and one with vec3 doing different things. Not sure if glsl (or the Flame emulations) support type overloading?
If it were to resolve to the earlier fbm method, it relies on two parameters from the concrete noise, however in the XML they’re not duplicated for FBM and may result in uninitialized variables.
And the code relies on the global ADSK input adsk_time which seems to have an impact on the pattern. Maybe that broke or doesn’t work the same between platforms.
And lots of fun easter eggs in that code (of the good variety).
I would switch to the ‘Fractal’ type. It’s similar in result, but uses different math and doesn’t break on the Mac.
2 Likes
It was Ivar (crok), he’s sorely missed in our community. I remember he made it and forgot to add Crok to it and so it’s just “the_noise”
2 Likes
Works fine on my linux box, but not on my M2 macbook, however, it also works fine on my hackintosh, Radeon RX 580 GPU.
1 Like