From BlenderWiki

[edit] 2.40 Release

[edit] Fluid simulation

You can now simulate liquid fluids such as water, oil, or honey due to the new fluid simulation capabilities added by Nils Thuerey with the sponsorship of Google Summer of Code.

The fluids can collide with static objects, be acted on by forces, and can initialize properties of the fluid such as initial direction, and viscosity; as well as allow fluid to flow in and out of the simulation domain.

• http://www.blender3d.org/cms/Fluids_simulation.675.0.html
• http://mediawiki.blender.org/index.php/Manual/PartX/Fluid_Simulation

[edit] Animateable time steps

• solver now supports animated time steps, gravity and viscosity, an example can be found here: http://www10.informatik.uni-erlangen.de/~sinithue/temp/fluid_timeanim.mpg
• for simulation time animation the time IPO of the object is currently used, for all three there should probably be new ipos in the fluidsim struct

[edit] Misc

• the fluidsim meshes now replace the original one. so modifiers now work with them (apply modifier, or edit mode still work on original mesh).
• changed GUI a bit, now displays an estimate of the required memory
• temporary simulation files are now removed if env. var. BLENDER_DELETEELBEEMFILES is not set or zero
• default output is to '//fluidsimdata/...'
• there's still a problem with redrawing (currently relies on a call to the derived mesh generation)

[edit] 2.42 Release

[edit] fluid simulation

 Log:
 Sorry for the big commit, but I've been fixing many of these
 issues in parallel... So this commit contains: an update of
 the solver (e.g. moving objects), integration of blender IPOs,
 improved rendering (motion blur, smoothed normals) and a first particle
 test. In more detail:
 
 Solver update:
 - Moving objects using a relatively simple model, and not yet fully optimized - ok
   for box falling into water, water in a moving glass might cause trouble. Simulation
   times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot
   might also cause slowdowns.
 - Additional obstacle settings: noslip (as before), free slip (move along wall freely)
   and part slip (mix of both).
 - Obstacle settings also added for domain boundaries now, the six walls of the domain are
   obstacles after all as well
 - Got rid of templates, should make compiling for e.g. macs more convenient,
   for linux there's not much difference. Finally got rid of parser (and some other code
   parts), the simulation now uses the internal API to transfer data.
 - Some unnecessary file were removed, the GUI now needs 3 settings buttons...
   This should still be changed (maybe by adding a new panel for domain objects).
 
 IPOs:
 - Animated params: viscosity, time and gravity for domains. In contrast
   to normal time IPO for Blender objects, the fluidsim one scales the time
   step size - so a constant 1 has no effect, values towards 0 slow it down,
   larger ones speed the simulation up (-> longer time steps, more compuations).
   The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect).
 - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow
   objects can use the velocity channels to animate the inflow. Obstacles, in/outflow
   objects can be switched on (Active IPO>0) and off (<0) during the simulation.
 - Movement, rotation and scaling of those 3 types is exported from the normal
   Blender channels (Loc,dLoc,etc.).
 
 Particles:
 - This is still experimental, so it might be deactivated for a
   release... It should at some point be used to model smaller splashes,
   depending on the the realworld size and the particle generation
   settings particles are generated during simulation (stored in _particles_X.gz
   files).
 - These are loaded by enabling the particle field for an arbitrary object,
   which should be given a halo material. For each frame, similar to the mesh
   loading, the particle system them loads the simulated particle positions.
 - For rendering, I "abused" the part->rt field - I couldnt find any use
   for it in the code and it seems to work fine. The fluidsim particles
   store their size there.
 
 Rendering:
 - The fluidims particles use scaled sizes and alpha values to give a more varied
   appearance. In convertblender.c fluidsim particle systems use the p->rt field
   to scale up the size and down the alpha of "smaller particles". Setting the
   influence fields in the fluidims settings to 0 gives equally sized particles
   with same alpha everywhere. Higher values cause larger differences.
 - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals
   computed by the solver are used. This is basically done by switching off the
   normal recalculation in convertblender.c (the function calc_fluidsimnormals
   handles other mesh inits instead of calc_vertexnormals).
   This could also be used to e.g. modify mesh normals in a modifier...
 - Another change is that fluidsim meshes load the velocities computed
   during the simulation for image based motion blur. This is inited in
   load_fluidsimspeedvectors for the vector pass (they're loaded during the
   normal load in DerivedMesh readBobjgz). Generation and loading can be switched
   off in the settings. Vector pass currently loads the fluidism meshes 3 times,
   so this should still be optimized.
 
 Examples:
 - smoothed normals versus normals from subdividing once:
   http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png
   http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png
 - fluidsim particles, size/alpha influence 0:
   http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png
   size influence 1:
   http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png
   size & alpha influence 1:
   http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png
 - the standard drop with motion blur and particles:
   http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg
   (here's how it looks without
   http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg)
 - another inflow animation (moving, switched on/off) with a moving obstacle
   (and strong mblur :)
   http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg
 
 Things still to fix:
 - rotating & scaling domains causes wrong speed vectors
 - get rid of SDL code for threading, use pthreads as well?
 - update wiki documentation
 - cool effects for rendering would be photon maps for caustics,
   and motion blur for particles :)

