Uploaded March 2022 | Updated September 2026, 1 week ago
The Slow Mo Guys did a video about liquid gallium on a vibrating speaker membrane, wondering what it would look like in simulation: youtu.be/A9J1gkw9BI0?t=135
Well, I can now simulate liquid metal with my FluidX3D software, and it even runs in real time.
Note that I couldn't do the simulation with 1:1 the physical parameters of liquid gallium, as it just wouldn't be stable. The parameters that I used are (in lattice units): box size 128x128x96, density rho=1, kinematic shear viscosity nu=0.01, force per volume f=0.0005, surface tension sigma=0.005, peak velocity of speaker membrane u=0.09, frequency of speaker freq=0.01.
The raytracer here does reflections only at a depth of 2, so 1-3 rays per pixel.
The simulation software used is FluidX3D, an OpenCL implementation of the lattice Boltzmann method. FluidX3D runs at peak hardware efficiency on the worlds fastest data-center GPUs, on gaming GPUs and CPUs and it even runs my smartphone.
The fluid simulation is done with the lattice Boltzmann method (LBM) with the Volume-of-Fluid (VoF) extension and piecewise linear interface construction (PLIC) for surface tension.
VoF-LBM provides a 3D grid with fluid fill levels, used as isovalues for marching-cubes, which generates a contiguous triangle mesh representing the water surface.
Marching-cubes: paulbourke.net/geometry/polygonise
Raindrop simulations: doi.org/10.1186/s43591-021-00018-8
Volume-of-Fluid: doi.org/10.3390/computation10020021
Esoteric-Pull: doi.org/10.3390/computation10060092
FP32/FP16 mixed precision: researchgate.net/publication/362275548_Accuracy_and_performance_of_the_lattice_Boltzmann_method_with_64-bit_32-bit_and_customized_16-bit_number_formats
FluidX3D: doi.org/10.15495/EPub_UBT_00005400
With raytracing I shoot light rays from the camera through the 3D isogrid. For each grid cell that a ray traverses, I run marching-cubes to generate the triangles on-the-fly, then check for ray-triangle intersections with any of these triangles. If the ray intersects, I don't use the flat-face-surface nromal of the triangle, as this would lead to visual artifacts on the reflected/refracted rays. Instead, I interpolate the surface normal at the intersection point in order to have a smoothly appearing surface. How does surface normal interpolation work with marching-cubes? I get the normals directly at the lattice points with gradient (central derivative) on the isogrid, then do trilinear interpolation to the intersection point. This is only computed once, after the intersection point has been found.
The 3D lattice that the LBM provides already is one of the ideal acceleration structures for raytracing. Any ray only has to check for possible intersections with isosurface triangles contained within the traversed grid cells. This makes it - when the lattice is not too large - even run in real time on any OpenCL 1.2 capable GPU with enough memory. No RTX or "professional" GPU required.
Also see the most realistic raindrop simulation ever done: youtu.be/9Rfu9ZqW894
Timestamps:
0:00 intro
0:03 simulation start
0:29 almost melts the GPU
1:15 pressure waves from speaker membrane
1:32 isosurface mesh generation
2:15 outro
#FluidX3D #OpenCL #Raytracing #GPU #LBM
The Slow Mo Guys did a video about liquid gallium on a vibrating speaker membrane, wondering what it would look like in simulation: youtu.be/A9J1gkw9BI0?t=135
Well, I can now simulate liquid metal with my FluidX3D software, and it even runs in real time.
Note that I couldn't do the simulation with 1:1 the physical parameters of liquid gallium, as it just wouldn't be stable. The parameters that I used are (in lattice units): box size 128x128x96, density rho=1, kinematic shear viscosity nu=0.01, force per volume f=0.0005, surface tension sigma=0.005, peak velocity of speaker membrane u=0.09, frequency of speaker freq=0.01.
The raytracer here does reflections only at a depth of 2, so 1-3 rays per pixel.
The simulation software used is FluidX3D, an OpenCL implementation of the lattice Boltzmann method. FluidX3D runs at peak hardware efficiency on the worlds fastest data-center GPUs, on gaming GPUs and CPUs and it even runs my smartphone.
The fluid simulation is done with the lattice Boltzmann method (LBM) with the Volume-of-Fluid (VoF) extension and piecewise linear interface construction (PLIC) for surface tension.
VoF-LBM provides a 3D grid with fluid fill levels, used as isovalues for marching-cubes, which generates a contiguous triangle mesh representing the water surface.
Marching-cubes: paulbourke.net/geometry/polygonise
Raindrop simulations: doi.org/10.1186/s43591-021-00018-8
Volume-of-Fluid: doi.org/10.3390/computation10020021
Esoteric-Pull: doi.org/10.3390/computation10060092
FP32/FP16 mixed precision: researchgate.net/publication/362275548_Accuracy_and_performance_of_the_lattice_Boltzmann_method_with_64-bit_32-bit_and_customized_16-bit_number_formats
FluidX3D: doi.org/10.15495/EPub_UBT_00005400
With raytracing I shoot light rays from the camera through the 3D isogrid. For each grid cell that a ray traverses, I run marching-cubes to generate the triangles on-the-fly, then check for ray-triangle intersections with any of these triangles. If the ray intersects, I don't use the flat-face-surface nromal of the triangle, as this would lead to visual artifacts on the reflected/refracted rays. Instead, I interpolate the surface normal at the intersection point in order to have a smoothly appearing surface. How does surface normal interpolation work with marching-cubes? I get the normals directly at the lattice points with gradient (central derivative) on the isogrid, then do trilinear interpolation to the intersection point. This is only computed once, after the intersection point has been found.
The 3D lattice that the LBM provides already is one of the ideal acceleration structures for raytracing. Any ray only has to check for possible intersections with isosurface triangles contained within the traversed grid cells. This makes it - when the lattice is not too large - even run in real time on any OpenCL 1.2 capable GPU with enough memory. No RTX or "professional" GPU required.
Also see the most realistic raindrop simulation ever done: youtu.be/9Rfu9ZqW894
Timestamps:
0:00 intro
0:03 simulation start
0:29 almost melts the GPU
1:15 pressure waves from speaker membrane
1:32 isosurface mesh generation
2:15 outro
#FluidX3D #OpenCL #Raytracing #GPU #LBM


