FluidX3D Rendering Comparison (Raindrop Impact) @ProjectPhysX

Uploaded January 2022 | Updated September 2026, 1 week ago

How do visual quality and combined compute+render time compare for different variants of raytracing?
Compute time alone of this simulation is 16 minutes. Rasterization adds another 5 minutes, flat triangle raytracing 8 minutes. With normal vector interpolation it's 10 minutes. A second raytracing pass vastly elongates render time to 31 minutes.
Resolution is 1080p, and 599 frames are rendered.

1 raytracing pass means the camera ray enters the fluid and gets split in reflection and internal ray; the internal ray exits the fluid again and becomes the refraction ray. Per pixel, a total of 4 rays are computed (camera ray, reflection ray, internal ray, refraction ray).

The 2nd pass means that both reflection and refraction ray again can intersect fluid and become reflected and refracted. With 2 raytracing passes, the entire simulation box is reflected on / refracted through every single dropelt. Per pixel, a total of 10 rays are computed (camera ray, 3x reflection ray, 3x internal ray, 3x refraction ray).

Entire simulation in 4K: youtu.be/UUYrWUpPQwY
From Boxes to photorealistic Fluid: youtu.be/u83qaxuT6eA

See my published research paper in Microplastics and Nanoplastics:
microplastics.springeropen.com/articles/10.1186/s43591-021-00018-8

The large simulation domain is made possible by FP32/FP16 mixed precision with novel 16-bit number formats:
arxiv.org/pdf/2112.08926.pdf

This is a Volume-of-Fluid lattice Boltzmann method (LBM) simulation of a 7 mm diameter terminal velocity (9.55 m/s) raindrop impact (D3Q19 SRT) at 20° inclination. Velocity, density and fluid mass are solved at 108 Million lattice points (504x504x428) for 13752 time steps, equivalent to 10 milliseconds in real time. The simulation required 12 GB video memory.
For reproducibility: The dimensionless numbers for this setup are Re = 63618, We = 8864, Fr = 36.44, Ca = 0.1393, Bo = 6.674.

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 (8799/5232 MLUPs/s on the Nvidia A100/V100 @ D3Q19 SRT FP32), on gaming GPUs and CPUs and it even runs my smartphone.

The rendering is done by FluidX3D as well. Simulated light rays from the camera traverse the LBM lattice and check for intersections with the triangles that marching-cubes generates on-the-fly from the isovalues. Triangles never leave registers.
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 iso-surface triangles contained within the traversed grid cells. This makes it - when the lattice is not too large - even run in real time on non-RTX GPUs.

I am the lead developer of FluidX3D. The implementation is detailed in my Master's thesis, which is freely available on ResearchGate:
researchgate.net/publication/349552856_High_Performance_Free_Surface_LBM_on_GPUs

The Volume-of-Fluid extension is detailed in this research paper:
mdpi.com/2079-3197/10/2/21

Timestamps:
00:00 Intro
00:02 Video Comparison
00:12 Freeze Frame
00:17 Outro

#FluidX3D #OpenCL #Raytracing #GPU #LBM

Music: admo - On The Nightway

