LÖVE

I develop shaders using Löve for many years, but it's the first time I really don't understand what happens, I really need help here...
I just ported this shader (https://www.shadertoy.com/view/MtGXRK) to Löve and after some iterations I don't have the same result as the model anymore
I suspect that perhaps the floor or mod functions are defective in OpenGL 1.2, or perhaps RGBA32f canvas format is not sufficient for big integers ? (not so big anyway, as the max pile here is 20000, 160000 on Shadertoy)
Any help will be welcome !

For those interested in mathematics and who want to know more about sandpiles, here's a video on Numberphile that explains them :
https://www.youtube.com/watch?v=1MtEUErz7Gg

Lol I was just about to say they did a really interesting numberphile on sandpiles but you beat me to it.

some help please ?

logoliv wrote: I just ported this shader (https://www.shadertoy.com/view/MtGXRK)

Ha that's me

Also i'm currently checking your source code..

Got it : When you draw a canvas it gets converted back to rgba8, I've the same problem with my pathmarcher .

(So when your draw the buffer to temp the shader gets destroyed)

Hi Gijs, nice to see you here as the Shadertoy comments are somewhat limited...

temp is just a placeholder to say to Löve to draw on buffer with love.graphics.setCanvas(buffer) which has 32 bit floating point format ("r32f"). When I draw to the screen with love.graphics.setCanvas(), the information about sand piles is still stored in buffer (which is read only in disp shader)

I've coded other Löve shaders using RGBA32f canvas format and had no problem with it, the difference is that I always stored small floating point numbers and not big integers like sandpiles. As I seriously doubt that the problem comes from a bad port of the functions floor() and mod() to Löve, my best candidate for now is that RGBA32f format has limitations in Löve that are not present in the Shadertoy implementation...

I've also opened a bug report here : https://bitbucket.org/rude/love/issues/ ... on-problem

I replied to the bitbucket issue:

slime wrote:It is not immediately obvious to me what you're expecting it to look like compared to what it actually looks like to you.

However you are sampling from a texture that you are rendering to in the same shader. This is undefined behaviour in all graphics APIs and will result in unpredictable results on any GPU, OS, or framework used.

You also have alpha blending active when your shaders are active, and the temp Canvas stores normalized [0-1] colors rather than floating point since you don't specify any particular format so LÖVE uses the default rgba8.

Do you even need 32 bit floating point texture here? Pretty sure sandpiles require no more precision than 3 bits, making rgba8 format more than sufficient.

raidho36 wrote:Do you even need 32 bit floating point texture here? Pretty sure sandpiles require no more precision than 3 bits, making rgba8 format more than sufficient.

To get the correct result a sandpile needs a lot of sand, not an infinite amount(so no infite replenishing), so more precision is needed.

slime wrote:I replied to the bitbucket issue:

slime wrote:It is not immediately obvious to me what you're expecting it to look like compared to what it actually looks like to you.

However you are sampling from a texture that you are rendering to in the same shader. This is undefined behaviour in all graphics APIs and will result in unpredictable results on any GPU, OS, or framework used.

You also have alpha blending active when your shaders are active, and the temp Canvas stores normalized [0-1] colors rather than floating point since you don't specify any particular format so LÖVE uses the default rgba8.

So how could we inplement a backbuffer correctly?