Scripts Plugins Dokumentation Tutorials Links
  Blender Blender-Dokumentation Fluidsimulation  
 
  Index

Fluid Simulation

Die Seite der deutschen Blenderdokumentation - Mediawiki

Inhaltsverzeichnis   next » 

bezieht sich auf Blender 2.41

Fluid Simulation

 

Description

While modeling a scene with blender certain objects can be marked to participate in the fluid simulation, e.g. as fluid or as an obstacle. The bounding box of another object will be used to define a box-shaped region to simulate the fluid in (the so called simulation domain). The global simulation parameters such as viscosity and gravity can be set for this domain object.

Using the "bake" button, the geometry & settings are exported to the simulator and the fluid simulation is performed, generating a surface mesh together with a preview for each animation frame, and saving them to hard disk. Then the appropriate fluid surface for the current frame is loaded from disk and displayed or rendered.


Animations-Beispiel eines Dammbruches.

Process

In general, you follow these steps:

  1. Model the scene (objects, materials, lights, camera)
  2. Designate the portion of the scene where the fluid will flow (the domain)
  3. Specify the functions of the various objects as they relate to the fluid (an inlet, or outlet, or obstruction, etc.)
  4. Create the fluid source(s), and specify its material, viscosity, and initial velocity.
  5. Bake in a preliminary simulation
  6. Revise as necessary, saving changes
  7. Bake in a final simulation

Die zwei Bilder über und unter diesem Absatz sind ein Beispiel von Fluid Simulationen, das mit dem El'Beem Simulator in Blender erzeugt wurden (und mit YafRay gerendert wurden).


Ein anderes Animations-Beispiel von einem fallenden Tropfen.


 

Options:


Die Basis (und häufig verwendete) Selten benötigte anspruchsvollere
Fluid Simulations Optionen Optionen

Domain/Fluid/Obstacle/Inflow/Outflow

Selecting one of these buttons determines how the enabled object will be used during the simulation. Each button determines a different functionality/interaction, and each has different further options that will become available.

