Amazingly fast, open source, accurate fluid solver. Blender compatible.

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.

  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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:

  1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software.
  1. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.
  1. This notice may not be removed or altered from any source distribution.
  1. 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:

  1. 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.

Hope is only thing that we can rely on right now T_T

Haha, indeed! This solver is legitimate. Time to start a donation fund & get a paid dev to put this puppy into blender. I can see the “donate” button on the front page of blender.com now… :yes: It can be a band-aid on our fresh wound from losing Brecht. :wink:

… hm
during the GSOC14- (Google Summer of Code) 2014 there is a student already working on implementing this one
into Blender.

http://mantaflow.com/index.html

Hey that’s cool… Didn’t see that. I don’t think it’s as optimized or nearly as fast as Fluids, but awesome nonetheless. It also out of the box seems to be more diverse in OS support. I’d still choose Fluids if it came down to choice, seems like too good of a thing to pass up. Kind of like how OpenSubdiv was.

since Fluids v3 does not have a mesher function,it wouldn´t be useful for Blender users.
never the less it is interesting to look at it.

Mantaflow has a mesher function aka a function which translates the simulated data to a mesh.

the blender code site has more informations about the accepted GSOC projects :wink:

since Fluids v3 does not have a mesher function,it wouldn´t be useful for Blender users.
never the less it is interesting to look at it.

:rolleyes:

Hence why I mentioned the below in my original post.

“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.”

I also included in the original post that it doesn’t yet render surfaces as a mesh.

The following wishlist represents desirable features for Fluid v.3, which I just don’t have time to work on.

  1. 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.

This isn’t an attack on your personal preference for for Mantaflow. Like I said, as far as speed and accuracy (I think accuracy) goes, Fluids trumps Mantaflow… It’s nothing personal, nor is my personal preference against Mantflow when compared to Fluids. I see no problem drooling over an awesome piece of code like Fluids, and having a thread about it. Cheeeeeeeelll out.

A little more work to get the thing a mesh function and it’d trump everything else, I’d (I speak for myself, not everyone else using Blender) be willing to wait a little longer to have an awesome simulator like Fluids if it took a little more work to get a mesh function working.

Anyways, I’d be willing to start another thread on Mantaflow and it’s positives, if it will keep things here on topic. It’s a suggestion and an admiration, not a demand. Not in any way meant to disrespect the guy putting in lots of hard work to implement Mantaflow, or yourself. No need to hijack the thread, bro! In the end we’re getting stuff for free so I’m thankful regardless.

There are plans to incorporate OpenVDB into Blender. With OpenVDB, there will also be a Mesher.

Manta uses completely different methods and has completely different use-cases. For serious simulation work, we need both!

@GottfriedHofmann

you are right, the more the merrier.
Do you know the status of OpenVDB at the current time?

btw there seems to be another great water simulator which also already works with Blender
http://www.dual.sphysics.org/index.php/animations/

Did you guys notice this from the last developer’s meeting notes? :slight_smile:

[LIST=|INDENT=1]

  • Roman Pogribnyi solved the fluid linking issues. Work on getting Mantaflow to work now can finally proceed.
    [/LIST]

great stuff… wish we could have it right now :smiley:

Get the boards! Surf’s Up!

that is of course great news :slight_smile:

there is even a two month old video (long before the good news )
of an initial mantaflow scene in Blender available.

I’m a bit confused. What does Mantaflow offer that the existing solvers don’t?

  • Better control over smoke and fluid sims
  • Multiple domains
  • Better solver base
  • Improved turbulence simulation

Looks like there was a GSoC project to do this in 2013 (easy to find on Google); from what I can piece together, it was supplied as a plug-in but it was decided by Brecht and Ton that the better way to do it would be to integrate it all into Blender’s code fully, including building OpenVDB as part of the dependency installation process while building. That’s what hasn’t happened yet.

Looks very powerful at any rate and now that Cycles volumetrics is a thing, looks really useful. And quite right, both Mantaflow and this are needed!

surely from the fluid sim (liquids) side some improvement would be nice… the fluid sim is quite outdated and the particles are useless without a remesher. Regarding the smoke sim, as there will be something new and better it is of course a really good thing, but the sim we have now is quite good already.

This year, I have done a SPH project as studient : https://github.com/tychotatitscheff/duc-sph
As far as I know, we have used the same papers as them so http://image.diku.dk/projects/media/kelager.06.pdf and http://www8.cs.umu.se/education/examina/Rapporter/MarcusVesterlund.pdf . Basicly, the colision handling is only box and sphere and capsule and the viscosity force is not perfect. Best model has been found since.
But it show how to optimise sph simulation using opencl.

multiple domains in the fluid simulation

It’s not bad but far from the detail you can get with Fume FX for example:

http://previewcf.turbosquid.com/Preview/2014/07/08__00_16_06/heavysmoke_f_md.jpgf968f730-04ea-4c4a-bdf8-92fe6e3e6047Large.jpg

You can only get big blobs of smoke but not fine detail as this.