Welcome

Fluids v.3 is a large-scale, open source fluid simulator for the CPU and GPU using the smooth particle hydrodynamics method. Fluids is capable of efficiently simulating up to 8 million particles on the GPU (on 1500 MB of ram).

This demo video shows 4 million particles simulated at 1/2 fps. At this rate, 3000 frames are simulated in just 1.5 hours. Published in December 2012, this is the fastest, freely available GPU simulator (for now anyway). See the Performance page for details.

Fluids v.3 (2012) is based on Fluids v.2 (2009), while extending it in several ways.

Features:
– Supports up to 8,000,000 particles (Fluids v.2 limited to 65536)
– Very fast GPU solution, with peak efficiency of 6,000,000 simulated particles per second.
– All calculations on the GPU (unlike Fluids v.2, which did CPU-only integration steps)
– Minimal use of PCI bus transfer
– Novel search algorithm
– Generic search allows 2x2x2, 3x3x3 and 4x4x4 neighborhood search for optimal performance
– Better memory management, with structure-of-arrays layout.
– Simplified code compared to Fluids v.2
– Simulation times reported interactively, and separated for each computation step.
– Capture video to disk (press tilde ` key)

Fluids v.3, like its predecessor version two, is intended for the scientific community to have access to a very efficient, large scale fluid simulator for diverse applications. As such, it is released as free, open source software, usable in commercial or non-commercial software. See license details here.

Please read the FAQ for details on licensing, current limitations, and future goals.

Check out these more recent projects as well:
NVIDIA(R) GVDB Voxels – Integrates Fluids v.3 as a sample
http://ramakarl.com – Website with current projects
Thanks!, Rama Karl Hoetzlein

19 Responses to "Welcome"

David Nash says:

March 27, 2013 at 10:24 pm

Looking at the todo list I have to admit, I think the particles look great and the marching cubes could ruin the fine detail of the particles in the large scale system. In the later stages of the video, the blue and white particles look right, the red particles could possibly be coloured dark blue by a shader.

A method that I think deserves some research is a screen space burring effect, with perhaps reactive blurring on a per particle basis, so perhaps for the particle velocity you could have a seperate VB, and the w component could store a bit mask, then the velocity field could be used to blur the particles slightly. I find with a dense packed particles system with large enough numbers, a blur effect can cause slight detail loss (but not as much as marching cubes) and would make the blue particles look like one solid mass. Also, the foam particles could be made larger, or even rendered with a point and a second slightly larger point with transparency.

I did an experiment last week using NVidia’s cuda demo named “Particles”. I found it was quite simple to render the particles to a grid texture using a cuda kernal based on the CollideD function – it is a scattered write however they are written to texture so the Tex chip should batch / queue the write calls between threads. I did not implement a method for counting the particles in each grid cell, perhaps this could be a serial algorithm for the Tex unit someday. Anyway I displayed the results of the render using CG and found that the volume texture looked pretty bad, the solo particles falling from above had very quantized looking positions, and overall I had a big hit to framerates. This is why I didn’t even bother to run the marching cubes texture with a transparency shader (or Optix).

So overall I think the particles movements look smoother and the detail is better without the marching cubes effect mentioned. The technique for marching cubes might be good for smaller fluid bodies however.

Reply
John Cassella says:

May 16, 2013 at 10:49 pm

Hi, any update as to when/if a linux build environment will be available?

very excited to learn from this project!

-johnc
redpawfx

Reply
1. admin says:
  
  June 4, 2013 at 6:35 pm
  
  Unfortunately, I’m too busy with other stuff to build a linux version right now. You’re welcome to try this yourself, and I could give some pointers. You might also try to generate interest in getting help from others to port to linux – possibly through the github forum.
  
  Reply
  1. Serge Martin says:
    
    December 4, 2013 at 3:29 pm
    
    Hello
    
    I did a simple port to linux here : https://github.com/sergemartin/fluids_v3
    
    Reply
    1. Ryan says:
      
      July 16, 2014 at 4:08 am
      
      Can you give a quick run-down on how to build it? If I can get this v3 working, I’d be willing to repeat the process for v3.1. I’ve gotten as far as running cmake CMakeLists.txt but the subsequent make fails with “fatal error: Cg/cgGL.h: No such file or directory”. I’m not sure if I’m missing the dependency or doing something completely wrong.
      
      Thanks.
      
      Reply
      1. Rama Hoetzlein says:
        
        July 16, 2014 at 4:21 am
        
        Serge’s port is of v3.0. I would suggest a linux port based on 3.1, which no longer requires Cg, Jpg, or Freeglut. Only dependency now in 3.1 is cuda toolkit. So a combination of Serge’s linux code, and version 3.1, would be ideal. I just don’t have much time at the moment.
Reinier says:

October 2, 2013 at 12:08 am

Are there any pointers / tips you could give porting this to a functional Bullet library? I’m starting a master project regarding SPH and now I’m starting to work with BulletFLUIDS, based on V2. I’d love a more GPU oriented Bullet library but I assume there won’t be one soon (or ever?). Looking at the BulletFLUIDS based on V2, it’s not an easy task probably?

Thanks!
Reinier.

Reply
1. admin says:
  
  October 4, 2013 at 5:42 am
  
  Although Fluids v.2 was first a plugin to BulletPhysics (not integrated) , I wasn’t aware of BulletFluids. BulletPhysics itself is already very GPU oriented for rigid-body simulation, but I assume you’re looking for a SPH library with it. Unfortunately, so far Fluids v.3 is not yet integrated into any rigid-body simulator. It may be possible to adopt into BulletFluids, but you’re right its not easy. I do know others are working on Fluids v.3 integration with rigid bodies, so if/when there are any new developments I will post them here.. If you’re thinking to attempt a port yourself, I would suggest starting with BulletFluids and consider integrating v.3 with it, since it is not so different from v.2 and thus might be easier that way.
  
  Reply
2. Erwin Coumans says:
  
  November 14, 2013 at 8:31 pm
  
  Bullet 3 is running 100% of the rigid body pipeline and collision detection on the GPU using OpenCL. How much more “GPU oriented” can it be? See http://github.com/erwincoumans/bullet3 It would be great to have Fluids v2 integrated with Bullet 3, then add cloth and two-way interaction and you get something similar to NVIDIA Flex. All open source.
  
  Reply
  1. Erwin Coumans says:
    
    November 14, 2013 at 8:33 pm
    
    That was a typo (no edit?) -> Fluids v3 integrated with Bullet 3
    
    Reply
Erwin Coumans says:

November 26, 2013 at 1:52 am

The software seems to broken using the current CUDA version:

Cuda error in file ‘fluids/fluid_system_host.cu’ in line 184 : invalid device symbol.

Reply
1. admin says:
  
  December 6, 2013 at 7:05 am
  
  Yes, this is due to a change in CUDA whereby cudaMemcpyToSymbol function has changed. In Fluids v.3 search for the line that does:
  cudaMemcpyToSymbol ( “simParams”, .. )
  And modify it so that sim params is the name itself, not in quotes. This is a known change in CUDA 5.5:
  http://stackoverflow.com/questions/12947914/error-in-cudamemcpytosymbol-using-cuda-5
  
  Reply
admin says:

December 6, 2013 at 6:57 am

Linux port available thanks to Serge Martin:
https://github.com/sergemartin/fluids_v3

Reply
Nolan Dyck says:

January 13, 2014 at 9:10 pm

Wow. This is a really cool project. Congratulations on your achievements and thanks for making the code available.
I have couple of questions:

Why did you choose CUDA over OpenCL?
Did you consider other fluid discretization methods such as the Finite Volume Method (FVM) and Discrete Vortex Method (DVM)? What pulled you towards SPH?

Reply
1. admin says:
  
  January 14, 2014 at 6:50 pm
  
  CUDA was used for historic reasons as I learned it first. Others have suggested a port to OpenCL, but I just don’t have time now to do it.
  
  At the time I started Fluids v.1, in 2007, SPH was the most promising real-time fluids technique. It is efficient, has minimal memory requirements, and conserves mass without a pressure solver. While FVM and DVM are also approaching real-time, I found them to be more complex to code, and difficult to create large-scale, real-time systems. SPH can be rendered with point splatting, where as grid methods require a marching cubes approach to render the surface. Any current game which has real-time 3D free surface fluids – of which there are still very few – use SPH.
  
  Reply
Tsing says:

July 1, 2014 at 5:24 am

Hi,

I found your performance is pretty awesome. I am trying to implement an SPH system of my own. I am using brute force neighbor searching method which is O(n^2). And I’m wondering whether to use KD-Tree or grid in neighbor finding. What did you do in your code of neighbor searching and is there any suggestion to increase the performance?

Thank you.

Reply
1. Rama Hoetzlein says:
  
  July 3, 2014 at 5:08 am
  
  A KD-Tree is inefficient because the overhead of node traversal on GPU is slower than spatial grid methods. Of course, there are many empty cells in the uniform grid, but the memory cost of the grid cells (200k) is small compared to the total number of particles (8 million+). With the new techniques here, uniform grids are the fastest method on GPU. You can find more details on the 1-radix Counting Sort method use in fluids v.3, from the on-demand GTC presentation here: http://on-demand.gputechconf.com/gtc/2014/presentations/S4117-fast-fixed-radius-nearest-neighbor-gpu.pdf
  
  Reply
Jan Zelezny says:

July 16, 2014 at 9:54 pm

I tried a demo simulation in Win 7 and it’s beautiful.
Only occasionally particles flies out from wave and it takes a while than to find their way back.
I have a question I’d like to alert people what makes Blender 3D for this project.
But I am sure one thing. When running a simulation on the GPU can check every single frame the location of all particles (for example 1 Million) and write in to file. And if so how much will affect the speed of calculation.

Reply
1. Rama Hoetzlein says:
  
  July 19, 2014 at 12:29 am
  
  If you write to disk, that will be slowest part. Consider 1 million points * 12 bytes/vertex = 12MB/frame * 30 fps = 360 MB/sec. That bandwidth is more than most SSD drives (250 MB/sec). That is only 1 million points. If you do 8 million, its 2880 MB/sec. With compression, it could be better, but you don’t want to lose too much detail.. Basically, as GPU performance improves, the idea of a particle disk cache will go away completely – it will soon be faster to re-simulate than to cache.
  
  Reply

Leave a Reply to admin Cancel reply