Mesh rendering: If the mesh has modifiers, the rendering settings are used for exporting the mesh to the fluid solver. Depending on the setting, calculation times and memory use might exponentially increase. For example, when using a moving mesh with subsurf as an obstacle, it might help to decrease simulation time by switching it off, or to a low subdivision level. When the setup/rig is correct, you can always increase settings to yield a more realistic result.
  • Domain:
    The bounding box of the object serves as the boundary of the simulation. No tiny droplets can move outside this domain; it's as if the fluid is contained within the 3-D space by invisible force fields. Currently (version 2.4.2) there can be only a single fluid simulation domain object in the file. The lengths of the bounding box sides can be different.

    Domain Space:
    The shape of the object does not matter because it will always be a fixed cubic of space, so usually there won't be a reason to use any other shape than a box. If you need obstacles or other boundaries than a box to interfere with the fluid flow, you need to insert additional obstacle objects inside the domain boundary.

    • Resolution:
      The granularity at which the actual fluid simulation is performed. This is probably the most important setting for the simulation as it determines the amount of detail in the fluid, the memory and disk usage as well as computational time. Note that the amount of required memory quickly increases: a resolution of 32 requires ca. 4MB, 64 requires ca. 30MB, while 128 already needs more than 230MB. Make sure to set the resolution low enough, depending on how much memory you have, to prevent Blender from crashing or freezing. If the domain is not cubic, the resolution will be taken for the longest side. The resolutions along the other sides will be reduced according to their lengths.

    • Preview-Res.:
      This is the resolution at which the preview surface meshes will be generated. So it does not influence the actual simulation, and even if there is nothing to see in the preview, there might a thin fluid surface that cannot be resolved in the preview.

    • Start time:
      Simulation time (in seconds) of the first blender frame. So this option makes the animation in Blender start later in the simulation.

    • End time:
      Simulation time of the last blender frame.

    • Disp.-Qual.:
      How to display a baked simulation in the Blender GUI (first pulldown menu) and for rendering (second one): original geometry, preview mesh or final mesh. When no baked data is found, the original mesh will be displayed by default.

      Displaying a Baked Domain: After you have baked a domain, it is displayed (usually) in the Blender window as the preliminary mesh. To see the size and scope of the original domain box, select Geometry in the left dropdown.
    • Bake directory:
      Directory and file prefix to store baked surface meshes with. This is similar to the animation output settings, only selecting a file is a bit special: when you select any of the previously generated surface meshes (e.g. untitled_OBcube_fluidsurface_final_0132.bobj.gz) the prefix will be automatically set (untitled_OBcube_ for this example). This way the simulation can be done several times with different settings, and allows quick changes between the different sets of surface data.

    • Bake-Button:
      Perform the actual fluid simulation. The blender GUI will freeze and only display the current frame that is simulated. Pressing Esc will abort the simulation. Afterwards two .bobj.gz will be in the selected output directory for each frame. Note on freeing the previous baked solutions: Deleting the content of the Bake directory is a destructive way to achieve this, be careful if more than one simulation uses the same bake directory (be sure they use different filenames, or they will overwrite one another).

      Reusing Bakes: Manually entering (or searching for) a previously saved (baked) computational directory and filename mask will switch the fluid flow and mesh deformation to use that which existed during the old bake. Thus, you can re-use baked flows by simply pointing to them in this field.

      Selecting a Baked Domain: After a domain has been baked, it changes to the fluid mesh. To re-select the domain so that you can bake it again after you have made changes, go to any frame and select (right-click) the fluid mesh. Then you can click the Bake button again to recompute the fluid flows inside that domain.

    • St/Ad/Bn-Button:
      Clicking this button will show other panels (Standard/Advanced/Boundary) of more advanced options, that often are fine set at the defaults.

      • Advanced-Button:

        • Gravity vector:
          Strength and direction of the gravity acceleration and any lateral (x,y plane) force. The main component should be along the negative z-axis [m/s^2]. All of the x,y,z values should not be zero, or the fluid won't flow (imagine a droplet in space). It must be some small number in at least one direction.

        • Viscosity:
          The "thickness" of the fluid and actually the the force needed to move an object of a certain surface area through it at a certain speed. You can either enter a value directly or use one of the presets in the drop down (such as honey, oil, or water). For manual entry, please note that real-world viscosity is measured Poiseuille (pronounced "pwazooze") units, and commonly centiPoise ('"sentipwaz"') units (cP). This table should help you correlate real viscosity measurements to Blender entries, but as a rule of thumb, multiply cP by 10^-6 to get Blender Viscosity Units:

          Blender Viscosity Unit Conversion

          -- Fluid -- -- cP units -- Blender Units
          Water (20°C) 1.002 (1x10^0) 1 x 10^-6 (.000001)
          Oil SAE 50 500 (5x10^2) 5 x 10^-5 (.00005)
          Honey (20°C) 10,000 (1x10^4) 2 x 10^-3 (.002)
          Chocolate Syrup 30,000 (3x10^4) 3 x 10^-3
          Ketchup 100,000(1x10^5) 1 x 10^-1
          Melting Glass 1x10^15 1 x 10^9

          Thus, manual entries are specified by a floating point number and an exponent. These floating point and exponent entry fields (scientific notation) simplify entering very small or large numbers. The viscosity of water at room temperature is 1.002 cP; so the entry would be 1.002 times 10 to the minus six (10^-6). Hot Glass and melting iron is a fluid, but very thick; you should enter something like 1 x 10^0 as its viscocity (indicating a value of 1x10^6 cP).

        • Real-World size:
          Size of the domain object in the real world in meters (blender units?). If you want to create a glass of water, this might be 0.2 meters, while for a single drop a centimeter (thus 0.01m) will be more suitable. The size set here is for the longest side of the domain bounding box.

        • Gridlevel:
          How many adaptive grid levels to be used during simulation - setting this to -1 will perform automatic selection.

        • Compressibillity:
          If you have problems with large standing fluid regions at high resolution, it might help to reduce this number (note that this will increase computation times).

      • Domain boundary type settings
        This is the same as for obstacle objects below, it will basically set the six sides of the domain to be either sticky, non-sticky, or somewhere inbetween (this is set by the PartSlipValue).
        • Tracer Particles
          Number of tracer particles to be put into the fluid at the beginning of the simulation. To display them create another object with the Particle fluid type, explained below, that uses the same bake directory as the domain.

        • Surface Smoothing
          Amount of smoothing to be applied to the fluid surface. 1.0 is standard, 0 is off, while larger values increase the amount of smoothing.
          Generate & Use SpeedVecs
          If this button is clicked, no speed vectors will be exported. So by default, speed vectors are generated and stored on disk. They can be used to compute image based motion blur with the compositing nodes.

  • Fluid:
    All regions of this object that are inside the domain bounding box will be used as actual fluid in the simulation. If you place more than one fluid object inside the domain, they should currently not intersect. Also make sure the surface normals are pointing outwards. In contrast to domain objects, the actual mesh geometry is used for fluid objects.
    • Volume Init Type:
      Volume Init will initialize the inner part of the object as fluid, this only works for closed objects. Init Shell will only initialize a thin layer for all faces of the mesh, this also works for non closed meshes. Init Both combines volume and shell, the mesh also should be closed. See the picture below.

    • Initial velocity:
      Speed of the fluid at the beginning of the simulation in meters per second.


      Example of the different volume init types: volume, shell and both. Note that the shell is usually slightly larger than the inner volume.

  • Obstacle:
    This object will be used as an obstacle in the simulation. As with a fluid object, obstacle objects should currently not intersect. As for fluid objects, the actual mesh geometry is used for obstacles. For objects with a volume, make sure that the normals of the obstacle are calculated correctly, and radiating properly (use the Flip Normal button, Mesh Tools pannel, Editing context [F9]), particularly when using a spinned container. Applying the Modifier Subsurf before baking the simulation could also be a good idea if the mesh is not animated.
    • Volume Init Type
      Same as for a fluid object above.

    • Boundary Type (see picture below)
      Determines the stickiness of the obstacle surface.
      • Noslip causes the fluid to stick to the obstacle (zero velocity),
      • Free(-slip) allows movement along the obstacle (only zero normal velocity),
      • Part(-slip) mixes both types, with 0 being mostly noslip, and 1 being identical to freeslip. Note that if the mesh is moving, it will be treated as noslip automatically.
    • Animated Mesh
      Click this button if the mesh is animated (e.g. deformed by an armature, shape keys or a lattice). Note that this can be significantly slower, and is not required if the mesh is animated with position or rotation IPOs.

    • PartSlip Amount
      Amount of mixing between no- and free-slip above.


      Example of the different boundary types for a drop falling onto the slanted wall. From left to right: no-slip, part-slip 0.3, part-slip 0.7 and free-slip.

  • Inflow:
    This object will put fluid into the simulation (think of a water tap).
    • Volume Init Type:
      Same as for a fluid object above.

    • Initial velocity:
      Speed of the fluid that is created inside of the object.

    • Local Inflow Coords:
      Use local coordinates for the inflow. This can be useful if the inflow objects is moving or rotating.

  • Outflow:
    Any fluid that enters the region of this object will be deleted (think of a drain). This can be useful in combination with an inflow to prevent the whole domain from filling up.
    • Volume Init Type
      Same as for a fluid object above.

  • Particle:
    This type can be used to display particles created during the simulation. For now only tracers swimming along with the fluid are supported. Note that the object can have any shape, position or type - once the particle button is pressed, a particle systems with the fluid simulation particles will be created for it at the correct position. When moving the original object, it might be necessary to delete the particle system, disable the fluidsim particles, and enable them again. The fluidsim particles are currently also unaffected by any other particle forces or settings.
    • Size Influence
      The particles can have different sizes, if this value is 0 all are forced to be the same size.
    • Alpha Influence
      If this value is >0, the alpha values of the particles are changed according to their size.
    • Bake directory
      Which simulation run to load the particles from, this should usually have the same value as the fluid domain object (e.g. copy by ctrl-c, ctrl-v).
 