![PhysX3D [GRAVITY SIMULATION] 5k body galaxy simulated in real time
PhysX3D got upgrades. I changed the square root implementation to the fast inverse square root algorithm provided by the aparapi Kernel. With this, y=1/sqrt(x) is calculated as fast as a multuplication, resulting in 7.2x overall performance increase compared to the old square root implementation.
GPU acceleration is now about 50x faster than CPU multithreading.
A galaxy containing 5k bodies is simulated on a 1.54Tflops notebook GPU (Nvidia GeForce GTX 960M). The GPU achieves 124 calculation steps per second using Runge Kutta 4th order integration in 3D space. Everything was simulated in real time.
In other words, the GPU calculates roughly 3.5 billion particle interactions every second.
More information at: http://www.projectphysx.de
Music: Puddle of Infinity - Open Sea Morning PhysX3D [GRAVITY SIMULATION] 5k body galaxy simulated in real time](https://i.ytimg.com/vi/j4kejlWBVwA/mqdefault.jpg)
![PhysX3D [GRAVITY SIMULATION] Euler vs. RK4 / Sonnensystem im Jahr 3016
Das Einschrittverfahren Runge-Kutta-4 (RK4) ist um Größenordnungen genauer als das einfachere eulersche Polygonzugverfahren. RK4 erlaubt es, auch bei einer hohen Körperanzahl die Simulationsgeschwindigkeit ohne ohne größere Rechenfehler sehr weit hoch zu schrauben.
Mehr Informationen auf: http://www.projectphysx.de
Musik:
Hans Zimmer - Stay (Interstellar Soundtrack)
Hans Zimmer - Day One(Interstellar Soundtrack) PhysX3D [GRAVITY SIMULATION] Euler vs. RK4 / Sonnensystem im Jahr 3016](https://i.ytimg.com/vi/jr-3WIY9Fmo/mqdefault.jpg)
![SoundFFT [AUDIO SPECTRUM ANALYZER] Music Demo
SoundFFT is a fast and accurate spectrum analyzer for live audio signals. It performs a fast Fourier transform (FFT) on the live input signal coming from the computers main microphone. The highest peak is being detected and its center is being calculated to further increase resolution.
Java can only input an audio signal from an audio source like a microphone. So in order to get the audio stream from the computers main speakers, you have to use some kind of workaround. I found the software Virtual Audio Cable to fulfill exactly this purpose.
This demo shows how SoundFFT works with Music.
Interestingly, the laws of physics prevent a more accurate frequency resolution without the spectrum being both more delayed and averaged. The longer the buffer is for the fast Fourier transform, the more accurate the frequency resolution will be and vice versa.
Nevertheless, it is fascinating to be able to see exactly what you hear. Also keep in mind that the human brain automatically Fourier transforms the incoming sound (what you hear is the pitch and not the wave) without you having to waste a single thought about it.
Free download and more information at http://www.projectphysx.de
Music: DROELOE feat. Belle Doron - In Time SoundFFT [AUDIO SPECTRUM ANALYZER] Music Demo](https://i.ytimg.com/vi/jwZk7DbF3P8/mqdefault.jpg)

![FluidX3D [FLUID SIMULATION] Some Real Time Demonstrations
FluidX3D is a real time 3D fluid simulation based on the lattice Boltzmann method. It is written in OpenCL (GPU code) and optimized to the physical limit (video memory bandwith, ~500GB/s).
FluidX3D has been completely overhauled, all velocity sets (D2Q9, D3Q13, D3Q15, D3Q19, D3Q27) as well as all collision operators (single relaxation time (SRT), two relaxation time (TRT), multi relaxation time (MRT)) have been added and can be freely combined. In my implementation, neither TRT or MRT have any measurable performance impact since the bottleneck is still the memory bandwidth, capped by the hardware to about 420GB/s on the Titan Xp. The swap algorithm is OS-Pull (fastest algorithm, but not as memory efficient) and the data layout is the faster struct-of arrays (SoA). Ive reached the optimization limit with 2.6 Giga lattice updates per second (GLUPs) for D3Q19 on the Titan Xp.
Ive translated my graphics library Line3D into OpenCL with the Bresenham algorithm for drawing lines on a bitmap. It can handle up to 2 billion lines per second, which is way faster than all other graphics libraries for primitive shapes out there.
For more information about FluidX3D and my other projects, visit
http://www.projectphysx.de
Music: CMA - Youre Not Alone FluidX3D [FLUID SIMULATION] Some Real Time Demonstrations](https://i.ytimg.com/vi/kpCAaydlzi4/mqdefault.jpg)
![DroneEngine [QUADCOPTER SIMULATION] June Update: control modes
Es geht voran mit der DroneEngine. Ich habe drei unterschiedliche Steueralgorithmen implementiert, die zukünftig die Grundlage für das simulierte Sensor-Feedback bilden werden. Weitere Updates werden folgen.
Song: Ellie Goulding - Lights [LuQuS Remix] DroneEngine [QUADCOPTER SIMULATION] June Update: control modes](https://i.ytimg.com/vi/kps6_SK4Dw4/mqdefault.jpg)

![PhysX3D [GRAVITY SIMULATION] Planetary Movement through Space
This is how the planets and moons move relative to the solar system barycenter. In a similar way the whole solar system moves around the center of the milky way.
More information at: http://www.projectphysx.de
Music: Chris Zabriskie - Cylinder Three PhysX3D [GRAVITY SIMULATION] Planetary Movement through Space](https://i.ytimg.com/vi/llhXEzWEWxI/mqdefault.jpg)
