Multi pass Shadertoy import - why is my Vuo version different? Idiosyncrasies?

I’ve been trying to import this Shadertoy,

I have it almost working, and the buffering is wired up correctly I hope - but the ripples / waves on my version dissipate almost immediately. I’ve attached a comparison screenshot. I’m wondering if differences in interpretation of GLSL code are the problem. It seems to be something to do with how the color / height values are being read / written.

Does anyone have any clues ?

Hm, not sure yet, but here’s a composition that looks like the screenshots.

LBM3.vuo (10.7 KB)

Yeah Jaymie - that runs exactly like mine :(

I’ve been sweating over this last couple of weeks - originally I tried importing into Processing, then Unity 3D, then JMonkey… but at least I’m getting somewhere with Vuo as it actually has support for Shadertoy.
I’m working on a pilot research project to help kids with autism… the soothing, interactive nature of these shaders is perfect for developing concentration, and stress reduction. It will run as an app in a room with controlled ambient sound and lighting, with possible bio feedback devices. Perfect for Vuo!

Anyway, thanks for your kind efforts - the other software forums I’ve been on have either had no answers or were indifferent.

I’ll keep plugging away and let you know if I get anywhere - I suspect it’s a problem that will be found in more Shadertoys. But it’s SO hard trying to debug GLSL!


Well the closest I’ve got is by fiddling with this piece of code in Buffer A

//enforced motion
        if( distance(vec2(5.0+10.0*iGlobalTime,float(LatSizeY/2)+10.0*sin(iGlobalTime/3.0)),vec2(ix,iy)) < 4.0)
            rho = 1.1;
            w = 1.0;

for example changing the rho value increases the ‘hot spot’ to give longer trails, but it’s obviously not fixing the problem.

Yeah, we haven’t been able to solve it either.

The problem might have to do with precision, like if the shader is assuming a 32bpc texture. (It would help to know what kind of texture Shadertoy is feeding into iChannel0. We weren’t able to figure that out, but please let me know if you do.) There’s a chance it would be fixed by 32bpc Color Accuracy.

Your goal sounds fairly open-ended: soothing, interactive graphics. Maybe there’s a different implementation of the Lattice Boltzmann methods or a different fluid simulation that would work? Have you seen @George_Toledo’s Water Simulation?

Yeah I was thinking it was a precision issue too. You might be right about 32 bit - but I’m confused, according the the shadertoy changelog…

  • Multipass rendering is here! Intermediate render targets are 16 bit (which means no hacky pack/unpack operations)
    Hello proper Depth of Field, SSAO, Motion Blur, HDR, gamma control, incremental monte carlo rendering, games…

But on this open frameworks forum - where someone has apparently converted a multi pass shadertoy - I noticed in their code they are using a 32 bit texture!

So Vuo doesn’t have 32 bit support yet - is there any kind of hacky work around?

Thanks for the Toledo links - that could be a plan B!

You’re right Jaymie - it should be 32bit!

I rebuilt it in openFrameworks and compared the results of 16 bit and 32 bit buffers.

So for the minute I’ll use openFrameworks, but reluctantly, as I despise Xcode. Vuo is so easy to use, I hope you build in 32 bit support soon!


To summarize from the comments — These shaders require 32bpc color depth. Vuo 1.2.3 only supports up to 16bpc.

@glennmarshall, thanks for confirming that it works in OpenFrameworks.

In our code under development, we added experimental support for 32bpc and confirmed that the composition renders correctly. We’ll follow up on feature request 32bpc Color Accuracy.

[Edit: The Shadertoy node now has the option for 32bpc.]