Mykhailo Moroz

Yeah I was aware of iResolution, I just never used the z component, but I guess I should still add it for compatibility.
Mouse zw has no equivalent in Compute toys, so that needs to be added in the first place.
Texture mipmaps for the pass-in/out buffers are not computed unfortunately

Of course there are still some minor differences:
* matrix multiplications are not a*b but mul(a,b)
* no GLSL texture types like sample2D / etc
* there are no "Shadertoy" channels, you need to resetup them to use absolute indices of the pass_in/out buffer

Slang can be made extremely close to GLSL/Shadertoy style of shaders by using a set of defines and typealiases, I've made a template in compute.toyts just for that compute.toys/view/1947
I also ported my most popular shadertoy using it:
compute.toys/view/1948

Compute.toys finally got the Slang compiler integrated, which means its finally time to ditch WGSL 🎉🎉
I've ported my FFT to it, coding in it is much nicer. compute.toys/view/1922
Should try something with its autodiff next.

Faster Mixed Radix FFT Forked from https://compute.toys/view/1914 Faster version

Made a mixed radix FFT implementation in compute.toys/view/1915
It is neat, but I still wonder how do you properly handle large prime factor size FFT's?

I mean its just SPH, its not *that* difficult

No, its written by me, that's why I can not answer your question easily.

uhhhm, shadertoy?

The answer to this will require a whole new blog post I'm afraid...

Shadertoy

I've also tested out using it for nontrilinear stuff as well as volumetric integration
shadertoy.com/view/w3sXzf
shadertoy.com/view/t3sXzX
shadertoy.com/view/t3lSzf

I've ported my vrchat isosurface ray tracer to shadertoy and added it to my fluid simulation there.
Its probably the fastest multibounce ray tracing for liquids I've made thus far.
shadertoy.com/view/w3sXzs

Shadertoy

I posted my own implementation of the trilinear isosurface intersection on shadertoy
2 methods, one is the one from jcgt.org/published/00... and the other one is my own idea of using 4 trilinear samples (can use HW samplers here) to reconstruct the cubic.

www.shadertoy.com/view/WXS3Rm

Managed to get Nvidia Flow (PhysX) to compile and run, after initially failing the other week. Was curious for a quick peek now that it's been open sourced (github.com/NVIDIA-Omniv...)

Flow itself isn't CUDA based, but instead uses compute shaders

Some higher level observations in the replies 1/?

I've also finally implemented sorting of the simulation particles, gave quite a nice performance boost (around
3-4x)

till surprising to me just how fast this turned out to work, my older attempts at ray tracing density isosurfaces were horrifyingly slow, and on top of that less accurate too, as it was just constant step ray marching.

The paper was about tracing SDFs but you can apply it to any isosurface of an interpolated 3D volume, like the liquid density.

The Nvidia paper from above also shows how to optimize those intersections quite significantly, giving a fast way to get the coefficients of the cubic as well as how to solve it quickly (would be great if it wasn't patented by Nvidia tho heh...)

Shadertoy

The ray tracing algo is essentially a 2 level sparse DDA ray marcher which finds voxels with the liquid isosurface passing through them. When its found, a trilinear surface patch ray intersection is performed (solution to a cubic equation shadertoy.com/view/tlycDK)

I've been improving my VRChat liquid simulation for the last few weeks. Of the most notable things that I've implemented is a ray tracing algorithm over a 3d texture isosurface (using some ideas from jcgt.org/published/00...)
Its surprisingly performant for VR resolutions!

still better tho (or maybe its cause im twitter blue or whatever)

Is it me or is bluesky video quality absolute trash

GitHub - d4rkc0d3r/CompactSparseTextureDemo: Small demo project showing how to compact sparse textures on GPUs efficiently in unity. Small demo project showing how to compact sparse textures on GPUs efficiently in unity. - d4rkc0d3r/CompactSparseTextureDemo

P.S. the (arguably cursed) mip map prefix sum method
github.com/d4rkc0d3r/Co...

But other than that its very similar to my old VRChat fluid sim, except now I can have proper separate particles with their own data that isn't lost (like color in the video)
(also I no longer use Custom Render Targets (they are cursed))

The grid now stores the minmax id's of the particles in this cell, its done by rasterizing points with vec2(id, N-1-id) with min blending (to get min and max). If a particle didn't get into this grid, its afterwards additively rasterized into another average particle grid.

I'm slowly porting my approximate grid SPH simulation to VRChat. It did require few improvements to be stable enough, now its a hybrid neighbor index/particle average grid.
Still need to implement
@d4rkpl4y3r.bsky.social 's mip counting sorting method for improved performance.

I usually render particle fluids with particles, as it gives the most details, but here I tried using ray marching for the fluid. It certainly is much more liquid like, but at the same time its slower and loses some detail. I wonder if I can improve this. compute.toys/view/1809

Shadertoy

I initially tried to do so in Shadertoy, but my approach there was losing the initial position data, which essentially just broke it, so I could only do "high viscosity" instead shadertoy.com/view/M33Bz2

I tried to apply my previous simulation approach to model soft bodies. By keeping the initial positions and using those to create springs between particles with spring length being the distance between initial positions its easy to make a soft body sim.
compute.toys/view/1807

Not sure if I have seen this applied for Lagrangian fluid simulations before, you may correct me if someone already did something like that (probably yes).

Without a viscosity term the approximate SPH simulation does start to "boil" with time, which is expected. But thankfully even a low viscosity fixes this.