Technische Details

Fluid animation can take a lot of time - the better you understand how it works, the easier it will be to estimate how the results will look. The algorithm used for Blender's fluid simulation is the Lattice Boltzmann Method (LBM); other fluid algorithms include Navier-Stokes (NS) solvers and Smoothed Particle Hydrodynamics (SPH) methods. LBM lies somewhere between these two. In general, it is really hard for current computers to correctly simulate even a 1-meter tank of water. For simulating a wave crashing through a city, you would probably need one of the most expensive supercomputers you could get, and it might still not work properly, no matter which of the three algorithms above you're using.

  • large domains
  • long duration
  • low viscosities
  • and high velocities.

The viscosity of water is already really low, so especially for low resoltuions, the turbulence of water can not be correctly captured. If you look close, most simulations of fluids in computer graphics do not yet look like real water as of now. Generally, don't rely on the physical settings too much (such as physical domain size or length of the animation in seconds). Rather try to get the overall motion right with a low resolution, and then increase the resolution as much as possible or desired.


Ein anderes Fluid Simulations Bispiel, erzeugt mit Blender und Yafray

 

Hints

  • Don't be surprised, but you'll get whole bunch of mesh (.bobj.gz) files after a simulation. One set for prelim, and another for final. Each set has a .gz file for each frame of the animation. Each file contains the simulation result - so you'll need them. Currently these files will not be automatically deleted, so it is a good idea to e.g. create a dedicated directory to keep simulation results. Doing a fluid simulation is similar to clicking the ANIM button - you currently have to take care of organizing the fluid surface meshes in some directory yourself. If you want to stop using the fluid simulation, you can simply delete all the *fluid*.bobj.gz files.
  • Before running a high res simulation that might take hours, check the overall timing first by doing lower resolution runs. Then, do a simulation for a narrow specific time segment (encompassing a frame or two) by
  • Only the bounding box of the domain object is used, but fluid and obstacle objects can be meshes with complex geometries. Very thin might not appear in the simulation, though, if the chosen resolution is too coarse to resolve them (increasing it might thus solve this problem).
  • Note that fluid simulation parameters, such as inflow velocity or the active flag can be animated with fluidsim IPOs.
  • Don't try to do a complicated scene all at once. Blender has a powerful compositor that you can use to combine multiple animiations. For example, to produce an animation showing two separate fluid flows while keeping your domain small, render one .avi using the one flow. Then move the domain and render another .avi with the other flow using an alpha channel. Then, composite both .avi's using the compositor's add function. A third .avi is usually the smoke and mist and it is laid on top of everything as well. Add a rain sheet on top of the mist and spry and you'll have quite a storm brewing! And then lightning flashes, trash blowing around, all as separate animations, compositing the total for a truly spectacular result.
  • If you're having trouble, or something isn't working as you think it should - just let me know: send the .blend file and a problem description to =nils at thuerey dot de=.

