http://www.rchoetzlein.com/fluids3/
"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)."
Click here for performance info: http://www.rchoetzlein.com/fluids3/?page_id=17
Download the source code here: http://www.rchoetzlein.com/fluids3/?page_id=13
Click here for development info: http://www.rchoetzlein.com/fluids3/?page_id=32
This guy is working (err, was working) on implementing interactivity with Bullet Physics.
With a little work, it seems like this could be a very possible and great addition to Blender, definitely would up the perceived value of Blender to outside users.
What do you guys think? As far as his wish list goes, blender has some fluid surface rendering code that can contribute to his wish list (I think?), giving us an advanced, fast GPU based fluid solver. This thing is pretty cool.
"The following wishlist represents desirable features for Fluid v.3, which I just don’t have time to work on.
- Fluid Surface rendering (difficulty: advanced) – Fluids v.3 does not yet render the surfaces as a mesh. The ideal method would be based on this paper:Efficient High-Quality Volume Rendering of SPH Data, Fraedrich et al., Oct 2010. Using this method, the SPH particles would be rapidly rasterized into a 3D volume texture by using the geometry shader to expand each particle into a set of small triangular slices. The final 3D volume is then polygonized into a mesh using a CUDA-based Marching Cubes. By performing all steps on the GPU, this could be done interactively.
- Efficient Shared Memory SPH (difficulty: medium) – Ideally, proper use of GPU shared memory should enable a 20-40x performance gain, but requires a different approach.
A shared memory solution based on this paper, Interactive SPH Simulation and Rendering on the GPU, has already been implemented into Fluids v.3. See the function computePressureGroup (in file fluid_system_kern.cu). This method has been tested and produces correct results in Fluids v.3, use the F or G key to change simulation algorithm, but it produces results 4x slower instead. The challenge is to determine why, on a hardware level, the shared memory solution is not performing as expected.
- Incompressible PCISPH (difficulty: advanced) – A recent theoretical advance in smooth particle hydrodynamics, called PCISPH, allows for more accurate incompressible fluids. This should also increase efficiency by another 5-10x performance gain. The method is based on the paperPredictive-Corrective Incompressible SPH, by Solenthaler and Pajarola.
- Rigid Body Interaction (difficulty: advance) – Fluids v.3 does not yet support interaction with rigid bodies. My intention was to integrate this with Bullet physics, but i never got around to it. The approach requires either particle-triangle boundary tests, or transforming each rigid mesh object into a set of particles which are then inserted into the simulation.
- Secondary Particles (difficulty: easy) – One of the main goals of Fluids v.3 is to bridge the gap between game physics and motion picture production. For realistic images, motion pictures use secondary spray particles which are emitted from the primary particles. This should be relatively easy to add to Fluids v.3 by emitting secondary particles when the velocity is high and the density is low in the primary particles. The secondary particles would be advanced using a simple GPU-based integrator, and due to their short lifetime they do not need to interact with one another like the primary particles.
- Hardware Analysis (difficulty: easy) – Performance tests on Fluids v.3. were done on an NVIDIA GeForce GTX 460M which is rated at 518 Gflops with 192 cores. The most recent card is the GeForce GTX 680, which is rated at 3090 Gflops with 1536 cores. This means that simulations shown here with 4 million particles at 1/2 fps should be able to run 6-8x faster, or at 3 to 5 fps. Does this actually happen? How does the neighborhood search scale with GPU hardware? The goal is to determine the actual performance response due to changes in hardware for the neighborhood search algorithm used in Fluids v.3.
Development Overview:
Fluids v.3 represents a 6x to 10x performance gain over Fluids v.2, using identical hardware. By implementing PCISPH (3-5x gain), proper CUDA shared memory usage (20-30x gain), and switching to GTX 680 hardware with 1536 cores (6-8x gain), it should be possible to get a total net gain in performance between 20x-30x in addition to the current performance of Fluids v.3.
By adding interactive Fluid Surface rendering, Secondary Particles, and Deferred shading, the visual quality should be comparable to motion pictures. That is, with current hardware, it should be completely conceivable to interact with 2 million particle simulations at a high visual quality. The vision of Fluids v.3 is to move from sandbox faucet simulations into an era of large scale, real world, interactive fluid simulations.
In 2013, I will start a new job, and will be unable to continue work on Fluids v.3. I am therefore pleased to make this software open to the community to expand and improve it. See the page on Licensing for details."
Fully blender compatible, it seems…
FLUIDS v.3 – SPH Fluid Simulator for CPU and GPU
Copyright (C) 2012-2013. Rama Hoetzlein, http://fluids3.comAttribute-ZLib license
(* See additional part 4)
This software is provided ‘as-is’, without any express or implied
warranty. In no event will the authors be held liable for any damages arising from the use of this software.
Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:
- The origin of this software must not be misrepresented; you must not claim that you wrote the original software.
- Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.
- This notice may not be removed or altered from any source distribution.
- Any published work based on this code must include public acknowledgement of the origin. This includes the following when applicable:
- Journal/Paper publications. Credited by reference to work in text & citation.
- Public presentations. Credited in at least one slide.
- Distributed Games/Apps. Credited as single line in game or app credit page.
Retaining this additional license term is required in derivative works.
You may use the following for citations:
In publications:
- 2014, Hoetzlein, Rama C. Fast Fixed-Radius Nearest Neighbors: Interactive Million-Particle Fluids. GPU Technology Conference, 2014. San Jose, CA. 2010-2014. Online at http://fluids3.com
In app or game credits:
GPU Accelerations: Rama C. Hoetzlein (Fluids v3 2013)
Notes on Clause 4:
The intent of this clause is public attribution for this contribution, not code use restriction. Both commerical and open source projects may redistribute and reuse without code release.
However, clause #1 of ZLib indicates that “you must not claim that you wrote the original software”. Clause #4 makes this more specific by requiring public acknowledgement to be extended to derivative licenses.