[edit] fluids

 - New options for mesh voxelization: shell only (also
   works for non closed objects), volume ("normal"/old way of
   doing it), and a combination of both:
   http://www10.informatik.uni-erlangen.de/~sinithue/blender/voltcomp_sm.jpg
 - Finally included bjornmose MSVC6 fixes
 - Added support for animated meshes, e.g. meshes with
   parented skeletons. Is enabled for obstacles with a new button.
   A simple example with Bassam's mancandy can be found here:
   http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.mpg
   http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.blend
   (Warning - keep meshes as simple as possible, e.g. turn off subsurf
   for baking. Export probably shoulb be further optimized.)
 - Changed handling of no/free/part slip obstacles, see:
   http://www10.informatik.uni-erlangen.de/~sinithue/blender/bndtcomp_sm.jpg
 - Removed surface particle option for upcoming release,
   needs more testing & tweaking
 - Added tracer particles instead (swimming along in the fluid)
 - Updated wiki (description of IPOs still missing).

[edit] 2.43 Release

[edit] FluidSim Changes

Surface Subdivision

The most important update of the fluid simulation is the "Surface Subdiv" option, that allows the creation of high resolution surface meshes directly during the simulation (similar to the subdivision mesh modifier that would do it afterwards). It can be found on the third page of the domain settings. A value of 1 means no subdivision, each increase results in one further subdivision of each fluid voxel. The resulting meshes thus quickly become large, and can require large amounts of disk space. Be careful in combination with large smoothing values - this can lead to long computation times due to the surface mesh generation.

Particles

Another updated part is the particle generation. In combination with the subdivision option, the particles can now be directly included in the surface mesh to give the impression of small drops.

An example of the effect of particles can be seen here - the image to the left was simulated without, the right one with particles and subdivision enabled.

Examples

An example of this can be found here. The first movie is the solver without particles and subdivision, the second one uses it: http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid6_fl6manc4_1noparts.mpg http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid6_fl6manc4_2wparts.mpg
While both movies were created with the same simulation resolution, the second one takes almost twice as long to compute, but contains significantly more visual details.

The corresponding example setup can be found here: http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid6_testmanc4.blend

This file also uses the new particle loading options. There is a suzanne mesh in one of the switched off layers, that can be used to load particles generated during the simulation. For these different types can be selected: drops (as used for the subdivision), floats (float on the fluid surface, could be used for e.g. foam), and tracer particles. The latter ones are known from the last version, and just swim along in the fluid (enabled with the "tracer particle" option).

[edit] 2.46 Release

Nils added OpenMP/multithreading support for fluids! See rev 12645! --Genscher 15:04, 12 February 2008 (CET)

Commit log of Nils:

- Added OpenMP code, it is enabled by defining PARALLEL=1 for the elbeem

 compilation.  Currently, it is not yet active by default, but 
 Genscher wanted to do some tests. 
 It can be used to distribute the computation load onto multiple shared-
 memory CPUs by splitting the domain along the y-axis (assuming a 
 gravity force along z). However, there is no load balancing: so
 if there's fluid only in one of the y-axis halves you will not get 
 a speedup for 2 CPUs.  

- Added a fix for the memory allocation bugs #7120 and #6775. In

 solver_init.cpp there are now several variables max___MemChunk 
 (line 692+), that set upper limits for various systems. The same
 problem existed for mac & linux, but the limit is higher, so 
 it probably went by undetected. The windows limit is currently 1GB,
 if the strange 700MB limit problems mentioned in the bug regports the 
 bugs persist, this could be further reduced. For 64bit compilations 
 this problem shouldn't exist anyway.
 What's still missing is a display of how much the resolution was 
 reduced to fit into memory...

- And some minor solver code cleanup.

[edit] 2.48 Release

[edit] Fluid Control

"Magic Fluid Control"

From the authors page:

The water is simulated using the Lattice-boltzman method. It is controlled using particles which define local force fields and are generated automatically from either a physical simulation or a sequence of target shapes. At the same time, as much as possible of the natural fluid motion is preserved.

This feature was also shown at Siggraph 2007 and is now integrated into Blender.

Fluid control options

Time

You specify the start and end time during which time the fluid control object is active

Attraction force

The attraction force specifies the force which gets emmited by the fluid control object. Positive force results in attraction of the fluid, negative force in avoidance.

Velocity force

If the fluid control object moves, the resulting velocity can also introduce a force to the fluid.

Quality

Higher quality result in more control particles for the fluid control object

Reverse

The control particle movement gets reversed