Limitations & Workarounds

  • One domain per blender file (as of Version 2.4.2), but you can have multiple fluid objects. Workaround: For prelims, move the domain around to encompass each fluid flow part, and then for final, scale up the size of the domain to include all fluid objects (but computation will take longer). This is actually a benefit, because it lets you control how much compute time is used by varying the size and location of the domain.
  • If the setup seems to go wrong make sure all the normals are correct (hence enter edit mode, select all, recalculate normals once in a while).
  • Currently there's a problem with zero gravity simulation - simply select a very small gravity until this is fixed.
  • If an object is inited as volume, it has to be closed, and have an inner side (a plane wont work). To use planes, switch to Init Shell, or extrude the plane.
  • Blender freezes after clicking BAKE. Pressing Escape makes it work again after a while - this can happen if the resolution is too high and memory is swapped to hard disk, making everything horribly slow. Reducing the resolution should help in this case.
  • Blender crashes after clicking BAKE - this can happen if the resolution is really high and more than 2GB are allocated, causing Blender to crash. Reducing the resolution should also help...
  • The meshes should be closed, so if some parts of e.g. a fluid object are not initialized as fluid in the simulation check that all parts of connected vertices are closed meshes. Unfortunately, the Suzanne (monkey) mesh in Blender is not a closed mesh (the eyes are separate).
  • If Blender crashes after clicking BAKE, the resolution is probably too high for your computer.
  • If the fluidsimulation exits with an error message (e.g. that the init has failed), make sure you have valid settings for the domain object, e.g. by resetting them to the defaults.
  • If you're still using Version 2.40: On some systems (e.g for Mac OS X) this version of Blender by default installs into a directory with a "+" in the name, e.g. blender-2.40-OSX-10.3+-py2.3-powerpc which causes an error message containing "syntax error in line N" after clicking BAKE. The easiest way to overcome this, is to remove the "+" from the Blender directory name, or enter another output directory. This is fixed in newer versions.
 

Weitere Informationen

Acknowledgements

The integration of the fluid simulator was done as a Google Summer-of-Code project. More information about the solver can be found at www.ntoken.com. These Animations were created with the solver before its integration into blender: Adaptive Grids, Interactive Animations. Thanks to Chris Want for organizing the Blender-SoC projects, and to Jonathan Merrit for mentoring this one! And of course thanks to Google for starting the whole thing... SoC progress updates were posted here: SoC-Blenderfluid-Blog at PlanetSoC.

The solver itself was developed with help and supervision of the following people: U. Ruede, T. Pohl, C. Koerner, M. Thies, M. Oechsner and T. Hofmann at the Department of Computer Science 10 (System Simulation, LSS) in Erlangen, Germany.

Inhaltsverzeichnis   next » 
- back to top -