$FluidX3D Rendering Comparison (Raindrop Impact) How do visual quality and combined compute+render time compare for different variants of raytracing? Compute time alone of this simulation is 16 minutes. Rasterization adds another 5 minutes, flat triangle raytracing 8 minutes. With normal vector interpolation its 10 minutes. A second raytracing pass vastly elongates render time to 31 minutes. Resolution is 1080p, and 599 frames are rendered. 1 raytracing pass means the camera ray enters the fluid and gets split in reflection and internal ray; the internal ray exits the fluid again and becomes the refraction ray. Per pixel, a total of 4 rays are computed (camera ray, reflection ray, internal ray, refraction ray). The 2nd pass means that both reflection and refraction ray again can intersect fluid and become reflected and refracted. With 2 raytracing passes, the entire simulation box is reflected on / refracted through every single dropelt. Per pixel, a total of 10 rays are computed (camera ray, 3x reflection ray, 3x internal ray, 3x refraction ray). Entire simulation in 4K: https://youtu.be/UUYrWUpPQwY From Boxes to photorealistic Fluid: https://youtu.be/u83qaxuT6eA See my published research paper in Microplastics and Nanoplastics: https://microplastics.springeropen.com/articles/10.1186/s43591-021-00018-8 The large simulation domain is made possible by FP32/FP16 mixed precision with novel 16-bit number formats: https://arxiv.org/pdf/2112.08926.pdf This is a Volume-of-Fluid lattice Boltzmann method (LBM) simulation of a 7 mm diameter terminal velocity (9.55 m/s) raindrop impact (D3Q19 SRT) at 20° inclination. Velocity, density and fluid mass are solved at 108 Million lattice points (504x504x428) for 13752 time steps, equivalent to 10 milliseconds in real time. The simulation required 12 GB video memory. For reproducibility: The dimensionless numbers for this setup are Re = 63618, We = 8864, Fr = 36.44, Ca = 0.1393, Bo = 6.674. 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 (8799/5232 MLUPs/s on the Nvidia A100/V100 @ D3Q19 SRT FP32), on gaming GPUs and CPUs and it even runs my smartphone. The rendering is done by FluidX3D as well. Simulated light rays from the camera traverse the LBM lattice and check for intersections with the triangles that marching-cubes generates on-the-fly from the isovalues. Triangles never leave registers. 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 iso-surface triangles contained within the traversed grid cells. This makes it - when the lattice is not too large - even run in real time on non-RTX GPUs. I am the lead developer of FluidX3D. The implementation is detailed in my Masters thesis, which is freely available on ResearchGate: https://www.researchgate.net/publication/349552856_High_Performance_Free_Surface_LBM_on_GPUs The Volume-of-Fluid extension is detailed in this research paper: https://www.mdpi.com/2079-3197/10/2/21 Timestamps: 00:00 Intro 00:02 Video Comparison 00:12 Freeze Frame 00:17 Outro #FluidX3D #OpenCL #Raytracing #GPU #LBM Music: admo - On The Nightway$

Simulating an oblique drop impact on a shallow liquid pool with FluidX3D

$I wrote this Real Time RayTracer from Scratch in 1 Week. Hybrid Rasterization + Raytracing Demo I wrote this real time OpenCL raytracer in one week from scratch and without any external libraries. Timestamps 0:00 Intro 0:02 1 Sphere 0:29 64 Spheres 1:34 Triangles - reflection 2:23 Triangles - reflection+refraction 4:10 How it works 4:39 Outro This project was first inspired by this awesome video from the YouTuber NamePointer: https://youtu.be/lKIytgt3KXM It is surprisingly easy: From the camera, shoot a ray through every pixel. Reflect the ray off the first surfaces in its way, reflect the reflection 2 more times. Finaly when the reflected ray hits the skybox, mix all the colors to paint the original pixel with. The GPU does this for all 2 Million pixels on the screen in parallel. I implemented: - ray-sphere intersection - ray-triangle intersection (Möller-Trumbore algorithm) - reflection as well as refraction with Snells law - hybrid rasterize-raytrace approach: First rasterize triangles and instead of the pixel color save their IDs in the bitmap. Then the raytrace kernel looks up the ID to immediately get the first intersecting triangle. This way the first intersection and reflection are basically free, so the shiny Stanford bunny with 70k triangles runs at 200+fps. Because I wrote the raytracer in OpenCL, it runs on any OpenCL capable device (GPUs, CPUs, even my Samsung phone). No proprietary RTX hardware required. Music: Unfound - Promenade$

FluidX3D on GigaIO SuperNODE - Concorde 40 Billion Cell CFD Simulation - 33h on 32x MI210 64GB GPUs

PhysX3D [GRAVITY SIMULATION] Sonnensystem

Raytracing 871000 Triangles in Real Time... on Intel Integrated Graphics

$Liquid metal on a speaker (Slow Mo Guys), but as simulation The Slow Mo Guys did a video about liquid gallium on a vibrating speaker membrane, wondering what it would look like in simulation: https://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 couldnt do the simulation with 1:1 the physical parameters of liquid gallium, as it just wouldnt 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: http://paulbourke.net/geometry/polygonise/ Raindrop simulations: https://doi.org/10.1186/s43591-021-00018-8 Volume-of-Fluid: https://doi.org/10.3390/computation10020021 Esoteric-Pull: https://doi.org/10.3390/computation10060092 FP32/FP16 mixed precision: https://www.researchgate.net/publication/362275548_Accuracy_and_performance_of_the_lattice_Boltzmann_method_with_64-bit_32-bit_and_customized_16-bit_number_formats FluidX3D: https://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 dont 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: https://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$

Real Time Ray Tracing... in the Command Prompt in 16 Colors

Real Time Ray Tracing... in the Command Prompt in 616 dithered Colors