Realflow Manual

Written by Thomas SchlickAuthor of RF_magazine (www.rf-magazine.com)

1. “HELLO” FROM THE DEVELOPERS

2. WELCOME TO REALFLOW 5

2.01 What Is RealFlow? 2.02 New Features in RealFlow 5 2.03 Basic Concepts a. The Third Dimension b. RealFlow Nodes c. Particle Systems d. Grid Fluid Domains e. Forces f. Dynamics And Animation g. Scripting h. Connectivity i. “RealFlow -nogui” j. Scene Scale

2.04 Notations And Abbreviations a. Commands And Menus b. Abbreviations c. Keys And Shortcuts

3. GETTING STARTED WITH REALFLOW

4. REALFLOW’S USER INTERFACE

4.01 Window Tools 4.02 Viewports 4.03 Nodes 4.04 Node Params 4.05 Global And Exclusive Links 4.06 Right-Click Menus 4.07 Menu Bar a. The File Menu

b. The Edit Menu c. The View Menu d. The Layout Menu e. The Tools Menu f. The Export Menu g. The Import Menu h. The Commands Menu i. The Playback Menu j. The Help Menu

4.08 Icon Bars a. The File Bar b. The Edit Bar c. The Nodes Bar d. The Scripts Bar e. The Transformation Bar

4.09 Timeline 4.10 Timeline Control 4.11 Simulation Control 4.12 Miscellaneous Tools 4.13 Messages 4.14 Curve Editor 4.15 Simulation Events 4.16 Batch Script 4.17 Movie Player 4.18 Help Viewer

5. ADJUSTING REALFLOW PREFERENCES 5.01 General 5.02 Simulation 5.03 Display 5.04 Backup 5.05 Notify 5.06 Script 5.07 Export

9

10

11111212131313141414151515

17171717

18

20

2020232324252526

262829303233343636

373737383838

39394041424243434344

45

45464748494950

5.08 Preview 5.09 Layout 5.10 Curves 5.11 Job Manager

6. THE EXPORT CENTRAL WINDOW 6.01 General Structure 6.02 Scene Tree Options 6.03 Exporting Particle Emitters 6.04 Exporting Grid Emitters 6.05 Exporting Grid Domains 6.06 Exporting Grid Mists 6.07 Exporting RealWave Nodes 6.08 Exporting Cameras 6.09 Exporting Daemons 6.10 Exporting Objects 6.11 Exporting Meshes 6.12 Exporting Job files 6.13 Exporting Log Files 6.14 Exporting Previews

7. HYBRIDO

7.01 Domains And Grids 7.02 A Basic Workflow For Grid-based Fluids 7.03 Common Settings a. The Node Panel b. The Initial State Panel c. The Statistics Panel d. The Display Panel

7.04 Grid Fluid Domain a. The Fluid Panel b. The Displacement Panel

7.05 Grid Fluid Emitter a. The Emitter Panel

7.06 Secondary Particle Emitter a. Concepts

7.07 Grid Splash Emitter a. The Grid Fluid Splash Panel

7.08 Grid Foam Emitter a. The Grid Fluid Foam Panel

7.09 Grid Mist Emitter a. The Mist Panel b. The Display Panel

7.10 Hybrido IDOCs a. Splash per IDOC b. Foam per IDOC c. Mist per IDOC

7.11 Notes About Interactions With Grid Fluids

7.12 A Grid Fluid Scenen (Tutorial) a. Creating An Ocean b. Displacement c. Evaluating The Simulation d. Splashes e. Mist f. Foam g. Grid Mesh

8. REALFLOW EMITTERS

8.01 Common Settings a. The Node Panel b. The Initial State Panel

51525253

56

5656585959606061616162636364

65

65666868696970

717173

7575

7676

7777

7980

818283

84848585

85

86888989909192

94

959596

c. The Particles Panel d. The Statistics Panel e. The Display Panel 8.02 RealFlow Emitter Types a. Circle Emitter b. Square Emitter c. Sphere Emitter d. Linear Emitter e. Triangle Emitter f. Spline Emitter g. Cylinder Emitter h. Bitmap Emitter i. Object Emitter j. Fill Object Emitter k. Fibres Emitter l. Binary Loader m. NBinary Loader n. Container

8.03 Standard Fluid Particles (Tutorial) a. A Basic Setup For Standard Fluid Emitter b. Working With Density c. RenderKit Meshes d. Standard Meshes e. Building A Range Of Meshes

8.04 Retiming A Simulation With A Binary Loader (Tutorial)

9. REALFLOW DAEMONS

9.01 Daemons And Scale 9.02 Common Settings a. The Node Panel b. The Display Panel

9.03 RealFlow Daemon Types

a. k Volume Daemon b. k Age Daemon c. k Speed Daemon d. k Isolation Daemon e. k Collision Daemon f. k Sphere Daemon g. Gravity Daemon h. Attractor Daemon i. DSpline Daemon j. Wind Daemon k. Vortex Daemon l. Layered Vortex Daemon m. Limbo Daemon n. Tractor Daemon o. Coriolis Daemon p. Ellipsoid Force Daemon q. Drag Force Daemon r. Surface Tension Daemon s. Noise Field Daemon t. Heater Daemon u. Texture Gizmo Daemon v. Magic Daemon w. Object Field Daemon x. Color Plane Daemon y. Scripted Daemon z. Filter Daemon aa. Sheeter Daemon

9.04 Plugins

10. REALFLOW OBJECTS

10.01 Common Settings a. The Node Panel b. The Initial State Panel c. The Grid Fluid Interaction Panel d. The Particle Fluid Interaction Panel

97101101

103103104104104105105107107108109110112113113

114114115118120121

121

123

124124124125

125

125126126127127127128129130132132133134135135135136136137137138139140140142142143

146

147

147148149149149

e. The Texture Panel f. The Rigid Body Panel g. The Soft Body Panel h. The RealWave Panel i. The Display Panel

10.02 Null Objects 10.03 MultiBody Objects a. The Texture Panel b. The Rigid Body Panel c. The Soft Body Panel d. The Display Panel

10.04 Plug-ins 10.05 Plug-ins 10.06 MultiJoints

11. REALFLOW MULTIJOINTS

11.01 MultiJoint Settings a. The Node Panel b. The Creation Panel c. The Forces Panel d. The Collisions Panel e. The Break Panel f. The Plasticity Panel g. The Statistics Panel h. The Display Panel

11.02 Collapsing Dominos (Tutorial) a. Preparing The Simulation b. Adjusting MultiJoints

12. REALFLOW MESHES

12.01 Adding A Mesh

a. Right-click Menus For Mesh Nodes b. Special Settings For Grid Meshes c. Storing Mesh Files

12.02 Common Settings a. The Filters Panel b. The Clipping Panel (RFRK/Standard) c. The Texture Panel (RFRK/Standard) d. The Optimize Panel (Grid Mesh/RFRK) e. The Shader Panel

12.03 Particle Mesh (RFRK) a. The Mesh Panel (RFRK) b. The Particle Magnitudes Panel (RFRK) c. The Display Panel (RFRK) d. The Field Panel (RFRK) e. The Particle Filter Panel (RFRK)

12.04 Particle Mesh (Standard) a. The Mesh Panel (Standard) b. The Optimize Panel (Standard) c. The Field Panel (Standard) d. The Noise Panel (Standard) e. The Deformation Panel (Standard)

12.05 Grid Mesh a. The Mesh Panel (Grid Mesh) b. The Texture Panel (Grid Mesh) c. The Display Panel (Grid Mesh)

13. REALFLOW CAMERAS

13.01 The Node Panel 13.02 The Camera Panel

153154156158160

161161161162162

162162162

164

164165165169170171172173174

175175176

178

178

179180180

180180181182183183

186187188189189190

190191192194194195

196196197198

199

199199

14. REALWAVE

14.01 File Types 14.02 Basic Workflows a. Adding A Modifier b. Dynamics Objects And Particle Interactions c. Foam Maps d. Particle Layer

14.03 RealWave Settings a. The Node Panel b. The Initial State Panel c. The Display Panel d. The RealWave Panel

14.04 RealWave Modifiers a. Common Settings b. The Object Interaction Global Settings Modifier c. The Control Points Modifier d. The Fractal Modifier e. The Spectrum Modifier f. The Scripted Modifier g. The RWC Sequence Modifier h. The Gerstner Modifier i. The Statistical Spectrum Modifier j. The Object Interaction Modifier

14.05 RealWave Emitters a. Object Splash b. Crest Splash

14.06 A RealFlow Scene (Tutorial) a. Adding And Adjusting Modifiers b. Animating A Buoy

15. IDOC

15.01 The Settings a. The Node Panel b. The IDOC Panel c. The Display Panel

15.02 Working With IDOCs 15.03 Grid Fluid IDOCs

16. JOB MANAGER

16.01 Getting Started a. Launching Manager And Nodes b. The Web-Interface

16.02 Sharing Simulation Jobs 16.03 Path Translation Rules 16.04 Status Disgrams a. “Current Jobs” Messages b. “Nodes” Messages

17. CURVE EDITOR

17.01 Basic Animation 17.02 The Curve Editor Toolbar a. Mode b. Pan/Scale c. Copy/Paste d. Undo/Redo e. Fit f. Snap g. Node Type h. Tangents i. Other

201

202202202202203203

204204204205205

208208208209210211213213213214216

216216220

221221223

225

225225225226

226227

228

228229231

237238239240241

242

244244244245245246246247247248248

17.03 The Curve Editor Menu Bar a. The File Menu b. The Edit Menu c. The Keys Menu d. The View Menu

17.04 Expressions a. First Steps b. Inverse Functions And Negative Values c. Random Values d. Conditions e. Complex Functions

18. REALFLOW PLUG-INS

18.01 Using Plug-ins 18.02 Developing Plug-ins 18.03 Provided Plugins a. CrowdFlow b. Morph

19. REALFLOW -NOGUI

19.01 Starting “RealFlow -nogui” 19.02 Using Flags

20. REALFLOW SCRIPTING

20.01 Python And RealFlow 20.02 Script Types And Scripting Windows 20.03 Common Settings a. The File Menu b. The Edit Menu c. The Script Menu d. The Help Menu

20.04 Batch Scripts 20.05 Simulation Events 20.06 Scripted Nodes 20.07 “Hello World” 20.08 Scalar Variables 20.09 List Variables 20.10 Dictionary Variables 20.11 Global And Local Variables 20.12 Operators 20.13 Data Types a. Integer b. Float c. Boolean d. Vector

20.14 Accessing RealFlow Nodes 20.15 Accessing Particles 20.16 Conditions 20.17 Building Vectors 20.18 Changing Attributes 20.19 Changing Particle Attributes 20.20 Custom Attributes 20.21 Affecting Particles With Daemons 20.22 Shifting Particles 20.23 Custom Functions 20.24 Using Modules 20.25 Creating Graphical User Interfaces (GUIs) a. Initializing A GUI b. Processing The Values c. Using The Variables d. File And Node Pickers

20.26 Final Notes

21. SCRIPTING – EXAMPLES AND IDEAS

21.01 Placing Objects

250250251251252

252254256257257258

260

260260260261263

266

266267

268

269269269270270271271

271272274274276277278279280281281282282282

284285287289290291292293294296297298299300301301

302

304

304

21.02 Placing Particles 21.03 Batch Simulations 21.04 Particle Shifting Using A GUI 21.05 Recording Animation Keys 21.06 Tracking Particles 21.07 RealWave Displacement Maps 21.08 Random Mass Change 21.09 Listings a. GUIParticleShift.rfs b. KeyRecorder.rfs

22. TABLES AND VALUES

22.01 Density a. Solid Substances b. Liquid Substances c. Gaseous Substances

22.02 Gravitational Acceleration 22.03 RealFlow Objects

307308309312314319320322323324

326

326326326326

327327

© Next Limit Technologies 2010

RealFlow 5. Manual Version 1.100

| 9

1 “Hello” FRoM THe DeVelopeRs

It’s been a long time since we released RealFlow version 4. Since then we have been working very hard, trying to pack a new version with everything we consider to be a breakthrough in the world of CG fluids and dynamics simulation. There is a huge array of new features in version 5 and you will find thorough explanations and useful tutorials in this wonderful user’s manual. We just want to highlight what we consider to be the most important additions.

There is a new, totally state-of-the-art hybrid solver, that we hope will enable all the users to achieve the type of shots that only the “big guys” can do right now. We call this new technology Hybrido (HYBrid larRge dImension LiquiD sOlver). To give you the basics: the main body of water is simulated using a grid-based solver. A algorithm automatically detects those areas where more resolution is needed (and we’re not just talking about curvature, which is a trick that many people use. In those areas our particle-based solver takes control to capture details – we call this a splash. But this is not end of the story, because now the particles, entering the main body of water, will automatically generate foam. This happens either in the form of particles, textures or both. A displacement is added on top of the main body of water, based on a statistical spectrum method. This approach captures the really fine details you can see on fluid surfaces. So now, we are able to create realistic simulations, but we’re not finished yet – there’s still something missing... Yes, you got it, it’s mist. Splash particles, travelling into surrounding air, are undergoing a process of fragmentation. In other words, they disintegrate to create mist.

All these simulation data have to be rendered in an efficient way, so we have released version 2 of the RealFlow RenderKit to help out. You can render mist, using our “RFRK_cloud” tool, as well as rendering splashes a volumetric way with a mesh. You can even render displacement maps.

Another highlight is a new C++ SDK, similar to the API (Application Program Interface) of the current Python SDK. Now you can create plug-ins that are intrinsically multithreaded, which makes a big difference in terms of efficiency!

We have also redeveloped rigid and soft body solvers from scratch and now you can do loads of cool things, like adding permanent deformation of your soft bodies. Stacking

of rigid-bodies is now much more accurate and robust. Joints are also an incredible breakthrough, because they can be created automatically just by detecting if the distance between the bodies’ polygons is small enough. And, of course, everything is multithreaded. The name of this new solver is “Caronte”.

A new target-driven plug-in daemon will improve the built-in Magic daemon and we are convinced you will like it. We’re sure you will also love the new CrowdFlow plugin, which enables you to simulate your particles as a fluid mixed with a crowd.

To find out more about all the new and improved features included in RealFlow 5, check out the “New Features in RealFlow 5” section.

Thank you for using RealFlow.

The RealFlow development team.



Introduction | 10

2 WelcoMe To RealFloW 5

After more than three years of research and development, Next Limit presents the 5th generation of its fluid and dynamics tool – RealFlow. Over the years RealFlow has become the most popular commercially available fluid simulator, used in many well-known feature film productions, TV programs, commercials, and games cinematics.

With RealFlow 4, Next Limit introduced many completely new or rewritten features, such as an interface to the Python scripting language, a freshly developed rigid body solver, a new interface and dozens of improvements in simulation speed and stability. RealFlow 5 represents another quantum leap in the company’s history and presents state-of-art tools for large-scale fluid surfaces, new solvers for soft and rigid bodies and vastly improved wave generation, to name but a few. All these exciting new functions are seamlessly integrated into RealFlow’s fully customizable user interface and easy to handle.

The manual has also been completely rewritten to bring you up to speed with RealFlow 5. Experienced users will find many useful tips and tricks, as well as comprehensive explanations of the new features. Beginners are guided through the software with easy-to-follow tutorials and detailed explanations of parameters and settings.

2.01 What Is RealFlow?In brief, RealFlow is a fluid and dynamics simulation tool. With RealFlow you’re able to calculate the interactions between individual particles acting like water, for example. On the other hand it’s also possible to mimic the behaviour of bodies under the influence of certain forces, like gravity or wind. The dynamics functions in RealFlow also allow collisions and interactions between soft and rigid bodies. Another aspect is wave generation with RealWave. All these elements can be combined and merged without limits – it’s possible to use fluids with rigid bodies or ductile objects, generate fluid splashes on ocean surfaces, create buoying items, and simulate underwater behaviour.

RealFlow is available for all major platforms: Microsoft Windows, Mac OS X and Linux. All versions support the 64 bit mode, too and are able to use more than 4 GB of RAM. Another

addition to the RealFlow product range is the RealFlow Renderkit (RFRK). It’s a set of tools that has been designed to facilitate the complex task of rendering RealFlow fluids. The RFRK enables you to generate procedural geometry at render time and also render individual fluid particles. With Maxwell Render 2 you also have the possibility to directly create and render meshes using the same tools as the RFRK. With this interface, fluids can also be rendered on a particle basis for foam and spray effects.

For more information about the interaction between RealFlow and Maxwell Render please visit the Maxwell Render homepage (http://www.maxwellrender.com/) or contact Next Limit’s sales department.

2.02 New Features In RealFlow 5RealFlow has gone through lots of major and minor changes. The main features will doubtless catch your attention, but there are also many improvements, which are not immediately visible at first glance. These changes affect the stability, memory efficiency, user friendliness, speed and contextual help menus. Here are some highlights:

HybridoA new fluid solver for mid to large scale simulations with sophisticated secondary effects, like splashes, mist or foam generation, and displacement maps for use with the final mesh. Hybrido is surely RealFlow’s most impressive novelty and creates stunning results. They’re incredibly fast, even with millions of particles, while memory usage is kept to an absolute minimum.

IDocs/Job ManagerIDOC stands for “Independent Domain Of Computation” and can be used with both the new Hybrido solver (splash, foam, mist) and standard fluids. Non-interacting domains can be spread across several computers for simulation. With the new Job Manager you can distribute the individual domains and keep track of the results.

Fluid emitterThe solvers have been highly accelerated. Simulations with standard fluids are now up to 20 times faster. Another new feature is the container emitter. That’s just an empty bin,



Introduction | 11

ready to pick up your particles and perfectly suited for particle swapping or foam creation. Former RealWave-specific emitters are now part of the software’s wave creation tool.

DaemonsDaemons are now multi-threaded and can affect all standard fluids, dynamics nodes (including MultiBodies) and mist particles. Most daemons can also be used for Hybrido particles. The new filter daemon let’s you specify certain characteristics and even expressions to shift particles to a container emitter.

“caronte” – Rigid Body Dynamics"Caronte", the new rigid body dynamics engine has been completely rewritten for more performance, better collision detection and easier handling. Rigid body dynamics now supports more than one processor and constraints have been replaced by MultiJoint objects.

“caronte” – soft Body DynamicsThis tool has also been rewritten from scratch. It’s much faster and more reliable, and also offers a completely fresh interface with new parameters. An important change is that soft bodies no longer use particles to describe the bodies’ vertices.

RealWaveA statistical spectrum modifier used for sharp cresting waves. Also it’s possible to export tileable displacement maps for large ocean surfaces. You’ll additionally find a Gerstner wave modifier and the possibility to import file sequences.

curve editorThe curve editor has been vastly improved and now supports the selection of keys over multiple curves. New tools have been added for better and easier curve drawing and processing. It’s also possible to mix keyed curves with expressions. Sophisticated tools for navigating the graph window and for copy/paste actions have also been implemented.

python scriptingThe Python interface provides commands and support for the new functions. Additionally, a completely new structure for event-based scripts has been introduced. It’s now also

possible to manage scripts in a clearly arranged tree structure and use the new auto-complete function for the implemented statements. Another improvement concerns RealWave meshes – with RealFlow 5 you can affect vertices along all three axes.

MeshingThere are two completely new ways to create meshes. Firstly, you can calculate meshes on the fly from millions of particles, in conjunction with the new grid fluid solver Hybrido. Experienced users will find some similarities to the traditional meshing engine in RealFlow 4. The other new meshing approach provides the same tools as Next Limit’s RealFlow RenderKit. The RenderKit meshing engine is also part of Next Limit’s Maxwell Render 2.0 software and can read RealFlow’s particle BIN files. This ability to exchange data between different programs and render engines is fairly unique.

New objects and object FeaturesRealFlow 5 provides a new Cross object. Users are now also able to load image maps and image map sequences for some particle-fluid interactions. Parameters, like “Particle friction” or “Sticky”, can be specified as maps, showing zones with different values based on the greyscales of the map. MultiBody objects can be used to load a large number of individual items within a single node – this also drastically shortens import time.

plug-ins and sDKProgrammers and developers now have the option to write their own extensions and commercial plug-ins for RealFlow. A complete Software Development Kit for C/C++ provides the necessary tools and functions to get you started.

GUIRealFlow’s interface is now even more friendly. New icons, a cleaner layout and fast OpenGL shaders for displaying meshes have been added. The simulation events window now provides a tree structure for fast access to your event scripts. Another very useful addition is a new internal Movie Player to create animated previews directly within RealFlow.

Help systemA completely new and integrated help system is also part of RealFlow 5. The help system is directly based on the new manual and provides detailed information for all features, functions and parameters. It also includes the Python scripting reference.



Introduction | 12

A three dimensional domain gives the user the possibility to look at an object, or an entire scene, from all sides. This is also called perspective view and you can virtually walk around the objects. RealFlow also knows two dimensional views, like front, top or side. There, the point of view is fixed and can only be altered within two dimensions. This change of view is called panning.

Visualization of a complex velocity vector field in RealFlow.

The 3D space is the place where your simulation happens. It includes a grid to let the user know where the origin is. Typically, a 3D scene also includes a camera, though this isn’t absolutely necessary. With cameras it’s easier to store and recall certain views or follow other items in the scene. For this purpose, RealFlow supports multiple cameras and you can even import previously animated (or static) cameras from various applications.

Everything that’s created in RealFlow or added to the scene is also part of the 3D space and can be manipulated there. Another important feature of 3D programs is shading to improve the spatial impression. RealFlow offers different shading methods and you can also decide whether you want to illuminate the objects with one or two light sources. Together with the four standard views you have full control over your 3D elements.

64-Bit supportAll versions of RealFlow 5 (Windows, OS X, Linux) now support 64-bit operating systems and can make use of the entire available memory. At the moment, OS X 10.6 supports this mode only for the Node Version, but we’re working on a GUI version. 64-bit applications were designed to make use of the entire amount of RAM installed in your computer, but do not necessarily accelerate simulation speed.

2.03 Basic conceptsRealFlow can simulate highly complex interactions between various objects to mimic natural phenomena, such as fluids, collisions or deformations. Though there’s an enormous amount of physics and maths behind these simulations, the user actually doesn’t have to be proficient in natural sciences. Everything is done by the software and the included tools. Nevertheless it’s definitely useful to have a basic understanding of natural processes and some fundamental physics. This understanding will help you to get a feeling for motions, scales and the plausibility of your simulations. Another reason is RealFlow’s mode of operation, because many parameters have a physics background, for example density, mass or friction. Another concept concerns programming. Since each software has its limits, RealFlow provides interfaces to Python and C++ to overcome these restrictions.

a. The Third Dimension

RealFlow’s workspace is three dimensional. This means that the position of an object or particle is always described by three coordinates, named X, Y and Z. This concept is not only valid for positions, but also for rotation, scale and many other characteristics, like the pivot point. In terms of dimensions, e.g. for a cube, the coordinates are also known as length, width and height.

To specify an object’s coordinates it’s important to have a reference point. This special point is called “origin” and is located at the scene centre of the scene. Following the XYZ notation, a particle with coordinates of [ 0,0,0 ] is directly located in the origin. In RealFlow the XYZ space is displayed as a system of three axis which represent a so-called coordinate system. A set of two coordinates (XY, XZ or ZY) is called a plane and is always two dimensional. It’s also possible to create a coordinate system from just two axis. In this case the origin’s coordinates are [ 0,0 ].



Introduction | 13

b. RealFlow Nodes

In order to calculate simulations, RealFlow needs objects – so each item that’s inside a scene could be considered as a node. But this kind of definition is not enough, because the objects have different functions. Some are used to create particles, others add forces or waves. It makes sense to group the RealFlow objects according to their functionality – for example emitters, daemons or RealWave surfaces. These groups also include “traditional” objects, like spheres or vases. Traditional objects are different from RealFlow’s other object groups, because they consist of polygons and vertices, representing the shape you finally see. Emitters or daemons also have a graphical representation, but that’s only for visualizing their location and dimension, because an emitter cannot collide with a daemon, for instance. The emitter node itself isn’t able to interact with a cube either, but the particles, spilled out from this emitter, can do so.

RealFlow’s different node types in the Icon Bar.

Real or traditional objects also have the ability to act as simple collision objects for fluids, as rigid bodies with physical characteristics, or as ductile soft bodies. It doesn’t matter if they’re native RealFlow objects or imported. No objects have this ability. These are the node classes you can use: domains, emitters, daemons, polygon objects, meshes, wave meshes and cameras. All these types and their functionalities are explained later.

c, particle systems

Particles are generated by emitters and their total amount represents the fluid. Each particle can be seen as a point in 3D space with certain properties, like velocity, position or mass. Though it’s possible to address each particle individually (e.g. with scripting), it cannot be discussed as a single object. However, a particle has a physical dimension and is capable of influencing other objects. The final shape of the fluid is a result the total amount of particles and forces acting

1. between the particles and2. on particles from the outside.

Turbulent interactions between different fluid types.

d. Grid Fluid Domains

Previous versions of RealFlow exclusively used a grid-free approach to simulate the behaviour of fluids. This concept is perfectly suited for smaller scenes, where a certain amount of details is needed, but with large-scale simulations it quickly reaches its limits. To overcome this restriction, RealFlow now can make use of predefined grids, also called domains, with customizable resolution. The idea is to create just the “core” of the fluid at a fairly low level of detail, making it possible to rapidly solve the fluid equations. Whenever a higher amount of detail is required, RealFlow can detect these areas and add standard splash particles to refine the simulation. Splash particles are again generated within certain areas, defined by the user.

This sophisticated hybrid technology makes it possible to adjust the quality and level of detail exactly to your specific needs at maximum simulation speed! Another advantage



Introduction | 14

is RealFlow’s ability to generate secondary particles, for example splashes, from cached simulation data – even over a network. With this workflow it’s much easier to create large-scale simulations, because you can keep the core fluid particles and develop several versions with splashes and mist, or write out everything in several passes for better pipeline integration and post-processing.

e. Forces

A force causes an object to change its velocity. This brief definition already contains everything you need to know. Whenever there’s a force acting, then the particle (which is here considered as a very small object) or object becomes accelerated and changes its previous position. There’s only one binding condition: the object must have mass, because a massless object is not affected by forces. The basic formula for forces is:

F = m · a

F is the symbol for force, m stands for mass and a defines some kind of acceleration. Acceleration could be gravitational acceleration, for example, also called g. By simply setting m = 0, you can see that the resulting force F becomes 0, too. That’s why every object needs a certain amount of mass to become accelerated.

In RealFlow an external force can be introduced by adding one or more daemons to a scene. Very popular forces are gravity, wind, drag and vortex. A big plus is that all these forces can either act globally on the entire scene, or locally on selected objects, within a defined volume. Forces can affect particles as well as objects. In RealFlow it’s possible to add as many daemons as you want.

f. Dynamics and animation

This is another very important concept, because these methods are fundamentally different, though both share a common characteristic: motion. Animation is a manual (or semi-automatized) process of recording certain properties at particular points in time. This is method is also known as keyframing. At each point a new key is set, containing the new values. The differences between the current and the previous key are interpolated by the software, resulting in a motion. RealFlow can handle both imported animation keys from 3D applications and RealFlow’s tools.

On the other hand, dynamics doesn’t need manually set keys. The user simply defines starting values for various parameters (for example velocity, position, mass etc.) and adds forces. The simulation software then calculates the entire motion of the objects, based on real physics. With dynamics it’s possible to simulate interactions between different objects in a physically correct way. With manually set keys this would be a really tricky task requiring an enormous amount of experience.

Of course, the dynamics simulation is recorded, too, to enable playback or export the data to a 3D software, but actually this isn’t absolutely necessary. With identical starting values we could repeat the calculation again and again, and the result would always be the same – at least theoretically. Another idea is to write an animation key for each change in position and rotation. This method is called baking and can be performed either with Python scripting or inside some 3D applications.

A third type of motion recording is expressions. An expression is a formula that tells an object how to move. With expressions, animation keys aren’t needed and it’s not necessary to introduce forces. Expressions can also serve as a starting condition and the object’s motion becomes influenced by forces on its way. Expressions are a very convenient way to create repetitive motions, for example, without the need of Python scripts. Another advantage with expressions is the fact that they are multi-threaded, while Python can only use one processor of a computer.

g. scripting

Scripting is a really powerful extensions and once you’ve started with it you’ll never look back. Of course, it’s not easy for beginners to learn the basics of a new software and a scripting language. Python scripting was introduced in RealFlow version 4, giving the users a powerful tool to influence RealFlow independently from most of its technical restrictions. Next Limit chose Python, because it’s an easy-to-learn and freely distributable language.

Scripting doesn’t only allow the user to influence particles or objects, it makes it possible to automatize certain repetitive tasks, change various parameters from thousands of items in a single pass, write out text files, bake dynamics, create customized simulation data files, or turn simulation and dynamics properties on and off, to name but a few. Creating Python scripts under RealFlow is discussed separately, since it’s a very important and versatile feature. There’s a basic course contained in this manual.



Introduction | 15

open RealFlow. Without GUI you can speed up many processes, because RealFlow does not spend CPU power for updating the viewports. With this mode of operation, RealFlow’s simulation speed can be increased up to 30%.

To make use of this version, the first simulation stage has to be subdivided into two separate parts again. The first part is the assembly of the scene and the adjustment of all parameters, including the export and file format options. This has to be done within the standard GUI version. In the second part the previously created project file is simulated with “RealFlow -nogui”. Finally, these data are imported into your 3D program again to become textured, shaded and rendered.

j. scene scale

Scene scale was and still is one of RealFlow’s fundamental concepts. Beginners often struggle with the proper handling of different scene scales. In RealFlow 5 the scale concept has drastically changed and is now not only limited to geometry. Now scale can be described individually for basic geometry and overall scale, as well as for force daemons acting on particle fluids, grid fluids and objects. Scene scale is also represented by the supporting world grid in RealFlow’s 3D viewport. One grid square is exactly 1 m x 1 m with a standard scene scale of 1.0. Scale is actually one of the core concepts of RealFlow, because it strongly influences the credibility of a simulation and also simulation time. Your global scales can be adjusted under Preferences:

Menu bar > File > Preferences > General

There you can find the individual settings for geometry and force scales. These values should be specified only once and then remain untouched. They’re valid for each and every scene you’re going to create and they can be seen as global values. Actually you just have to adopt “Geometry scale” to your favourite 3D application. “Daemon force” related scales should also be left at 1.0. Please keep in mind that “Daemon force” scales work independently from “Geometry scale”. If you have to use a “Geometry scale” of 0.01, force scales should still be 1.0, because it’s not necessary to compensate “Geometry scale” with higher or lower force scale settings.

It’s certainly sometimes unavoidable to change scene scale on a local level for a particular scene. For this purpose there’s a button giving you the possibility to change scale whenever necessary. These local settings override the global preferences and will be saved with your

h. connectivity

You have to bear in mind that RealFlow is not a plug-in, but a so-called stand-alone program. This means that everything happens within a user-friendly and fully customizable user interface, independent from other software tools. It’s virtually possible to run RealFlow without any other supporting software. You can add fluids, waves, or objects and simulate their interactions. RealFlow is especially tailored for fluid and object dynamics, and therefore lacks functions you know from other 3D programs, like modelling, rendering and complex animation tools, as well as texturing, or UV manipulation features. All these tasks are done outside RealFlow. To establish a connection between both worlds, Next Limit offers free plug-ins for the following packages:

• Autodesk’s 3D Studio Max• Autodesk’s Maya• Autodesk’s Softimage• Maxon’s Cinema 4D• Newtek’s Lightwave• Side Effect’s Houdini

These plug-ins have to be downloaded and installed separately into the appropriate folder of your 3D software. Once installed, they’re used to process the simulation data, meshes and fluid particles for final texturing and rendering. This workflow guarantees best compatibility, since the results can be rendered directly within your favourite application. Another advantage is seamless integration into VFX pipelines.

The whole process can be subdivided into two stages. The first one concerns the simulation process. During this step the entire project is prepared and calculated. The second stage is to establish a connection between RealFlow and your favourite 3D application. For this purpose RealFlow provides

1. various file formats for data and image transfer2. a set of plug-ins to import and export simulation and geometry data

i. RealFlow -nogui (formerly “command line Version”)

RealFlow can be run in two different modes: GUI and NOGUI. GUI stands for “Graphical User Interface”. “RealFlow -nogui” is not a separate program, it’s just a different way to



Introduction | 16

scene. So you don’t have to repeat your adjustments each time you’re opening the project. By clicking on this button a window opens where you can adjust all required settings:

The “Scale options” button and its associated menu.

Geometry scale

“Geometry scale” is of special importance, because it influences your simulation in many ways. One reason for using different scales are the various software packages supported by RealFlow. Internally a 3D program works with its own particular scale and this has to be compensated for RealFlow. Since Maya can be considered as one of the leading packages for VFX and production, it’s the standard for RealFlow’s solvers. This means that geometry scales from Maya and RealFlow are exactly the same. This also implies that RealFlow’s default “Geometry scale” of 1.0 directly represents Maya’s internal scale. In other words: objects from Maya are displayed 1:1 inside RealFlow. Another important fact with “Geometry scale” 1.0 is that the solvers work best at this particular scale.

Other 3D programs, for example Cinema 4D, work at very large scales. Cinema 4D’s scale is one hundred times larger than Maya’s. As a result, objects from Cinema 4D appear very large inside RealFlow and the ratio is 100 : 1. To compensate this, RealFlow offers a “Geometry scale” setting. In this case, scale has to be reduced to 0.01. Only with this compensation it’s possible to work at reasonable scales without the need of very large

particle amounts: an object being one hundred times bigger than a RealFlow object at scale 1.0 will need much more particles to become filled! Nevertheless, very small scales can be a real challenge for RealFlow and you should consider to work at larger scales, and adapt your objects accordingly.

“Geometry scale” can be seen as a magnifying glass. You can scale up or down a scene without changing the physical dimensions of the included objects. Imagine a glass on a table that fills with water. When you’re relatively far away you can only see some bigger splashes and the rising fluid level. By approaching the glass it’s possible to observe more and details, small splashes, droplets and maybe some sparkling. When you get closer, the glass (and the fluid) also appears bigger but, of course, it does not change its size! It still has the same dimensions as before, but now you’re closer. That’s actually the idea behind RealFlow’s “Geometry scale”. By raising “Geometry scale”, RealFlow internally works with a larger object making it possible to achieve a higher level of detail. Conversely you can scale down to make a scene more realistic. This method is non-destructive, because the objects are not really affected and you can export your fluids to a 3D program without any changes or further steps.

A scale change influences your entire scene! When altering “Geometry scale”, “Collision distance” will be adapted and the objects appear bigger or smaller. On the other hand, emitters are not affected. They will remain exactly as you have created them. This means that you have to adopt emitters manually and this mainly influences resolution and the emitter’s physical dimensions. The number of particles can drastically increase or decrease, additionally the fluid will behave different. So if you have to perform “Geometry scale” changes, always be careful and start with moderate values! Scale changes also have a huge impact on simulation times and the number of particles.

Daemon Force scales

Daemon force scales are a new concept in RealFlow 5. You can adjust forces for particle fluids, grid fluids and objects independently from each other. Because of the new grid fluid solver, it became necessary to introduce this differentiation. Grid fluids are normally used for mid- to large-scale simulations, while standard particle fluids are perfectly suited for small scenes, due to their high level of detail. To compensate this difference, it’s now possible to apply individual force scales to the solvers.

The key with this feature is that one daemon can act completely differently on grid fluids,



Introduction | 17

particle fluids and objects. It’s not necessary to introduce three force daemons and make them exclusive to the related nodes. By setting different scales for the various solvers you’ll be able to adjust everything to your needs without having to alter all the daemons individually each time. Higher force scale values create higher accelerations, lower settings have the opposite effect.

2.04 Notations and abbreviationsIt’s necessary to introduce a few notations making it easier for you to follow this manual. The abbreviations are actually very common and most likely they’re known from other applications, but for the sake of completeness they’re provided here.

a. commands and Menus

A sequence of commands is always separated by an angle bracket “>”, for example:

Menu Bar > Edit > Add > Grid fluid > Domain

Selected object > Node Params > Fluid > Density

b. abbreviations

Common abbreviations are:

LMB Left Mouse Button RMB Right Mouse ButtonMMB Middle Mouse Button MMW Middle Mouse Wheel

OS Operating system GUI Graphical user interfaceRFRK RealFlow RenderKit RBD Rigid body dynamics SBD Soft body dynamics

3DS 3D Studio MAX C4D Cinema 4DLW Lightwave XSI Softimage

c. Keys and shortcuts

It’s often necessary to use certain combinations of keys to activate a function or switch to a particular mode. Sometimes they’re combined with mouse buttons:

Rotate viewport: Alt + LMB “Press the Alt key on your keyboard, hold it and drag the mouse while holding the left mouse button.”

Switch to flat shaded mode: 3“Simply press the 3 key on your keyboard. A mouse action is not required here.”



Introduction | 18

3 GeTTING sTaRTeD WITH RealFloW

Now it’s finally time to start RealFlow. Experienced users will surely get along easily, though the interface has been updated. New customers should first read through the entire section about RealFlow’s graphical user interface and its numerous possibilities.

After RealFlow has launched, a window appears. This is RealFlow’s Project manager and contains functions to create a new scene or open an existing file. By default, all new files are created in a certain directory. This specific path can be changed permanently under Preferences, but for the very first project it’s currently not necessary to alter this path.

RealFlow’s Project Manager under Windows XP® during startup.

First of all you must enter a “Project name”. By clicking on the “CREATE A NEW PROJECT” button, RealFlow generates a set of different folders, where the simulation files wil be stored later. All these folders are grouped under the project’s main directory, carrying the name you’ve entered before. If you didn’t specify an alternative path, everything is stored under the program’s default location, which is printed one line below. “Full path” displays the entire path to your scene including the previously entered project name.

A scene can be opened with the appropriate button on the upper right or via the “Recent projects” list. To open a file from this list, simply double-click on the desired project. As long as the Project Management window is visible, it’s not possible to access the underlying windows or panels. You first have to either close the window or define/open a project. Now enter a name of your choice and click on “CREATE A NEW PROJECT”, or directly define a new path to a custom directory and then create the project.

If you want to have a look at the project’s directory, choose from the menu bar:

File > Open Project Folder...

This command opens an external window from the operating system to check whether all files have been created or not. The actual RealFlow file has the project’s name and the extension FLW, e.g. “beach_scene.flw”. It’s important to understand the structure and hierarchy of the project’s directory, because RealFlow stores and reads files directly from these folders. Some of these directories are only created in case of need:

gridThis is the place for all simulations file from the new large scale fluid engine. The “pxy” subfolder contains proxy files.

initialStateHere, RealFlow stores all files that can be used to start simulations from previously recorded states, e.g. relaxed and calm fluid volumes.

meshesPolygonal meshes from grid and traditional fluid simulations can be found here.

particlesAll particle files with the BIN (“binary”) extension. In case of need you’ll also find additional folders for mist emitters. These directories carry the name of the appropriate node and only appear when mist particles were simulated in cache mode.

imagesWetmap and foam-map sequences can be found here.

logThe log file is stored in this folder. It stores exactly the same information from RealFlow.



Introduction | 19

objectsThis folder contains dynamics data and files for geometry/object exchange.

wavesRealWave cache files (RWC) can be found here, but RealWave surface deformation files (SD) are located under “objects”.

preview RealFlow stores all preview-based image sequences and videos here. The folder contains two directories, called “images” and “video”. “video” is also the home of a “frames” folder, where all images from automatically generated video previews will be stored.

foamThis folder is created automatically on demand and contains foam cache files. With activated foam-maps, another directory is created storing the textures. This directory carries the name of the related grid fluid domain.

mistLike foam, this directory is only created on demand. You can find the mist cache files here.

These directories are not only important for storing RealFlow files, but also for importing simulated data into your 3D application. The “objects” folder is of special importance, because it’s recommended to store all exchange files you’ve created within this directory. By default, RealFlow looks for SD files there and you don’t have to browse through your hard disc.



Introduction | 20

4 RealFloW’s UseR INTeRFace

RealFlow comes with an default layout that’s always applied while starting the application. This standard interface can be changed to your individual needs and then defined as a new start layout. The initial screen is almost the same for all operating systems. Only a few buttons, some system specific font faces and handles are slightly different. The layout itself is separated into several sections, containing everything you need for setting up a RealFlow scene, modifying objects, and accessing all of the software’s parameters and nodes. To get you off to a good start, it’s a good idea to classify the different parts:

NodeElementscontainViewports, Nodes, Node Params, Exclusive Links, Global Links, Right-click Menus

MenuBarcontainsMenu Bar

IconBarscontainFile Bar, Edit Bar, Nodes Bar, Transformation Bar, Scripts Bar

TimelineElementscontainTimeline, Simulation Control, Miscellaneous Tools, Animation Tools, Timeline Control

OtherWindowscontainMessages, Curve Editor, Simulation Events, Batch Scripts, Movie Player, Help Viewer, Job Manager

4.01 Window ToolsThe top bar of each panel contains a couple of different symbols and icons, two on the left, three on the right. Windows and Linux users will immediately recognize them:

The first two symbols represent functions for changing a window’s content and different split views. The following three icons represent functions for A) minimizing, B) maximizing and C) closing a window. In this context, “Maximizing” means in that the window is detached from the layout and available as a floating window.

RealFlow’s panels don’t have a fixed assignment. Each window can easily be transformed into another one. For example, it’s possible to convert a viewport window into a Curve Editor, or a Global Links panel into a Node Params window. By clicking on the symbol on the far left, RealFlow opens a little menu, showing all of its available types. Active windows are displayed in grey, invisible ones are white.

The second icon on the left is used to create various arrangements of split windows. You can choose between “Split Vertical”, “Split Horizontal” and “Split Quad”. Of course, this option only makes sense with RealFlow’s viewport. Applying “Split Quad”, for example, to the Nodes panel creates three additional viewports. You can apply as many windows as your operating system can handle. The panels are also resizeable and for this purpose the interface provides a slider. Simply position your mouse cursor between two windows to activate the drag mode – now it’s possible to shift the borders.

4.02 ViewportsThese are surely the most striking windows and contain all scene elements. You can easily toggle between 2D and 3D views, choose from different shading modes and display various information about the nodes, e.g. the amount of grid cells. The viewports are fully



Introduction | 21

customizable in terms of colours, information and size, but some of these settings have to be made under Preferences (see page 45). Other settings are part of the “View” menu and will be explained there (see page 28). These options include shading methods, switching perspective or background pictures, for example. The empty default viewport is separated into four windows, offering different views. In detail these views are “Top View”, “Front View”, “Side View” and “Perspective View”. A fifth alternative is called “SceneCamera View” and is only available with an imported camera or one of RealFlow’s cameras.

Each viewport shows a black domain with a brownish grid. This grid represents RealFlow’s world scale: a grid cell represents an area of 1 m x 1 m by default. This size is not only an assistance for you to adjust or align objects, it also allows you to estimate the real scale of your scene. This is important, because many of RealFlow’s settings are related to scales and dimensions. It also affects simulation time and the number of particles, because larger particle amounts take significantly longer to simulate. The grid’s scale is a kind of basic unit and all of RealFlow’s physical objects (emitters, bodies, RealWave meshes and even many daemon boundaries) are based on this size. Additionally, RealFlow’s dynamics engines, also called solvers, work best at this special scale or even-numbered multiples of it. Under Preferences (page 47) you can alter the default grid size.

The layouts also show some basic scene information about the objects in your scene. This information is displayed on the upper left and contain things like number of particles, or a node’s name. The current point of view can be seen there, too. At the lower right of the active viewport you can see information about time. “TC” is the abbreviation for time code and is directly connected to the timeline. Please note that RealFlow’s default frame rate is 25 FPS, but this can be adjusted to your own needs. The time code format is

hours : minutes : seconds : frame

“SC” represents simulation time and tells you for how long the current scene is calculating.

Time code (TC) and simulation time (ST).

The viewports are fully controllable with combinations of keys and mouse movements. RealFlow’s viewports support OpenGL, a fast method to display, draw and shade objects. This method allows you to interactively change to different perspectives by dragging the

mouse. The 3D modes (“Perspective View” and “SceneCamera View”) know three degrees of freedom for changing the point of view: Panning, zooming and rotating. The 2D views (“Top”, “Front”, “Side”) are restricted to panning and zooming. These modes directly change the users point of view, not the position of the objects in 3D space – it can be compared with a camera movement, where you can define a certain field of view.

The three buttons of the mouse are used to adjust this field of view. To perform a change of view, move the mouse cursor to a viewport window and do the following:

Alt + LMB for rotatingAlt + RMB for zoomingAlt + MMB for panning

While dragging the mouse up and down or from the left to the right, the view’s changing interactively and in real-time.

u On page 22 you can see all cursor possibilities for controlling the viewport.

Updating the viewports is a very CPU intensive task and may take up to 30% of your processor’s capacity with slower graphic cards. Especially when you have large scenes with large particle amounts the simulation process might slow down tremendously. For these cases there are simple, yet effective methods to save CPU power:

• Use only one viewport while simulating, best one of the 2D views.• Minimize RealFlow’s entire workspace as far as possible.• Click onto an empty area of the viewport and then press Alt + D to deactivate the

viewport. This is one of the most effective ways to accelerate your simulations!• Use RealFlow’s “Non-GUI” mode for the simulation process.• Uncheck the “Display at frames” option under Preferences.

There are a few more shortcuts to alter perspective and display modes. These commands are also available from the View menu, but for the sake of completeness here they are:

1 for “Front View” 2 for “Top View”3 for “Side View” 4 for “Perspective View”5 for “SceneCamera View” 7 for “Bounding Box”8 for “Wireframe” 9 for “Flat Shaded”0 for “Smooth Shaded”



Introduction | 22

Rotate

+ Alt key + Drag + Alt key + Drag + Alt key + Drag

+ Drag

+ Hold

+ Shift key

Select single node

RMB menus Zoom (Middle wheel)

Rectangular selection Select multiple nodes

Pan Zoom



Introduction | 23

4.03 Nodes

The Nodes panel is actually nothing more than a list, containing the entire range of elements in your scene. Once an object is added to the scene it directly appears in this list. By removing it from the viewport, the item disappears from the Nodes panel and vice versa. The Nodes panel allows you to organize your objects and for this purpose there are two submenus. Both can be called by clicking with the right mouse button either on an

• activated (highlighted) node• empty part of the Nodes window.

Right mouse button menus for the Nodes panel.

“Rename” simply makes the activated node’s name editable for changes.

“Remove” is used to delete an object from the current scene. With imported objects from

SD files it’s a bit different, because it’s not possible to remove individual items.

“Group” is needed when you want to create a group of objects from a selection. A selection is made with LMB click on the first object of the following group and then Shift + LMB click on the last object. The result is a list of highlighted nodes, which can be grouped with RMB + Group. It’s also possible to create a selection of individual items with Ctrl + LMB click (Windows/Linux) or Cmd + LMB click (OS X) on the desired objects. Groups can be renamed and carry a little “+” symbol. By clicking on this symbol, the group is either expanded or collapsed.

The “Replace” option makes it possible to choose another external object from your hard disk. Position values are inherited from the old object.

“Tree” is expandable and gives you options for showing or hiding Node’s entries. “Expand All” and “Collapse All” affect groups, while “Show All” and “Hide all” are valid for all entries.

With “Show…” you can selectively hide and show RealFlow’s various node groups, like emitters or constraints.

“Copy name” grabs the name of an activated node to transfer it to another object. The target object has to be made editable with “Rename”. With Ctrl + V (Windows/Linux) and Cmd + V (OS X) the copied string is then inserted. This function is actually meant to transfer parts of a name, since it’s not possible to assign identical names within a scene!

The second menu is similar to the previously introduced “Tree” function and has one different entry, called “Add”. “Add” provides an easy method to rapidly choose from RealFlow’s different nodes and objects, such as emitters, meshes, RealWaves or empty group containers. The option “Add to Global links” is activated by default. This assures that the new object can interact with all the other elements of the current project.

4.04 Node paramsThe Node Params window is dynamically adjusted to your node selection and carries all available parameters and settings. You can also see different submenus, which appear



Introduction | 24

or disappear automatically according to the activated options, e.g. for rigid or soft body dynamics.

u The individual settings, panels and parameters for all Node Params panels are explained in detail in combination with the appropriate objects and their attributes.

To change a certain value it’s necessary to left-click on it to make it editable. Once it’s highlighted, you can enter the desired value. Please note that some parameters have certain ranges, for example between 0 and 1, while others accept almost any value, even negative settings. Invalid settings won’t be accepted and will automatically reset to the previously given value. Most of the parameters under Node Params can be animated. For this purpose it’s possible to set keys or open the Curve Editor which also provides several methods for animation (a detailed explanation of the Curve Editor’s functions can be found on page 242). To set or delete keys and curves, simply right-click on the desired value to open a little menu, showing various entries. Values that cannot be animated won’t show in this menu. Please don’t activate/highlight the values meant to be changed! In this case you’ll see another menu with entries for undo/redo and clipboard functions.

A Node Params sample menu for a square emitter.

Node Params additionally provides an internal help system that can be activated with a right mouse click or the F1 key. The right mouse help is only shown by clicking on one of the main riders.

The F1 help system shows information about the various parameters. Some of these explanations might appear very familiar to you and that’s no coincidence. To give you the best available information, RealFlow’s help system is entirely based on this manual. To activate it, simply click on the desired parameter to highlight it and then press F1.

The result is an explanation of the current property. Together with the new Help Viewer you have a powerful, though easy-to-use, help system that’s seamlessly integrated into RealFlow.

4.05 Global links and exclusive linksThese panels can only be explained together and they also have a very close relationship to the Nodes panel. By default, you’ll see each new object inside the Nodes panel as well as under Global Links. As long as the “Add to Global links” option is active, RealFlow assumes that all items are able to interact with each other. The idea behind exclusive links it that you have the possibility to make certain invisible to other objects. To achieve exclusive links, it’s important to know that you have to maintain a certain hierarchy. This means that you cannot arrange the links randomly, otherwise you’d cut interactions:

• Objects and emitters have to be placed under RealWave nodes• Daemons must be organized under objects and emitters, including grid fluid emitters• Objects must be placed under emitters• Objects must be grouped under other objects

Examples for Exclusive Links with correct hierarchy.



Introduction | 25

Exclusive links are incredibly versatile and useful. You can add various daemons, for example gravity or wind, with different settings and limit their influence to selected emitters. Also the new grid fluid emitters can profit from this concept. Imagine a scene with grid fluid, splash and mist emitters. To create different areas of turbulence, it’s possible to add several wind daemons, with each one responsible for a particular particle source. Without exclusive links, this would be an impossible, or at least a very difficult, undertaking. To make certain nodes exclusive to others, you have to remove them from the Global Links panel and then drag them from Nodes to Exclusive Links. Finally you can group the desired node(s) to the appropriate entry to establish the exclusive connection – this is again done by drag and drop. The Global and Exclusive Links panels also support the right-click menu. It contains functions to hide and show elements either globally or selectively, similar to the Tree function for objects (see page 23).

4.06 Right-click MenusThis type of menu has already been introduced at various occasions, but there are more of these little helpers. Right click menus help you to navigate through the viewports, add objects or call certain functions easily. The mode of operation is exactly the same for all menus, regardless of where they appear.

The most useful one is surely the menu from the viewports – you can see the entire menu tree on the left. It contains nearly everything for a fast and effective workflow. You can manage animation keys, objects or position changes, for example. Since these functions are also part of other menus, they’ll be explained in detail in the appropriate chapters.

The Icon Bar provides a right click menu, too, and with this one it’s possible to filter the symbol sets you want to be displayed, such as scripts or tools. You can access it by simply right clicking the Icon Bar:

4.07 Menu BarThe menu contains a complete list of RealFlow’s functions and features. It helps you to organize your layout, add objects, open windows and determine export settings, and also provides you with tools for scripting and organizing your copy of RealFlow. Additionally you’ll find shortcuts next to the menu entries. Please keep in mind that there’s a slight difference between Windows/Linux and OS X: Macintosh users can see an additional entry, called “RealFlow”. Here they can find all preferences for customizing the software. On Windows/Linux, “Preferences” is located under “File”.



Introduction | 26

a. The File Menu

The “File” menu helps you to organize your projects and call existing simulations, but it’s not responsible for setting up export settings to store simulation results. Please note that this feature is located under “Export”. These are the entries and shortcuts of the “File” menu:

New ProjectYou can close the current project and open the Project Management window.

Open Project...Choose this option for opening an existing project.

Save ProjectSave the current project with menu entry.

Save as...To save the current project with a new name this action is required.

RevertOpens the last saved version of the project.

Open Project Folder...Opens the folder containing the project.

Update SD SceneWith one click you can update a currently loaded scene file, especially after making changes inside the 3D software and writing out a new SD export file.

Summary Info...The function displays information about the total number of nodes and their properties, such as number of polygons, vertices or particles, together with physical parameters of emitters. Additionally you can add a description of your scene that will be stored with the project.

Recent workspaces To get a list with recently opened project files, choose this entry. You can directly access these files without having to open RealFlow’s Project Manager again.

Preferences...This command opens a new dialogue window containing parameters for adjusting general characteristics of RealFlow: Layout, controls and environment parameters, for example. Under OS X this function can be found under the “RealFlow” entry.

u Since the Preferences section contains many important settings for customizing RealFlow, it’s discussed under an own chapter starting on page 45. There you’ll find detailed information about the meaning and influence of the various parameters.

ExitClose RealFlow here. Before the program quits you’ll be asked to save all unsaved changes. In OS X this function can be found under the “RealFlow” entry.

b. The edit Menu

This menu provides functions for your work with RealFlow nodes.

AddAdd opens several submenus containing all kinds of RealFlow nodes. For faster access, the nodes are grouped and can be added directly to scene. RemoveRemove the selected node(s) from the scene.



Introduction | 27

UndoThis action can be repeated to go back several steps, but can also allocate a lot of memory, especially when you undo/redo emitter-based actions with large particle amounts. If the “Undo” option needs too much memory, you should consider freeing it up with the “Clear Undo Stack” function from the Tools menu. RedoRedo the previous action.

MoveSwitches to Move mode. When this mode is active, the selected node shows a cross with arrowheads.

RotateSwitches to Rotation mode. In Rotation mode, the active node shows surrounding circle- shaped handles for adjusting the desired transformation quickly by dragging the mouse.

ScaleSwitches to scale mode and adds cubic handles to the node. By dragging them you can easily adjust an object’s size with the mouse.

CopyWith this tool you can easily copy and transfer different transformation data from one node to another. You need two nodes for this operation – the order of selection determines, which item will be the source object. You can either copy and transfer data individually for “Position”, “Rotation”, “Scale” or “Shear”, or perform all changes together with “Transformations”. The selection doesn’t require nodes of the same type!

SnapAgain, this function depends on the order of selection and requires two nodes. The first object is used as reference. “Nearest side” will bring the two nodes as close as possible together. The “Nearest side (expanding)” tool stretches the target object until it touches the reference node.

Add KeyframeThis submenu consists of four entries. Instead of selecting and keying the appropriate parameter under Node Params > Node, you can also use “Position Key”. It automatically writes keys for the item’s X, Y and Z values. “Rotation Key” works exactly like “Position Key”, but is responsible for recording rotation value. The workflow with “Scale Key” is the same as with “Position Key”. If you want to write animation keys for position, rotation and scale, then you don’t have to do this for each attribute. Choose “Transformation Key” to add keys for all parameters.

Freeze TransformationsLocks all transformation to the current state.

Reset TransformationsResets all transformations to the object’s starting values.

Clone SelectedA clone object is a copy of the current object which gets its default values from the original. This function exclusively works with standard emitters, daemons and objects. Imported objects from SD files cannot be cloned, too.

Back culled selectionIn several cases it’s required to select polygons from an objects, for example for emitting particles. Normally, RealFlow doesn’t differentiate whether the polygons are visible to user or not. With this option enabled, you can only select polygons which are really visible to you and hidden faces won’t be considered.



Introduction | 28

c. The View Menu

“View” provides functions for customizing the viewport windows and various shading modes. It is surely one of the most often used menus during creating and simulating your scene. Please keep in mind that “View” does not manage the visibility of a node. If you want to make an object invisible or visible, you need the according Display panel. The entries of “View” can be seen here:

ElementThis submenu is used to display the currently selected object in one of the following modes: “Bounding Box” is a wireframe box, covering the volume of the object. There are no visible shapes or poylgons, even emitters are displayed as simple boxes. In “Wireframe” mode, only the polygon edges are shown and you can still see underlying objects. With “Flat Shaded” the object shows its faces as shaded polygons. The faces of “Smooth Shaded” objects appear even. Higher polygon numbers create better and more accurate results.

SceneYou can display the entire scene as “Bounding”, “Wireframe”, “Flat Shaded” and “Smooth Shaded”. The specifications for these modes are the same as for “Element”. Additionally, there are “Wireframe back faces” to show the inside of objects when their normals are inverted. “Textured” draws an object’s texture based on its UV coordinates.

Point of View You can change the current viewport view to “Top View”, “Front view”, “Side View”, “Perspective View” and “SceneCamera View”. The last view option is only available with at least one camera.

Reset ViewRedraw the viewport to switch back to RealFlow’s default point of view. Fast ViewDisplays objects as bounding boxes when moving, rotating or scaling. Especially with large scenes and many objects, this is a good means to increase display speed. Even standard fluid particles are drawn as boxes, while grid fluids and daemons are still represented as particles. View GridTurns the grid in the viewport(s) on or off. “On” is the default setting.

View Preview Safe FrameTo make use of this option, a camera is required. After the camera view has been enabled you can see two frames around the viewport. The outer frame is in cyan and exactly matches the camera view, independent of the viewport’s aspect ratio. The inner frame is blue and shows the title-safe area of the current view.

View Preview CaptionWith this option it’s possible to print some basic information about the current scene directly to the viewport. The data are written to in the top right-hand corner and represent your settings under

Preferences > Display > Top Right Caption

There you can enter either your own text or choose from a couple of variables, for example frame rate, frame width or the scene’s name.



Introduction | 29

Follow SelectedDuring animation the currently selected node will always be in the viewport’s centre.

d. The layout Menu

This section provides access to all RealFlow windows and has the following entries:

Save LayoutWith RealFlow you can create your own layouts and interface arrangements and save them to a default folder, specified under Preferences.

Load LayoutTo load a layout from any folder, choose this entry. This is normally used, when there are no entries listed under “Apply Layout”.

Apply LayoutHere you can find a list with all available layouts under RealFlow’s default folder. “Default” resets everything to the initial layout. This configuration is also specfied under Preferences.

The image above shows a viewport without a grid, but with “View Preview Safe Frame” and “View Preview Caption” enabled (the labels are enlarged for better visibility). The preview caption was defined under the previously mentioned Preferences section, using the following text/variables:

Grid Fluid Comparisons @ $(FPS) frames : $(FRAMEWIDTH) x $(FRAMEHEIGHT)

View Screen TextureYou can fit a bitmap into a viewport as a background. If you have several viewports open, it’s possible to turn the loaded picture on or off for each viewport separately. RealFlow doesn’t store the loaded image and it has to be applied with each launch.

Load Screen Texture...Choose a bitmap to load into the viewport as a background. Supported file formats are TGA, BMP, JPG, PNG and TIFF.

Center SelectedCentre the select object(s) in the current viewport.



Introduction | 30

Clean Layout Cleaning a layout means that all menus and panels will be removed and the viewports expanded, filling almost the entire screen. The only remaining elements are Icon Bars, Timeline and Timeline Control. To switch back, go to “Apply Layout” and select a configuration.

Clear MessagesIf you want to get rid of previous notifications in the Messages window, you can call this functions. The window becomes cleared, but the associated log.txt files is concerned in the action. You still have the complete message history stored there, unless you quit and restart RealFlow.

Single ViewLaunches an independent panel containing a single viewport. Quad ViewLaunches an independent panel with four equal viewports.

NodesLaunches an independent Node panel.

Exclusive LinksLaunches an independent Exclusive Links panel.

Global LinksLaunches an independent Global Links panel.

Node ParamsLaunches an independent Node Params panel.

Curve EditorLaunches an independent Curve Editor panel.

MessagesLaunches an independent Message panel.

Batch ScriptLaunches an independent Batch Script panel.

Simulation EventsLaunches an independent Simulation Events panel.

Movie PlayerLaunches the internal Movie player.

Job ManagerLaunches an independent Job Manager panel for network simulations.

Help ViewerLaunches an independent Help Viewer panel for RealFlow’s built-in help system.

“Independent” means that RealFlow opens a floating window that’s not integrated into your current user interface. If you open an already displayed window, it will be detached from the user interface and shown separately as a floating window. The empty space will be replaced with another window.

u The feature set of the windows listed above are explained individually, because many of them offer a wide spectrum of different functions and options.

e. The Tools Menu

Tools provides several useful functions for managing memory and RealFlow issues. Many functions open new windows with extensive function sets, helping you to accelerate workflow or free computer resources.



Introduction | 31

System plugins manager...Displays information about the plug-ins loaded within RealFlow. When this window is open, it’s not possible to access the underlying panels and windows of RealFlow.

User plugins manager...Here you can see all installed 3rd party plug-ins together with some information, like ID and a short description, if available. To get access to the underlying RealFlow GUI again, this window has to be closed.

Clean Data FolderDeletes all particles, meshes, dynamics and deformation files.

“Memory”For managing your computer’s RAM, choose an entry of the associated submenu: “Purge Memory” cleans up memory and frees resources. This function should be called when particles start behaving weiredly or fluid simulations are obviously not correct. Only particle simulations can profit from “Purge Memory”. “Clear Undo Stack” empties the list of currently available undo actions.

u It’s important to know that RealFlow doesn’t free memory by simply removing an emitter from the scene. The particles will remain in your memory to give you the opportunity of undoing this action. This is also valid for other nodes and objects. If you really want to free memory, it’s recommended to use “Clear Undo Stack” after deleting memory-consuming objects. Since memory actions can sometimes lead to instabilities, it’s a good idea to save your files before executing this command.

Particle TooltipThis little tool shows information about an individual particle. To use this function, activate and place the mouse over the particle of interest. After a short while, RealFlow will show a variety of different attributes, for example ID, position or density.

Particle SelectionThis tool allows you to select a particle or multiple groups of particles and perform a variety of actions. When you choose this function, RealFlow will open a window and automatically switch to selection mode. Please note that you can only perform rectangular selections; core particles of grid fluid emitters are not affected. It’s only possible to select standard particles, including splash, mist and foam. Once a selection has been made, click on “Particle Selection” again and perform the desired actions.

To store the current selection, you can click on “Add group” to save your choice. RealFlow automatically assigns a unique name to the group that’s displayed under Selection. With “Rename group” it’s possible to change the current name. An interesting function is called “Freeze-Follow”. With this tool it’s possible to define a group of particles and freeze them. Other particles can collide and react with the frozen ones and create interesting effects. It’s no problem to stop the simulation at an arbitrary point, make a selection, and go on with the calculation. From this certain position on, the particles will be frozen. Please note that frozen particles cannot be released again and will remain steady, even after you have deleted the group.

A custom particle selection. Frozen/selected particles are displayed in green.

The last two fields are for statistical purposes and show the number of particles in the current group. “Delete group” removes a group from the particle selection and “Remove particles” keeps the group, but deletes the included particles.



Introduction | 32

Check for UpdatesYou can establish a connection to Next Limit’s server to check for updates. This option requires Internet access.

License manager...Here you have the possibility to register, manage or re-license your RealFlow copy. With this dialogue you can administrate all your licenses even within a network. It also tells you, for how many network nodes (or individual computers) each license is valid. The “New license” button opens an input field, where you can copy/paste a license. “Remove license” deletes a license from the manager and if you want to use a previously deleted license again, use “New license” and retype it. “Explore network” helps you to find all valid licenses within a network automatically. Close the window when you’re ready.

Measure utility This is a very useful tool which allows the user to examine a selection of geometric values like the surface and volume size for a selected object:

"Selected node” is the object whose properties are shown below. “Units System” gives you the opportunity to choose from Metric, US and Japanese systems. “Surface displays” the surface size and “Volume” prints out the node’s volume size. “Vol Bbox” is the volume of a virtual bounding box that would exactly enclose the selected node.

Create Array This handy function builds a 3D array from the select object. It’s a perfect tool to create a large number of objects within a very short time. It’s also possible to export these nodes as OBJ files for exchange with other programs.

Though the settings are pretty self-explanatory, here’s a brief description:

“Selected node” represents the original emitter or daemon used for creating the array. “Array type” currently only offers “Rectangular”. “Number of items [Axis]” is the number of added nodes in each direction. “Items Distance [Axis]” is used to define the space between items in the array. “Offset from selected [Axis]” again consists of three entries and describes the distance from the original node’s position. This is used to create staggered arrays.

“Use selected node as first item” starts to build the array from this node. “Add to new group” automatically creates a group folder under Nodes and attaches the new items to it.

Generate UuidPlug-ins always need a unique identification number and this functions creates one for you. For this purpose, a new window is opened where you can select the appropriate settings. This function is really only useful for plug-in developers and programmers.

f. The export Menu

“Export” contains everything you need to store, manage and save your simulation data. Here you can also find Export Central – a sophisticated tool to specify file names, image formats, paths and attributes that should be written to a certain file or directory.



Introduction | 33

Export AllWith a single click you can activate all options in Export Central. Particularly with large object numbers this can be a very convenient way to save the desired data.

Export NoneIn contrast to the previous function, this one disables all export features.

Export Central...This command opens the Export central window – RealFlow’s control centre for all kinds of files, export options and simulation data management.

u The Export Central dialogue contains all functions and options to manage your scene and data files within a single window. Since this is a very complex tool, it’s discussed separately, starting on page 55.

Update Time Line CacheSometimes, especially after many changes, RealFlow doesn’t display the previously recorded files in the Timeline. By using this function, all available simulation data will be read from their individual directories, and imported to be used, for example, for playback. RealFlow doesn’t check for consistent simulation files and just loads all available BINs.

File Name Options...This little helper provides several alternatives to customize your RealFlow data files. The first one is “File Name Prefix” and is used to add a custom prefix to your BIN sequences. ”Frame/Extension” order represents the format (syntax) of file names from simulations. “Padding size” is the number of digits that’s used to enumerate the recorded files. To avoid errors this number should always be set to 5.

RealFlow’s file name options dialogue.

RealFlow particle BIN file (single) Sometimes it necessary to export just a single BIN file for testing purposes or as an initial state. Using this function writes all particles positions at the current frame to one file.

Selected nodes as XMLXML is a common format for easy exchange. All currently selected nodes will be written to a single XML file. This files can be read again with an appropriate import function.

Scene as XMLSimilar to the previous function, this option is used to store the entire scene containing all nodes in XML format. “XML” stands for “Extended Markup Language”.

g. The Import Menu

This menu entry provides three functions to access external files and scene data.

Import ObjectOpens the file picker to import one or more objects from SD files or other formats, such as OBJ or DXF. Please note that RealFlow only supports one SD per scene, but you can add more nodes by either importing them as 3DS, LWO or OBJ files, for example, or update the SD in your 3D program and export everything again. UV coordinates will be recognized.



Introduction | 34

RealFlow particle bin file (single)You can also load any available BIN to the current scene.

Nodes from XMLThe XML format is a versatile and flexible file format. RealFlow now supports the Extended Markup Language format for easy data exchange. Nodes, previously saved with “Selected nodes as XML”, can be loaded again with this function. XML files can be edited and changed with any ASCII-capable text editor! In some situations it’s also helpful to export nodes or even entire scenes for backup purposes.

h. The commands Menu

This menu can be used to organize custom and system script files. It contains some complex functions with versatile features.

Add This function provides three options for updating and editing the Scripts Bar. All functions open the Add Script window, which is described a little later on the right. The “Add” submenu contains three entries: “Script” opens the Add Script manager for adding and organizing embedded Python scripts. “Script From File” works similar, but launches the Add Script manager for arranging imported Python scripts. The last action, “Plugin”, calls again the Add Script manager for organizing scripts from plug-ins.

Organize...Opens a window to manage all script types, including DLL-based scripts. The scripts will then appear under User Commands once they’ve been added. You can read more about this workflow on page 35, “The Organize... Window”.

u User scripts normally require at least some basic knowledge of Python scripting to make them run. The complexity of the freely available user scripts varies greatly and there’s no guarantee that they will really work for your special demands. This

is also valid for C++ programs, but there there the programming requirements are higher.Please bear in mind that Next Limit cannot support 3rd party scripts.

User CommandsLets you define certain scripts to act like an integrated function of RealFlow. By default the submenu is empty.

System Commands This shows the included system scripts so that you can call them like integrated functions.

Update MenuIf new scripts are not displayed, we recommend that you use this command.

The add script Window

RealFlow provides the possibility to integrate your custom scripts to the user interface. Once they’re loaded and added to the Scripts Bar they can be used like an internal function, similar to the system scripts (see page 38).



Introduction | 35

If you want to make use of already existing scripts, it’s a good idea to visit RealFlow’s popular scripting page. It contains dozens of programs, created by other users and RealFlow developers. These scripts are free to use and can be integrated into RealFlow. Many of them even contain icons. By the way, it doesn’t matter whether you want to add self-written or downloaded user scripts to the interface. Now lets have a close look at the Add Script window:

The “Name input” field lets you specify a custom name for the script you want to add. This can be any name, but you should avoid double naming! “Edit Script” opens the script editor where you can also load and save already pre-stored scripts. From the “ToolBar” menu you can choose the desired toolbar where the currently edited script will be added to. “Icon...” allows you to choose a custom symbol from your hard disk and the currently used icon is shown next to the “Icon” button. Please note that the best format for icons is PNG. The “Shortcut” menu provides a list of available shortcuts that can be used for calling your script. Simply select one of the suggestions to attach it to the current script.

The script tree contains already existing and loaded user programs to give you an overview. It also shows the current organization of your scripts, including all folders (= groups), the script’s name, the shortcut and its complete path. Here, it’s not possible to edit or organize the scripts – the tree is for information purposes only.

“New Folder” gives you the opportunity to create a new folder to group the scripts and, of course, it’s possible to rename it. If you want to add a script to a folder, choose your settings first and single-click on the desired folder to highlight it. When you confirm with “OK”, the window will be closed and the script will be added to the selected group. The script now appears within the Scripts Bar, showing the chosen icon. “Cancel” closes the window without applying or saving your settings.

u You can also specify user scripts as system scripts. For this purpose the source code needs a so-called header, telling RealFlow that the program has to be attached to the appropriate section of the Scripts Bar. If you’re interested in how to perform such an action, just open one of the included system scripts.

The organize... Window

RealFlow’s (user script) organizer only works if there’s at least one existing user script, otherwise there’s simply nothing to organize. The window contains two sections:

1. The script tree with three columns “Name”, “Shortcut”, “Script”2. The button bar

The empty Organize Commands window.

The script tree canvas should also look familiar to you, because it has exactly the same layout as seen under “Add script”. The difference is that it’s fully editable now. To perform these changes the button bar is used:

“New Folder” adds a new folder to the script tree – you can enter a new unique name for it. “Remove Folder” deletes the selected (=highlighted) folder, but please be careful: By removing a folder you’ll also delete the programs grouped under this folder from the scripts tree and the Scripts Bar. “Rename Folder” lets you enter a new name for the selected folder.

“Change Properties” is used to alter properties, like shortcuts or the desired toolbar for your scripts. “Edit Script” opens a new dialogue, similar to Add script, but without the scripts tree. With this menu it’s not possible to edit the source code, but you can specify a new name, a different path, apply a new icon or replace a script. To apply a completely new script, use the “Add Script” feature. “Remove” deletes a script without removing the higher-ranking folder. “Close” applies your settings and changes.



Introduction | 36

i. The playback Menu

This menu contains functions for creating video previews and controlling the Timeline.For many playback options there are shortcuts available that can be found next to the appropriate command. The shortcut legend is also different for Windows and OS X.

Video PreviewYou can automatically create a video from the active viewport with this function. When the images are completely recorded, RealFlow directly assembles a video and opens it in the Movie Player. Compression settings and preview size can be made under Preferences.

Open Last PreviewIf you have created more previews, you can simply call up the last one without searching.

Open Preview PreferencesThis option directly branches to the appropriate section of RealFlow’s Preferences.

u The following commands only affect Timeline properties not the video preview!

Play/StopStarts or stops the playback of the recorded simulation.

Play/Stop BackwardsStarts or stops the reverse playback.

Loop PlaybackPerforms an endless loop while playing back the simulations.

Beginning FrameJumps to the first defined playback frame.

Previous KeyframeMoves the timeline slider to the previous keyframe.

Previous FrameJumps one frame back.

Next FrameJumps one frame ahead.

Next KeyframeMoves the timeline slider to the next keyframe.

Ending FrameJumps to the last defined playback frame.

j. The Help Menu

Here you can query information about licenses and call internal help functions.

Contents...You can access RealFlow’s internal Help Viewer with this command. The Help Viewer and its versatile possibilities are explained in a separate chapter on page 44. RealFlow’s help system also provides a complete Python scripting reference.



Introduction | 37

Key Shortcuts...Use this function to get an overview about RealFlow’s keyboard combinations, embedded in RealFlow’s help system.

Web...Prompts RealFlow to open your default internet browser and launch the RealFlow website.

License agreement...Here you’ll find the terms of use and copyright notes. Please read the Software Enduser License Agreement carefully, because it contains relevant information about running RealFlow. Python license...The license for the embedded Python distribution can be found here.

Release notes...This is very useful source of information, where you can find all known bugs, for example. If you observe an error, you can first have a look at this panel to check, whether the malfunction is already known or not. If you think the malfunction is really a bug, you can contact Next Limit’s help desk. Additionally, system and hardware requirements are listed here, along with the latest modifictions of the software.

About...The splash screen shows information about your license.

4.08 Icon BarsDirectly below the Menu Bar you can see a series of different icons and symbols. These graphical buttons provide fast access to the most common and often used functions and objects. For better accessibility they’re subdivided into several groups according to their functionality.

RealFlow even gives you the possibility to create your own icons for custom scripts and add them to the Icon Bar. The program provides a total of 10 fully customizable segments, called “UsrToolbar 0 – 9”. The following chapters tell you how to create and organize your own toolbars. Another feature is that you’re able to filter the contents of the Icon Bar. For

this purpose right click into an empty area of the icon bar to open the display filters. You can then enable and disable the desired symbol groups.

a. The File Bar

The File Bar is a set of three icons for basic file operations.

For these functions RealFlow provides shortcuts, too:

Create a new project Ctrl + N (Win/Linux) and Cmd + N (OS X)Open an existing project Ctrl + O (Win/Linux) and Cmd + O (OS X)Save the current project Ctrl + S (Wind/Linux) and Cmd + S (OS X)

b. The edit Bar

This bar contains a total of five icons. With these tools it’s possible to select one or more nodes and change their position in 3D space. These tools work exactly like their counterparts in 3D applications. By holding and dragging the mouse, position, rotation, or scale changes are executed. The fifth icon lets you choose between the global and local axis system.

The four basic transformations are also available via shortcuts:

Select node press Shift or Ctrl/Cmd for multi-selectionMove tool WRotate tool EScale tool R

The first four tools can be used to select nodes from the active viewport or the Nodes panel. The viewports provide another option: Simply draw a virtual rectangle around



Introduction | 38

e. The Transformation Bar

This toolbar is new in RealFlow 5 and provides tools to transfer position, scale, shear and rotation data easily from one object to another. You simply have to select two nodes from the Nodes panel and/or the viewport and click on one of these buttons. The transformation data will be copied from the first selected object to the second one. As you can see, the order of selection plays an important role. The functions are not limited to objects of a particular type – properties can also be transferred from objects to emitters, for example.

Transformations Transfers all available node data to the target object.

Position Copy only the position data with this button.

ScaleOnly the node’s scale information will be transferred.

ShearClick on this button if you want to copy shear properties.

RotationThe current rotation angles are shared.

The second part of the transformation bar concerns snapping. These functions calculate the nearest sides between two selected nodes and snaps them together. The first selected object is the reference and won’t be repositioned when the second node is translated. This mode is especially useful for object dynamics – for example brick walls.

Nearest sideBrings two nodes together as close as possible.

Nearest side (expanded)Stretches the target node until it touches the reference object.

one or more objects to select them at once. The “Select node” tool supports hierarchical selection – ff a node can’t be selected directly from the viewport, because it’s overlapped by other objects, click onto the desired node until it becomes active. Of course, you can select it from the Nodes panel, too.

c. The Nodes Bar

Each icon represents one of RealFlow’s object groups. The order is: grid elements, particle emitters, daemons, objects, meshes, cameras, RealWaves and IDOC elements.

Clicking on an icon will open a list of all available elements. Choosing the desired object from one of the lists, also places the item in your scene. You can repeat this process as often as needed.

d. The scripts Bar

This icon bar contains the so-called system scripts. These are ready-to-use scripts that don’t need further adjustments or programming. You can open and organize these scripts with the Commands Menu, too (see page 34). The system scripts can be used like any other of RealFlow’s commands and they even have shortcuts.

Currently the following system scripts are available: Change resolution, Compute vorticity, Normalize Age, Maya Cache Particle Loader and Build Meshes.

By clicking on an icon the chosen script starts working. Please note that some scripts have certain requirements, e.g. the existence of a mesh node or a particle emitter. Some of these scripts might also appear rather slow, due to the fact that Python-based calculations are always single-threaded. This limitation is not RealFlow-specific, it’s caused by the Python programming language, which supports only one CPU or core.



Introduction | 39

4.09 TimelineRealFlow’s Timeline isn’t just a simple time indicator – it’s a versatile tool that gives you lots of information about a simulation. The timeline slider can be moved back and forth and will let you preview the simulation, but only if the simulation data was cached to disk. In this case, calculated frames are shown in orange.

By default you can also see a range between 0 and 200. This is RealFlow’s standard simulation and playback range, depending on the appropriate preferences. Start and end frames for playback can be changed any time with the fields to the left and to the right of the timeline bar. The second field on the right is used to specify the simulation range

If you’ve imported an SD file for geometry or animation data exchange, there’s always an animation range saved with the file, regardless of whether there are any animated elements in your file or not. This range can be defined by the user in the plug-in’s export settings. In this case, an additional line appears, indicating how many frames were imported/exported with the SD file. Please note that the yellow line doesn’t have any influence on the simulation length! It’s just a visual control of how many frames have been stored with your imported scene.

Another feature of Timeline is the “Lock button” on the left. Beneath this button you can also find a little triangle. By clicking on it, a mini menu is opened, showing some options for locking a simulation:

Locking a simulation means freezing all previously animated transformation or movements. Imagine a filled glass is being poured out – the pouring is animated. The first step would

be to fill the glass. By locking the simulation you can do this for an exactly defined range of frames (= “Frame countdown”). After the glass is filled with particles, you unlock the simulation and the animation can proceed. You don’t have to specify a certain range for the countdown, because it’s also possible to unlock the simulation manually by clicking on the lock button whenever you want it. With this easy method you can save time, because you don’t have to split the simulation into two or more parts – filling the glass and performing the animation. All this can be done within a single file. In other words, locking the timeline prevents RealFlow from exporting any files. This is useful for simulating initial states. After you get the desired result, set the initial state for the emitter and reset the scene, unlock the timeline and simulate as usual. Now it will start from the initial state.

Another very convenient button is “Go to last cached frame”. This directly sets the timeline slider to the last stored frame and so you can directly go on with the simulation.

4.10 Timeline controlThis set of buttons is surely familiar to everyone, as it works exactly like the control field in DVD players or video editing programs. Nevertheless it’s worth to briefly explain the functions:

1. Go to start frame2. Go to previous frame3. Play/stop button for reverse playback4. Frame counter / “Jump to frame” input field



Introduction | 40

film formats. Please note that there’s a connection between “FPS Output” and “Time Step” – “Time Step” can easily be used for re-timing or slow-motion effects.

RealFlow’s Simulation options allow you to adjust simulation settings for each project.

Please have look at this example:You enter an “FPS Output” value of 75 and simulate the scene. Once it’s ready you import the simulation data into your 3D application, you set the internal playback rate to 25 and render out everything. The result is a movie that’s played back at just one third of the original speed from RealFlow. In other words, you’ve stretched time by a factor of three.

“Threads” is also connected to RealFlow’s preferences and adjusted automatically. However, for simulations with lower particles counts, it’s often better to reduce this value. The reason is that distributing simulation data to different CPUs or cores takes a certain amount of time and this process can take longer than the actual calculation step. “Use max. threads” always simulates with the maximum number of processors.

The “Integration” section can be described as RealFlow accuracy. The more time steps, the

5. Play/stop button for normal playback6. Go to next frame7. Go to end frame8. Loop playback sequence

The Play/stop function can be triggered by pressing the space bar, too. You can also jump to the start of the simulation with the left arrow and to the end with the right arrow. With the up and down arrows you can count back and forth frame-wise.

4.11 simulation controlThe Simulation button triggers a simulation. During this process RealFlow performs all of the necessary calculations, generates the data files and writes them to disk. The simulation itself obeys several settings that can either be defined globally with Preferences (see page 46 and 47) or individually for each scene. For adjusting the settings per scene, simply click on the little triangle to expand a new menu.

There are three entries: “Fluid Dynamics” and “Object Dynamics” switch the appropriate simulation engines off or on. By default, they’re activated. The “Options...” part is probably of higher interest, because there you’ll find all simulation-related settings.

The parameters you can see under “Options...” are the standard values from RealFlow’s preferences. They can be overwritten to increase or decrease the defaults for the individual needs of your current project. It’s recommended to determine the settings under preferences globally and then alter them with “Simulation options”.

“FPS Output” can be used to either adjust the frame rate to your local TV system or a certain cinematic frame rate. RealFlow’s standard “FPS Output” is 25 frames per second for PAL. You can enter any desired value, for example 30 for NTSC or 24 for HD, or other



Introduction | 41

these modes are fast and perfectly suited for previews. The second button is “Reset” and by clicking on it, the entire scene is reset to the initial settings and positions. Without having specified a start frame (input field on the left of the time line), the simulation will begin from 0 again, otherwise the first frame is the manually defined start frame. If you have entered a frame, e.g. 30, then the first 30 frames will appear in orange, though nothing has been simulated so far.

Next to the “Reset” button, you’ll again find an expansion menu with “Reset To Initial State”. By activating this option it’s possible to read from a previously simulated and saved initial state (which can be compared with a preset), and start the simulation using these particular settings.

An example: RealFlow fluids always carry a certain amount of energy, making the particles bounce and jitter. This motion can be removed by allowing the particles to settle down. Once the fluid is calm, you can define a certain frame as an initial state and resume from this position without creating an extra scene. You can read more about initial states on page 69.

The third element of the simulation controls is the progress bar. During a simulation or a meshing task, RealFlow displays the progress for the current frame in percent, so the range goes from 0 to 100.

4.12 Miscellaneous ToolsThese buttons are new in RealFlow 5 and contain a set of often-used functions. The annotations below explain these buttons from the left to the right:

better and more precisely the simulation will turn out. You can choose between “Adaptive” and “Fixed”. The adaptive method automatically calculates the best number of steps within the specified range between “MIN and MAX substeps”. “FIXED substeps” can be very accurate, but greatly increases simulation time. Interactions between particles and objects especially profit from higher substeps, because they improve collision detection.

With low substep settings (right), collision detection might fail.

A value of 75 substeps is a good average and suitable for many scenes. For testing purposes, values between 10 and 25 are often enough, while final simulations are mostly calculated around 100 “MAX substeps”. If you need more precision, it’s sometimes better to raise “MIN substeps” than to alter the maximum number.

It’s often necessary to work with higher “FPS Output”, as in the example above. In these cases you’ll most probably receive an error message, telling you that you that your “Choice of MAX substeps is too large”. The reason is that it’s not possible to subdivide a scene arbitrarily and there’s a limit. Fortunately, the error message directly tells you the maximum substep you can use for the current settings.

The last entry concerns rigid and soft body dynamics. From the “Quality” menu you can adjust the solver’s accuracy within three levels: “Low”, “Medium” and “High”. With “Low “and “Medium” you might observe interpenetration problems or inaccurate collisions, but



Introduction | 42

“Build mesh” is used to create a mesh for the current frame. You don’t have to go to the mesh container’s settings any more to build a single mesh. Instead you can click on this button. Of course, there has to be a mesh object with at least one linked emitter available.

“Scale options” provides a window containing all methods to set RealFlow scales. With RealFlow 5 you have the possibility to set different scales for for geometry and daemon forces. You can now scale forces independently for particle fluids, grid fluids and objects.

“Visualization level of detail” is another new feature. With this option you’ll be able to define the quality of the displayed elements. You can choose from several levels – from “Draft” to “Best”. With “Off” you can disable this feature. It’s important to know that the adjusted level of detail is only used during the simulation process. Once you stop and play back the cached information, everything’s displayed independently from these settings.

“Send to job manager” is a tool for simulating non-interacting standard fluids, including splashes, foam and mist, on several machines independently, to speed up the simulation process. The Job Manager works together with the new IDOC nodes (see page 225).

“Go to the previous keys” helps you to jump to the key to the left of the timeline slider with a single click.

“Go to the next key” works exactly as the function above, but jumps to the key to the right of the slider.

“Set key“ provides an easy method to set keys. By choosing either “Position Key”, “Rotation Key”, “Scale Key” or “Transformation Key” you can quickly set the appropriate keys.

4.13 MessagesThe Messages window is your source for all of RealFlow’s notifications. There you’ll find error messages, notifications about saved or opened projects, time steps, or debug information from Python scripts. With Python it’s even possible to print out customized messages or values directly to the Messages window and this option can help you to monitor the results of a script. But please be aware that writing out text to the Messages window can slow down RealFlow significantly.

4.14 curve editorWhenever you’re dealing with animation inside RealFlow 5, there comes a moment when you have to work with animation paths and curves.

The completely reworked Curve Editor now provides sophisticated functions and features to make this job much easier than before. Additionally, the Curve Editor is a powerful function generator for expressions. With expressions it’s possible to define custom functions, which will be used for a node’s animated property. The big advantage with expressions is that you don’t have to set a single key, because everything is based on mathematical formulas. The new Curve Editor now even gives you the possibility to mix keyed curves with expressions.

u Since the Curve Editor is an important part of RealFlow 5, it’s described in detail, starting on page 242.



Introduction | 43

Batch Script can be integrated into a customized layout. Additionally you have a menu bar with several entries. Please also go the scripting section for detailed information about their functionality.

4.17 Movie playerThis is a completely new element in RealFlow 5, and can be used for playing back preview sequences – not complete videos, although it’s possible to export a video out of the application. The Movie Player itself works like any other player and show similar elements. To attach it to the layout, just grab the the windows headline area (“Movie Player”) and drag it to the desired place and save the layout.

4.15 simulation eventsSimulation Events substitutes the Events Script window from RealFlow 4 and provides a much more comfortable and well-structured tree view. By expanding the individual branches, you have access to the pre-built simulation events and you’re able to add your own scripts there. Since Simulation Events is a regular part of RealFlow’s GUI, it provides the same control elements as any other window. It can also be integrated into a custom layout.

u Scripting is also a fundamental part of RealFlow and you can learn more about using Python in RealFlow’s scripting guide, starting on page 268.

The window itself consists of two parts. The first part contains the tree view, and possibilities to add and edit events-based scripts. To access these functions, simply right click on the desired predefined functions, for example “Simulation Pre”. The second part contains a so-called “Master” tab and it’s mainly there for compatibility purposes when you want to make use of RealFlow 4 scenes containing scripts. This window still shows the “old” notation with built-in function for various simulation steps. Another tab is empty, by default. If you you choose a script from the tree in the upper section, its source code will be shown here and, of course, you can edit it.

4.16 Batch scriptBatch scripting is a very convenient method to automatize repetitive tasks, such as creating object arrays, randomizing various parameters or starting multiple project files for overnight simulation. There are many possible fields of application for this kind of scripting and it’s even possible to start scripts with command line simulations. By default it’s nothing more than an empty window.

The Batch Script panel works like a text editor and has some basic features like tabbing, syntax highlighting and keyword completion. Of course you can copy/paste scripts from other sources to the Batch Script window.

u You can learn more about batch scripting in RealFlow’s scripting guide, starting on page 271.



Introduction | 44

The main part is the canvas, which is empty by default and shows the label “No sequence loaded”. Directly below there’s the timeline, showing the number of available frames. You can easily scrub though the frames by dragging the slider. If you want to restrict playback to a custom range, then you can enter a start and stop frame in the fields next to the timeline. The “L” button turns on the loop function.

Checking the “Fit” button adjusts the video to the canvas. In this case the currently loaded video appears downscaled or cropped. By default the video is displayed 1:1 and therefore the borders might not be visible. You can resize the player by dragging its edges.

“Skip” is used to guarantee a smooth playback. By activating “Skip”, some frames might be dropped to guarantee playback at the adjusted frame rate.

With the folder symbol you can choose a previously recorded file sequence and load it to the player. Once the images are buffered, playback starts automatically. The next symbol provides a function to export the sequence as a video. You can also set this option as a default under Preferences (see page 51). When you want to store a video, you’ll be asked to choose a video format. Please note that the selection of video formats strongly depends on your operating system and the installed codecs.

The following buttons work exactly like their counterparts in the timeline control section. You can start playback or jump to the beginning/end of the sequence and go through the clip frame by frame. The last button clears the canvas. Finally, you can specify the frame rate for playback. This field is connected to RealFlow’s Simulation options (see page 40)

4.18 Help ViewerUnlike in previous versions of RealFlow, the help system is now an integrated part of the user interface. Since adequate explanations of functions and parameters are essential, RealFlow’s internal help has been vastly improved and extended. The entire help system is based on the manual and can be subdivided into two parts:

• The F1 help. By selecting a certain parameter under Node Params and pressing F1, you’ll get the appropriate help text for this particular function. RealFlow’s F1 help is directly connected to the Help Viewer: Below an explanation you can find a link, named “Search in help...”. This function automatically performs a search through all help documents and prints out the appropriate results.

• The Help Viewer. This is an extra window and can be seen as a kind of catalogue. You can navigate through all of RealFlow’s functions by navigating through a clearly arranged tree menu, use the index function or perform a quick search through the available documents.

The Help Viewer’s menu tree includes information about all available nodes. You can expand and collapse branches of this tree and by clicking on one of the topics, the help contents will be displayed. A very user-friendly feature allows you to stack documents with the help of tabs. You can open, close and manage these tabs as required, to provide fast access to frequently-used pages or explanations. To add a new tab, simply right click on the desired keyword and choose “Open Link on New Tab...”.

Under “Index” you can find a complete alphabetical list of RealFlow’s parameters. This feature is useful when you’re looking for a certain parameter, but currently don’t know where it’s located. Instead of the “Index” you can, of course, use the search function.

RealFlow’s help search is not a simple keyword look-up. It’s a sophisticated dynamic search function with many options for finding words, expressions similar to your query, and even Boolean functions, e.g. with or without a certain word. These functions are located under “Advanced search.”



Introduction | 45

5 aDJUsTING RealFloW pReFeReNces

The Preferences window is a comprehensive tool for adjusting RealFlow to your special needs. These adjustments not only influence RealFlow’s look and feel, they also have a very strong influence on simulation speed. You can control almost anything and tailor it to your personal taste or maximum performance. The window is classified into several panels according to their particular function. Though some of these setting have a global impact, they can also be changed individually for each scene, for example “FPS output” or “MAX substeps”. To open the Preferences window, please choose

Edit > Preferences... (Windows/Linux) or RealFlow > Preferences... (OS X)

The window consists of two parts. The left part is a menu tree with all available sections and you can open each one, by simply clicking on it. The appropriate contents are then shown in the right section.

5.01 General“Scenes Folder” contains the path to RealFlow’s default directory where all scenes are stored. Whenever you create a project, RealFlow links to this directory. With “…” you can easily define a new location, while “Default” resets to the standard folder. If the environment variable RFSCENESPATH is defined in your operating system, the scenes folder is always updated with this variable ignoring the user preference.

“Axis setup” is a very important setting and has to be adjusted to your 3D software package. The idea behind this menu is to choose the correct height axis setup to avoid flipped or mirrored objects. This setting also affects many height-dependent Python scripting commands. You can select from these options (the first letter indicates the height axis):

• YXZ Lightwave, cinema 4d• ZXY 3dsmax, maya• YZX xsi, maya, houdini

“File cache” is the amount of RAM that’s reserved for playing back your simulation data. The individual files can grow rather big, depending on the number of particles or polygons, slowing down playback speed. With higher settings playback can be accelerated.

“Geometry” scale is another parameter for adjusting RealFlow to your 3D package. Since different programs work with different scales, this scale type has to be represented in RealFlow’s workspace. These are the standard scales:

• 1.000 Maya, XSI, Houdini, Lightwave• 0.010 3DStudio Max, Cinema 4D

1.000 means that there is no transition and the imported objects exactly share the same scale as RealFlow’s internal nodes. Objects from 3DStudio Max and Cinema 4D are 100 times bigger than RealFlow’s native objects. This is also important for exchanging RealFlow projects between users working with different scene scales. Scale is also connected to the viewport’s grid. One grid element has always a size of 1.0 m x 1.0 m, independent from the currently adjusted scene scale value.



Introduction | 46

“Daemon force scale for particle fluids” is a very nice option, because instead of adjusting all daemons of a scene individually, it’s much easier to scale them globally. Since standard fluids, grid fluids and objects are affected differently by forces, you can change them independently. Global settings are made under Preferences, while project-based adjustments are done with the “Scale options” button (see page 42).

“Daemon force scale for grid fluids” works actually the same way as the scale option for particle fluids, but only affects the new grid fluid particles.

“Daemon force scale for objects” only affects the forces for rigid or soft bodies, regardless of whether they’re imported or native.

Scale is certainly one of RealFlow’s core concepts, because it greatly affects your simulations and calculation times. Scale is also very important for the credibility of simulations and can be used to compensate for problems with either very large or very small objects. You can read more about how to use different scales on page 15 and the following.

“Max. Frames” is related to RealFlow’s timeline. The given value of 200 is the standard end frame for simulations and playback. “Max. Frames” can also be changed individually for each project directly within the timeline. This setting is stored with the project and it’s not necessary to overwrite the default “Max. Frame” value each time the scene’s opened.

“Number of decimals” specifies the precision of the parameters. In most cases, it’s enough to work with 2 decimals. Parameters like position or rotation, offer even higher precision by default, without changing “Number of decimals”. You can enter any integer number between 1 and 5.

“Warning level” lets you choose between normal warning and error messages, and expert style notifications.

The “Undo” checkbox enables/disables RealFlow’s undo function.

“Stack size” is the number of possible undo actions. Undo can be a very RAM consuming task. Especially with very large scenes or enormous particles amounts, lots of RAM might be allocated, reducing RealFlow’s performance. In this case it’s a good idea to free memory (see also page 31) by using

Commands > Memory > Clear Undo Stack

“Font...” lets you determine the global font type for RealFlow’s layout. You can choose from any font installed on your system, though some fonts aren’t very practical, e.g. Times New Roman or handwritten styles. For better readability it’s recommended to use sans-serif fonts. Good examples are Arial, Helvetica, Verdana or Tahoma.

5.02 simulation

“Time Step” can either be set to “Adaptive” or “Fixed”. It’s recommended to stay with “Adaptive”, but if you observe problems with interpenetration it’s also possible to simulate a scene with fixed substeps. The “Fixed” option is normally more time consuming. “Time Step” is also an option that should be defined globally under Preferences and locally for each project under “Simulation options”.

“MIN substeps” are only available with “Adaptive”. By increasing this value, the simulation becomes slower, but the level of accuracy will increase and unstable simulations might



Introduction | 47

become stable. If you observe problems, it’s better to try again with moderate “MIN substeps” around 5 to 10. If the errors still persist, slightly increase this value.

“MAX substeps” are also limited to “Adaptive”. Low “MAX substeps” values accelerate RealFlow’s calculations, but at the expense of accuracy. In some cases, collision detection between particles and objects might fail due to low settings.

“FIXED substeps” becomes accessible with the “Fixed” option and subdivides a simulation into a defined number of calculation steps.

“FPS Output” normally only needs to be set once and changes should always be made under “Simulation options” (see page 40). The default value is 25, suitable for the PAL format.

“Threads” is adjusted automatically and normally equals the amount of detected processors or cores. Please note that RealFlow does not always use the maximum number of processors or threads, because this strongly depends on your scene. There are simulations which are better suited to multi-processor calculations, for example, projects with very large particle amounts. Other cannot completely utilize a computer’s power and therefore the processor load appears reduced. With RealFlow 5 many processes became multi-threaded, for example daemons and the new object dynamics solvers.

There’s also a single-threaded process: Python. Whenever you run a script inside RealFlow, only one CPU or core is used. That’s a principle matter of the Python programming language, not RealFlow, because Python can only support one CPU. Plug-ins, written in C++ can handle multiple processors.

“Processors” shows the number of installed processors/cores of your computer. Understandably this entry cannot be changed.

“Use max. threads” can be checked to always use the maximum number of possible threads, though it’s much better to specify this with each scene individually. Especially scenes with low particle counts can simulate faster with lower thread settings.

For the new rigid and soft body solvers there’s only one setting. Under “Quality” you can choose from three different levels: “High”, “Medium” and “Low”. Please keep in mind that this parameter can also be adjusted individually for each project under “Simulation options.” Object dynamics simulations no longer depend on “Time Steps”!

5.03 Display

“Grid size” determines how many cells are displayed with the viewport’s grid. By default you can see a square consisting of 100 x 100 subsidiary squares. The number of these squares can be adjusted with this setting. The Viewport grid is very important in terms of estimating relations and gives you a very good impression about the real dimension of your objects and scene elements.

“Square size” defines the side length of each subsidiary square. By default one square equals exactly 1.00 x 1.00 meter. By choosing higher values, the grid becomes bigger, while values smaller than 1 lead to downsizing.

“Bolder lines at” introduces a subgrid and by default you can see stronger lines each 5 units. To change this raster, simply enter a new value to increase or decrease step size.

“Scene lighting” tells RealFlow how many light sources are used for shading. This is only



Introduction | 48

important for flat shading and smooth shading. Two lights need more CPU time and can slow down simulation or update time for displaying all elements, but are more appealing.“Back face culling” actually only affects polygon selection. In some cases it’s required to select an object’s faces and with this option enabled only the polygons, visible to the user, can be selected. Hidden faces won’t be considered.

“Variable particle size on display” is used to achieve a perspective effect. Particles closer to the camera are shown as bigger then those far away.

“Display at frames” means that the viewport is updated each frame while simulating a scene. If it’s turned off this happens within each simulation cycle. A simulation cycle is the range between the first and last frame that’s displayed in the timeline. This option can substantially reduce simulation time.

“Background color” is used with the viewports only. You can choose any available colour by defining the appropriate RGB values. The default background colour is pure black: Red (R) 0 Green (G) 0 Blue (B) 0.

“Grid colour” has default RGB values of R76 G58 B28. As with “Background colour”, any RGB combination is allowed.

“UI color scheme” lets you choose between a “Light” and a “Dark” interface. Just select the one you like better.

“Display info” is responsible for all information about existing nodes shown at the left of the active viewport window. You can activate one of the following modes: “None”, “All nodes” (default) and “Selected nodes”.

5.04 Backup“Auto Backup to FLW” has to be activated if you want to create automatic backup copies of a project's current state. It’s strongly advised to check this option, because due to its complexity, RealFlow may become unstable under certain circumstances. To prevent a loss of data, “Auto Backup” is highly recommended. Please note that only the FLW file is copied, not the simulation or data files!

"Auto Backup to XML" provides another, more convenient way to prevent data loss. XML files have some clear advantages in comparison to the first method:

• Saving time for XML files is almost zero, even with the most complex scenes.• The size of the generated files is much smaller than with the FLW format.• XML files are not affected by version incompatibilities.• XML files are more reliable and can be read/edited with any text editor.

“Mode” can be used to either write backups within a timeframe per minutes or frames. Very large files need a some time to become written and can slow down RealFlow.

“Every” is related to “Mode”. It indicates the time period that will pass until the backup file is written, for example each 10 seconds or frames.

“Number of Files” determines the number of backup files written to disk within the specified timeframe. You should store at least two files.



Introduction | 49

5.05 Notify

“Active” must be turned on to keep you updated about the competition of a simulation by sending you a notification mail. Of course, you need an active Internet connection to make use of this feature.

“eMail Address” is the mail account that’s used the automatic notification. “Frame Step” specifies the number of frames that have to be calculated before RealFlow sends an e-mail to you. This is especially interesting during critical simulations.

u RealFlow’s notification system uses a SMTP server for delivering e-mails. With Python scripting it’s possible to access the SMTP and send custom notifactions to your mail account.

5.06 script

“Default” indicates the standard path to the directory where you want to store your custom Python scripts. Each time you want to load a script, RealFlow will guide you to this location. With “…” it’s possible to specify this path and “Default” restores the standard path.

“File” contains the path to the “commandsOrganizer.dat” file. This file contains paths and icons for your custom scripts and is used with RealFlow’s Commands menu. Again, “…” is used to edit the path and “Default” loads the standard settings.

“Auto Suggestions” monitors your input and recognizes Python keywords. Once RealFlow has found such a keyword, a list pops up containing all available and matching commands. You can select the desired instruction and the keyword is completed automatically.

“Insert Function Signature” is closely related to “Auto Suggestions”. With this option enabled, RealFlow prints out the required data type(s) for a Python command, e.g.:



Introduction | 50

getCamera( string ) or setVelocity( vector )

The data type is printed in brackets and will be substituted by you with an appropriate entry:

getCamera( "SceneCamera01" ) or setVelocity( Vector.new(1.0, 0.0, 0.0) )

Without “Insert Function Signature”, the brackets would be empty, assuming that you already know which data type you have to enter. To find out more about this topic, please read the scripting manual, starting on page 268.

“Auto Syntax Checking (slow)” allows you to control the syntax of a script while writing it. This, of course, requires a certain amount of system resources and can therefore slow down performance.

“Script editor look and syntax highlight” provides a “Customize...” button to open a new window where you can specify all settings for the scripting windows look and feel, and especially syntax highlighting colours, as well as “Tab Size”.

5.07 export“File Name Prefix” allows you to enter a custom character combination or name that will be added in front of any particle file.

“Frame/Extension order” offers a selection of 4 options:



Introduction | 51

• name.#.ext• name.ext.#• name#.ext (default)• name_#.ext

“name” stands for the particle source’s name, e.g. Circle04 and “#” is the current frame. “ext” is the abbreviation for extension, for example BIN or GDC.

“Padding” defines the format for frames (#) within a filename. Each frame will be prefixed with leading nulls to establish a five-digit number, for example 00004 or 00212. A complete file name would look like this: Circle04_00026.bin

It’s recommended to leave the default setting of 5, because some 3D programs and plugins have trouble reading files with different paddings. In these cases it’s probably not possible to import simulation data.

5.08 preview“Size” offers a wide range of often used standard resolutions. Simply choose the desired preset and RealFlow automatically adjusts the related “Width” and “Height” values.

“Keep Aspect Ratio” is used to keep a certain aspect ratio based on the current setting under “Width” and “Height”. With this option activated you can either enter a custom “Width” or “Height” value and RealFlow automatically completes the second value.“Width” is the width of the final video measured in pixel. The default value is 640.

“Height” is the height of the final video measured in pixel. The default value is 480.

“Ask Movie Path Before Preview” gives you the opportunity to store the final video to a custom location instead of RealFlow’s standard directory.

“Ask Frames Path Before Preview” helps you to find a location for storing the individual files from the image sequence that’s used to generate the final preview video.

“Generate Video” can be used to directly write a video file with a certain codec. This video will be saved under the project’s default preview folder.

The “Codec...” button lets you choose your favourite video compression method to save disk space and allows smooth playback. The list of available codecs strongly depends on your operating system and its installed components.

u Please note that Next Limit does not provide any codecs with RealFlow and only reverts to already installed compression methods, e.g. H.264, MPEG2 or other formats.

“Open in a new Movie Player” directly loads the freshly generated video to RealFlow’s movie player window. If this window isn’t already part of your layout, it’ll be opened automatically.

“Shell Command” can be used to define commands directly on an operating system level to specify certain aspects of the final video. The associated “Variables” button offers a drop down menu with available commands. It’s possible to add more than one variable!



Introduction | 52

“Save image sequence” allows you to permanently store the temporary frames. Without this option they’ll be deleted after the video has been generated.

“Top Right Caption” gives you the opportunity to create your own viewport label by choosing one or more entries from the associated “Variables” button list. The caption can also be combined with your own text. Selected variables are listed in the empty field next to the input field. An example is given on page 24. To show the label it’s necessary to activate this feature under:

Menu Bar > View > Show Preview Caption

5.09 layout“Layouts Folder” is the path to different included or customized layouts. With RealFlow it’s possible to adjust the user interface to your needs and store these settings. Layouts

Folder points to this directory. The “…” button is used to change the default location, while “Default” restores the initial settings. If the operating system’s environment variable RFLAYOUTSPATH is defined then the layout is always updated with this variable ignoring your own settings.

“Default Layout” contains the path and file name of the custom standard layout that’s applied with each start of RealFlow. RealFlow jumps back to the layout specified here and reverses previously made changes by choosing

Layout > Apply Layout > Default (the first entry in the list)

5.10 curves“Enable tooltips while dragging control points” shows the exact position data of a key. The first value indicates the current time, the second one the value of the appropriate



Introduction | 53

attribute. With “Horizontal and Vertical Snap Radius” you can easily drag the control point to the desired position.

“Break tangent by default” will always break a control point’s tangents. Breaking tangents allows the manipulation of the in and out tangent handles individually. You can then edit the curve before or after a key without affecting its opposite handle. Tangents are only available for certain key types.

“Add expression to the spline by default” will always combine expressions with already existing animation curve. This action can also be performed directly in the Curve Editor with the “+” button (see page 253).

“Horizontal Snap Radius” helps you to exactly position keys in the Curve Editor’s Graph window regarding time and value. Without snapping it’s always difficult to drag a control point to a value like 1.000 or 25.000. This setting manages snapping for the time axis. “Vertical Snap Radius” works exactly the same way as its horizontal counterpart, but controls the snapping radius for the value axis.

“Default Node Type” determines how the tangents of a key are treated:

• “Tcb node” is the default mode. It’s similar to Bezier, but the curve’s shape is not controlled with tangents, but rather with fields, like tension or bias.

• “Bezier node” uses adjustable tangents to control the shape and smoothness of the curve.

• “Linear node” simply draws lines between the control points. The result is a zig-zag curve without smooth or curved parts.

• “Stepped Node” specifies a stepped tangent to create a curve whose outer tangent is a flat curve. The curve segment is flat (horizontal) and the value changes at the key without gradation.

5.11 Job Manager“Name” shows the name of the currently loaded Job Manager plugin.

“Select Plugin...” opens a new dialogue to select the appropriate plugin that’s essential for getting the job manager ready. All available extensions are shown in a separate window.

“Manager Location” simply specifies the IP address of the computer, where the Job Manager is running. Any machine can host the server and this doesn’t have to be the fastest computer in your network.

“Port” is important for all network applications. You can, of course, specify any available port, but you have to make sure that it’s not already occupied by another application. There are a few standard ports that should never be used, because they’re required by core daemons of your computer. Please have a look at the documentation or help system of your computer, to find out the unused and open ports. Some networks use firewalls or routers to protect and restrict external access. If you’re behind such a device it’s often necessary to open the port, used by RealFlow’s Job Manager, there as well. If the appropriate port is not unlocked, network simulation fails.

“Apply Path Translation Rules” helps you to avoid problems with non-uniform path notations. Different operating systems use different notations for paths, e.g. the backslash or the colon. By checking this option you can activate the specifications defined under “Path Translation Rules...”.



Introduction | 54

“Path Translation Rules...” opens a new window where you can create your own rules. The window is subdivided into four fields for the prefix used by RealFlow and the according delimiter symbols for all supported operating systems. You can specify more than one rule set by clicking on “Add Row”. This action adds another set of fields. Within the fields you can simply enter the desired rules, for example. If you’re working with a homogenous network, it’s (normally) not necessary to define translation rules.

“Delete temporary files if success” is activated by default. With this option turned on, the Job Manager automatically deletes all temporary files that were create during the network simulation process. It’s recommended to keep this function active, as long as you do not really need these files.

“Default URL” shows the path to the Job Manager’s web interface. This interface is a mini web server with a user-friendly front-end, giving you all required information about available machines in your network and currently running jobs. You can change “Default URL” by simply adding a new path, but please keep in mind that this path must really exist.

u You can read more about the Job Manager’s mode of operation and how to create path translation rules, starting on page 228



Introduction | 55

6 THe expoRT ceNTRal WINDoW

Export Central is a versatile tool for managing your entire project structure. Though it’s a complex and multi-featured tool, it’s easy to handle and provides a rich set of data and file formats. Within Export Central you can specify almost everything regarding location, naming and attributes of your simulation data. By simply activating and deactivating export options with a mouse click, you have full control over the entire amount of files being written. For most of RealFlow’s objects, Export Central even provides more than one file format. The Export Central dialogue can be accessed via

Export > Export Central... or F12

By default RealFlow assumes that each new object in your scene is meant to be exported. Therefore new nodes are automatically activated in Export Central and theoretically you don’t have to think about this process anymore. But, Export Central has so many features that it’s worth taking a very close look at this window. To give you a better overview, this chapter is subdivided into several parts, according to RealFlow’s internal objects.

u Large data files and multiple exports can significantly slow down RealFlow. Think carefully about which data types you want to store and always try to minimize the amount of exported files as much as possible. It’s worth double-checking if a certain data type is really needed for processing simulation results!

6.01 General structureExport Central is a so-called modal window. This means that underlying elements of the user interface cannot be accessed as long as the window is open. In the first view you can see two main sections:

1. The node tree2. The button bar

The scene tree is dynamically updated whenever a new node enters the current scene.

Each object, emitter or mesh is added to the scene tree and gets its own settings. The different symbols already indicate the various object groups available and care for a visual support, making it easier to find the appropriate item. This layout will be used later to introduce and explain the file formats that can be stored with an object.

RealFlow’s Export Central dialogue with node tree and button bar.

You can differentiate between these branches:

Particle Emitters Includes traditional particle sources (with splash and foam).Grid Emitters Contains the export options for grid emitters.Grid Domains Here all currently available grid domains are displayed.Grid Mists A project’s mist domains are listed here.RealWave Options for RealFlow’s built-in wave generator.



Introduction | 56

Cameras Specifications for RealFlow cameras.Daemons Color Plane is the only daemon that can be stored.Objects Carries all solid objectsParticle Meshes (ST) Provides functions for storing RealFlow’s standard mesh type.Particle Meshes (RK) Select the export options formats for the RenderKit mesh type.Grid Meshes The files for grid fluid meshes are managed here.Job Files Files for network computing are specified here.Log This branch shows the log file export option.Preview This branch allows to enable/disable the preview functions.

Whenever a new object is added to the current scene, it’s grouped to the appropriate group and listed below. In this case, the branch shows a little “+” or “-” symbol to expand or collapse the section and provide access to the desired item.

The button bar on the right of the Export Central window is a very convenient facility, especially with large numbers of objects. With the different buttons it’s easy to establish a fast workflow and activate/deactivate export functions simultaneously.

Update Time Line CacheUse this button to reload all previously simulated data from the hard disk and load them into the cache for playing back or resuming simulations

File name options... It directly opens the file name dialogue that’s also located under “Export”. You can adjust file names without closing and reopening Export Central.

CleanThis useful function helps you to selectively clean your data folders directly out of RealFlow. It’s easy to use: you just select a data format, for example “Grid cache (.gdc)” from the “Grid Domains” branch and highlight it with a single click. Now, the “Clean” button becomes active. When you click on it, RealFlow asks you if you’re really sure you want to delete all the GDC files from the related folder. If you want to do so, confirm with “OK”. Please note that this action cannot be undone and the files are lost.

Open FolderIt’s often required to check a folder and its files. This function allows you to directly jump to a certain directory without browsing through the entire hard disk. To use it, click on the desired resource, for example “Grid cache (.gdc), and press “Open Folder”.

Export NoneThis is a real time saver, because it deactivates all options for existing nodes in one pass.

Export All...is just the opposite of “Export None”.

All objectsWith this feature you can activate the default export options for all objects and solid bodies.

All meshesIt’s used to activate the default export options for all meshes.

All particle emittersYou can activate the default export options for all standard particle emitters here.

All grid emittersIf you want to activate the default export options for all grid emitters, except mist, click on this button.

All grid domainsTo activate the default export options for all grid domains, that’s the right place.

All mistsIt lets you activate the default export options for all grid-based mist emitters.

DoneWhen you’re ready, close the dialogue and confirms your settings. Instead of applying your actions, you can close Export Central and discard everything with the ESC key.

6.02 scene Tree optionsThe scene tree shows four columns: “Export”, “Name/Prefix”, “Option” and “Path”.



Introduction | 57

connections between the nodes and the saved simulation files. If you decide to use Export Central’s renaming options, never apply special characters, such as §, $, % or &! Here’s an illustration of the previously discussed workflow:

Now let’s go on with the explanation of the node tree’s columns:

“Option” must be double-clicked to make the different selections available. It’s mostly used for choosing alternative image formats. With particle sources you can also determine the quality level for proxy files. To show the options, double-click on the entry, too.

“Path” lets you determine the location where a data sequence will be stored. By default, RealFlow provides a series of folders where all files are written to (see page 18 and 19). In some cases it might become necessary to create more folders to store different versions, for example. You can see the following notation:

($SCENEDIR)

“$SCENEDIR” consists of two parts. The first part is taken from the Preferences panel and specifies the default path to your scene repository. The second segment represents the project’s name. You have, for example, defined a custom location for all scenes under:

Preferences > General > Scenes Folder: D:\RF5_Scenes\MyProjects

“Export” contains a graphical representation of the scene tree and contains all object groups. This section is dynamically adjusted to the scene’s contents. The individual branches can be expanded or collapsed to access the different export options. These parts will be explained in detail during the following pages.

Under “Name/Prefix” you can easily change a node’s standard export name, for example if you have to make several versions of a simulation. By default, RealFlow automatically assigns a name to each node, e.g. Square07 or RealWave01 and writes them to the “Name/Prefix” sections. Just alter the name and it’ll be saved under this new label.

To edit the file name that’s written by Export Central, simply click on the desired name to highlight it. Next click once on the displayed name under “Name/Prefix” and the input field becomes editable. Now you can choose any name. This name will used as a prefix for the saved data file.

An example:Let’s assume you have a scene with lots of emitters and you want to rename some of them for better differentiation. A standard name for a square emitter, for example, would be Square07. The settings you have made under

Preferences > Export

tell RealFlow that a certain pattern will be applied to the file name. By default this pattern is “name#.ext” with a 5 digit file padding. “name” is the displayed name form Export Central’s “Name/Prefix” and “#” symbolizes the current frame. A typical file name at frame 100 would then be

Square0700100.bin

By changing the name under Export Central to “Square_RES20_” the file at frame 100 is stored as

Square_RES20_00100.bin

while the entry under Nodes remains the same. This change only affects the saved particle files! It’s important to rename files carefully, because a random naming could easily lead to errors and confusion. Imagine a rigid body dynamics scene with hundreds of objects and totally unsorted names. After a few days you won’t be able to reproduce the



Introduction | 58

BIN Particle cachePXY Particle or grid proxyPD Particle sequenceASC Particle sequencePDC Particle sequence

Export Central’s standard particle options.

BIN is RealFlow’s most common particle file format. It contains all relevant position and physical data, such as density or pressure. BIN files can be read by any plug-in available for 3D programs and they’re accessible via Python scripting for storing customized particle files. BIN files can be cached by RealFlow to enable simulation data playback via the Timeline and they can store huge amounts of data – file sizes of 50 MB or even more are quite normal. This, of course, makes it impossible to play back cached simulations in real-time and you should consider using the Movie Player. BIN files are fully supported by RealFlow’s import and export filters and all available plug-ins.

PXY is a proxy format and only stores a particle’s ID, position and velocity. Depending on the adjusted quality level under “Options”, some particles are left out during storage, but it’s perfectly suited for large particle amounts. Please keep in mind that proxy files are not supported by RealFlow’s connectivity plug-ins. PXY can be considered as an internal RealFlow format.

Now you create a new project that’s called “FirstTest”. RealFlow automatically adds the standard set of folders under this path:

D:/RF5_Scenes/MyProjects/FirstTest

This path exactly represents the $SCENEDIR variable. For standard particles, the complete path would be:

D:/RF5_Scenes/MyProjects/FirstTest/particles

or, as an abbreviation under Export Central (you can see this in the image on the right):

$(SCENEDIR)/particles

After the simulation has finished, you’ll find all mesh files under this location. Export Central gives you the possibility to change this path to your special needs. Simply highlight the desired node under Export Central and single click on the path to make it editable. You can even replace the $SCENEDIR variable with a complete path, e.g.

D:/Research/ScriptedEmitter/Foam/01/particles

This change can be performed individually for each item in the scene! So be careful to keep control over your settings, folders and files. It’s also important to follow the special operating system dependent rules for creating directories.

u This workflow is also available for the new IDOCs and very convenient, especially when a node belongs to more than one IDOC. The variable in this case is called $IDOC (instead of $SCENEDIR).

6.03 exporting particle emittersWith this option it’s possible to activate export functionality for standard fluid emitters, e.g. circle, triangle or spline. Please note that some emitters from the new grid fluid engine are also part of this section, because splash, foam and mist behave like traditional emitters, and they can interact with other emitters, daemons and objects in the same way. For all standard particle emitters, RealFlow supports these file/export formats:



Introduction | 59

PD is a flexible format for particle data. The advantage of PD is that the user can select the data data s/he wants wants to see exported by simply clicking on the desired attributes. This feature saves disk space effectively. Since PD is also well documented, it’s possible for users to write their own importer for reading out the files. As seen in the image on the left, you can choose from a wide variety of attributes. These data can be translated into vertex maps, for example, to visualize particular characteristics of the fluid or render particle based motion blurs. Please note that vertex maps aren’t supported by some 3D programs and this is not a feature of Next Limit’s plug-ins.

ASC stands for ASCII, the standard text format for all computers. Entries are directly readable and editable with any text editor. Currently, ASC is only supported for writing out files and customized data exchange, e.g. by using your own scripted or programmed readers.

The PDC format contains similar data as PD, but without the possibility to choose from attributes. “PDC” stands for Maya’s “Particle Data Cache”.

Foam particles are an exception, because they also support the FTC format and an image file type for generating foam maps. These maps are stored as TIF files.

By default, all data are stored under the “particles” folder of your currently opened project; TIF and FTC files are saved to a certain directory, called foam. If you need separated locations for the individual formats or emitters, feel free to change paths with Export Central’s Path option (see page 57). The BIN format should always be activated, since this is the only format that’s entirely supported. Nevertheless you’re also able to write out other formats simultaneously.

6.04 exporting Grid emittersRealFlow’s new Hybrido solver (see page 65) is a sophisticated and exciting technology, allowing you to simulate large scale scenes, such as extensive water surfaces. For this purpose, a series of new data formats had to be introduced, storing the particle data separately. These files are designed for storing huge amounts of data and only contain the most important attributes. The particles from this emitter type are also called “core fluid”. This core describes the body of your fluid, while splashes, foam and other secondary high-resolution effects are created with appropriate standard particle emitters.

Grid emitters share the same data types and file formats as the standard fluid emitters (see page 94): BIN, PD, ASC and PDC, but they’re not activated by default. The reason is the core fluid concept, which often requires very large amount of particles. To store them, RealFlow uses compressed cache or proxy files, and they can be found under the grid domains branch! If you want to make use of the core particles, you can activate BIN or PD, for example. Please note that PD only contains three attributes: “position”, “velocity” and “id”.

6.05 exporting Grid DomainsGrid domains support only two data formats, called GDC and PXY. The first one is the abbreviation for “grid domain cache”, the second one describes proxy files. It’s a little bit difficult to understand, because the grid domain itself isn’t capable of emitting particles. A grid emitter is always needed and this is the actual source of particles. The grid domain itself is just the space in which the particles are acting. RealFlow stores the particles of the grid emitter and assigns them to the grid domain. The GDC format is used for this purpose to speed up this process.

RealFlow’s export options for grid domains.

GDC can be seen as an internal format that’s only used by RealFlow to visualize the fluid inside the grid domain. GDC data are not meant to be imported to your 3D application,



Introduction | 60

and this versatility results in a wide variety of different file formats: BIN, PXY, PD, ASC, RWC, SD, LWO, BIN, TGA and TIF.

u To create splashes or foam particles, a RealWave surface needs special emitters: Object splash and Crest splash. These particles act like RealFlow’s standard emitters and are therefore grouped under Particle Emitters!

The BIN particle cache is directly created from the vertices and polygons of a RealWave object. It’s possible to create 3D meshes from these particles to combine them seamlessly with Object splash or Crest splash particles. This option is also called “Particle layer”. Since particle layers are directly generated by the RealWave object, they can be found under Export Central’s RealWave branch. For these particle sequences you can use the standard formats BIN, PXY, PD, ASC and PDC.

RealFlow’s export options for RealWave nodes.

The RealWave node itself is built from polygons, representing a flat mesh, and becomes displaced by a number of modifiers, creating many different wave types. The deformations

but if you want to make use of the grid domain’s core fluid particles, you can write out BIN files. Other elements, like splashes or mist are simulated and stored separately, and they’re not part of the core fluid! GDC files are stored in the “grid” directory of your project’s folder.

The third format is TIF and it’s used to write out displacement maps during simulation. Unlike other images-based export options, here only the TIF format is valid and you cannot choose from other types. The pictures are either stored as 8-bit greyscale or 16-bit colour files, dependent on your settings (“YYY” or “XYZ”). Before you can make use of this feature, it’s necessary to activate it under the grid domain’s settings:

Grid Domain node > Node Params > Displacement > Calculate > Yes

6.06 exporting Grid MistsGrid mist emitters also have their own file format: It’s similar to GDC and called MTC. MTC is a pure cache format, too, and not meant for transferring data to 3rd party applications. This format is for internal use only to visualize the mist particles in RealFlow and you cannot export particles from mist emitters. It simply holds a density field that is visualized in RealFlow’s viewport as foggy volume elements. For external usage, MTC is currently supported by RealFlow’s RenderKit 2.

RealFlow’s export options for grid mist emitters.

6.07 exporting RealWave NodesWith RealWave objects it’s possible to export various data types and it’s necessary to differentiate between emitter particles, RealWave particle layers, surface deformation and textures. The export possibilities for RealWave nodes exclusively concern the wave surface



Introduction | 61

RealFlow’s export options for cameras.

6.09 exporting DaemonsDaemons apply forces to scenes and normally there’s nothing that could be exported. In 3D programs, positions or force values are needless, because the simulation data already contain the influence of the daemon on an object’s or particle’s position and velocity. So there’s only one daemon that can be exported: Color plane. Actually it’s only possible to export the data generated by this daemon. Information can either be stored as a coloured bitmap or as numerical data. To change the default TGA format, click on “tga” and “Option”, and choose from the following types: JPG, BMP, PNG or TIF. The results can be found in the “images” folder of your project.

RealFlow’s export options for the color plane daemon.

6.10 exporting objectsWith this version of RealFlow, Next Limit introduced a completely new solver for rigid and soft bodies, and due to this fact, a new file format was required to store dynamics data. It’s called CACHE (.bdc) and is only used internally, and therefore not supported by RealFlow’s exchange plug-ins. CACHE files work on a scene level, similar to the ANIMATION (.sd) file, but there are some decisive differences:

• CACHE files are written with each frame and store more information than SD files.

of a RealWave mesh can be stored in various formats. The first is called RWC or RealWave cache. It’s a frame-based format and you’ll get one file per frame. Like the other cache files (GDC, GFC and MTC) , RWC is for RealFlow’s internal use only to increase playback speed. Another possibility is to write out SD files for recording the wave object’s surface deformation. SD is RealFlow’s common scene data format and used for all kinds of geometry exchange, though the RealWave SD has a different data structure. The entire displacement data from all simulated frames are stored within a single SD file and due to this fact, a RealWave SD file may quickly become rather big. Please note that SD files are no longer limited to 2 GB.

The next option is to store a sequence of LWO files. LWO is Lightwave’s proprietary file format, but it can be read by many other programs, too, e.g. Cinema 4D. LWO files aren’t supported by Next Limit’s plug-ins and therefore native support cannot be guaranteed. You might also have to use special import filters outside Lightwave with LWO files to display the entire sequence. The last file format is again BIN. Though it has the same extension as particle files, it doesn’t contain the same data. RealWave BIN files only store geometry displacement data without particle information. There’s one BIN file stored per simulated frame.

Due to the fact that RealWave objects can create foam textures, it’s possible to store matching greyscale images with the waves. By clicking on “tga” under “Option” you can choose from several common image formats. It’s also important to know that RealFlow textures are always square shaped.

With RealFlow 5 it’s now possible to export tileable displacement textures instead of, respectively additionally to the surface displacement file(s). These textures always use the TIF format and RealFlow writes out one file per frame. The files can either be loaded as sequences for post processing or merged to create a video that’s attached to a texture’s displacement shader. They can also be used with Next Limit’s new RFRK 2 displacement shader.

6.08 exporting camerasFor RealFlow cameras there’s only the SD format available. It makes no difference whether the camera was created directly inside RealFlow or imported from another program. Camera data are always written to the “objects” folder.



Introduction | 62

• SD files are supported by RealFlow’s exchange plug-ins and still needed for interaction with 3D programs.

RealFlow’s export options for objects.

CACHE files can be used to replace the other available formats, but only if exporting to other programs isn’t required. You can resume from CACHE sequences and since they work on a scene level, all dynamics data from all object nodes will be stored in the same way as with the global ANIMATION (.sd) file.

Another method to record animation data for export is the use of individual Animation (.sd) files. As you can see from the image above, they’re available for each object in your current scene. In previous version, these files had been necessary to simulate scenes with cached dynamics data, but that’s not valid anymore, because the new CACHE (.bdc) format can replace them. In case you want to export data from certain nodes to a 3D program, it’s still necessary to activate the object-related Animation (.sd) option. Of course, the files won’t be stored as “Animation.sd”. By default, they carry the name from the appropriate node. In this case “Sphere01.sd”. Please note that RealFlow can slow down significantly if you decide to store large amounts of object individually.

u If you want to use the "Cache" mode for simulations, you still have to use SD files for each object. The BDC format currently doesn't support the "Cache" mode.

With objects you also have the possibility to export OBJ files. OBJ is Maya’s standard format and supported by many 3D programs. If you have activated wetmaps with your objects, it’s necessary to enable their export. By double-clicking on “tga” you can find all available image formats.

There are often problems reported with 3D programs (respectively the plug-ins) and the ANIMATION (.sd) file: users observe missing connections between RealFlow simulation data and the corresponding objects within their 3D application. That’s mostly related to

naming: each external object needs an exact representation in RealFlow regarding names. Here's an example:

Valid names 3D app Valid names RealFlow Invalid names

Sphere_01 Sphere_01 Sphere.01

Vase7 Vase7 Vase_$$7

Wall_Left_Top Wall_Left_Top Wall.Left&Top

As you can see the names have to be exactly the same. By changing the name either in Maya or RealFlow, the plug-ins won’t be able to find the original objects and the simulation data can’t be connected – the result is an immobile object. There are also some characters that should be strictly avoided with names: never use a dot, because it’s used internally by RealFlow’s Python scripting engine. Forbidden characters are also vowels or glyphs like $, %, §, & and brackets. A filename should only consist of these characters:

A – Z, a – z, 0 – 9, - (hyphen) and _ (underscore)

Other characters might be replaced automatically within RealFlow and should be avoided!

6.11 exporting MeshesMeshes can be described as three-dimensional hulls around particle clouds, representing the volume of simulated fluids. Such a fluid mesh can be exported to a 3D program and then textured or shaded. RealFlow provides three different meshing methods:

1. Particle meshes (ST = Standard)2. Particle meshes (RK = RealFlow RenderKit)3. Grid meshes

All types share equal file types: BIN, MD and OBJ. The most common and entirely supported file format is BIN. The plug-ins are able to read BIN file sequences and display them in your favourite 3D application. RealFlow is also capable of showing BINs to enable playback and previews.



Introduction | 63

6.12 exporting Job FilesWith RealFlow 5 it’s possible to simulate fluids over a network, using multiple computers. The only limitation is that particles from different domains, respectively emitters, are not able to interact with each other – they’re independent. Therefore we call this concept “Independent Domains Of Computation”, or “IDOC” for short. To manage the data from different machines, RealFlow writes out the appropriate files into a particular directory: “jobfiles”. You can only change the folder’s name and location under Export Central.Additionally you can choose if you want to write out possibly existing RealFlow script files. This file type can be recognized by its RFS extension. You should be careful when you want to change the RFS file’s path, because in this case you might have to specify it manually within the Job Manager’s web-interface.

RealFlow’s export option for Job Manager scripts.

6.13 exporting log FilesThe log file is a standard ASCII text file that contains details about your currently opened scene and stores various messages. It’s mostly used for debugging a scene and comparing or evaluating render times. The log is overwritten with each start of RealFlow, so if you want to store different versions, it’s necessary to modify either the “Name/Prefix” in Export Central’s log branch or change the name manually in the projects “log” folder. With RealFlow 5, log files have been greatly improved and it’s actually a copy from the Messages window.

RealFlow’s export options for log files.

The MD format is very similar to a particle emitter’s PD files (see page 58). With MD it’s also possible to choose from a wide variety of attributes to become stored with the file, as you can see from the image below. Currently, MD is not natively supported by the plug-ins and requires custom import filters. A third option is to write out an OBJ sequence. OBJ is implemented in many applications, but most programs can only load one OBJ file per scene, instead of entire sequences. The recorded files can be found under “meshes” in your project folder.

RealFlow’s export options for meshes are the same for all three types.

u There’s only one difference between RealFlow’s three mesh types: standard particle meshes also support Lightwave’s LWO format.

Traditional particle emitters can be meshed either with RealFlow’s standard method or the new engine that’s the same as RealFlow’s RenderKit (RFRK) built-in meshing tools. Grid emitters are limited to their own meshing engine, which provides different features and is directly tailored to grid-based fluids. Anyway, grid meshes are a special case, because as long as there’s a domain included, it’s also possible to mix grid particles with standard particles.

Though emitter and mesh BINs share the same extension, they’re designed completely differently and the plug-ins know two separate import tools for particle BINs and mesh BINs.



Introduction | 64

6.14 exporting previewsPreviews are an easy, but very effective way to control simulations in terms of fluid behaviour or object velocity and overall appearance. With large scenes it’s not possible to reach real-time playback and therefore it’s necessary to record the viewport frame by frame. You have the possibility to record frames during playback for assembling them with an external tool. These image sequences can be stored in several formats, found under the “tga” option. The other method is to use RealFlow’s internal Movie Player. The available video file types strongly depend on your operating system and the installed codecs. Under Windows, there’s the AVI format, OS X uses MOV, for example. Preview movies are also generated from images sequences in PNG format.

RealFlow’s export options for preview files.



Introduction | 65

7 HyBRIDo

Hybrido (HYBrid larRge dImension LiquiD sOlver) is a brand new and sophisticated method for simulating medium and large scale fluids. This technology also includes the automatic creation of secondary splash, foam and mist particles. With Hybrido it’s possible to simulate everything from floods to ocean scenes – scenes that have been hard to create with RealFlow’s traditional particle emitters.

RealFlow’s standard emitters are perfectly suited for highly detailed fluid simulations with tiny splashes and turbulent surfaces. But, it’s always been difficult to create mid or large scale projects. The typical hallway flood scene is a very good example of RealFlow’s capabilities. This type of scene has normally been the maximum of what’s reasonable to simulate. If you wanted to spawn spray particles, it had to be done with Python scripting, exploiting parameters like pressure or velocity. With Hybrido that’s a thing of the past. Fluid artists are now able to simulate impressive shots, like oceans with breaking waves, huge floods, turbulent coasts with cliffs and rocks, or ships travelling through turbulent water during a heavy storm. RealFlow calculates the conditions for splash, foam and mist formation, and automatically creates these particles. These secondary particles can even be simulated as a post process in a network. With this advanced feature you’re able to generate millions of particles, utilizing the full CPU power of your renderfarm or network machines.

As usual, all the new elements are fully integrated into RealFlow’s user interface, easy to handle and capable of full interaction with other objects. Experienced users will find many

settings and parameters they already know from RealFlow 4. Despite this integration and intuitive workflow it’s worth explaining Hybrido’s mode of operation in detail. Hybrido is a completely new fluid engine and therefore uses methods that haven’t been implemented before.

Images from a grid fluid simulation with approximately 10 million particles.

7.01 Domains and GridsThe most important new addition is the domain term. Briefly, a domain is a place where your large scale fluid simulation happens. With RealFlow’s traditional emitters the fluid was free – it wasn’t necessary to create a space around the fluid to limit its extension. A standard fluid emitter that was placed somewhere within a virtually endless space didn’t require any boundaries. This workflow is a result of RealFlow’s fluid simulation method, called Smoothed Particle Hydrodynamics (SPH), which is great for small to mid-range projects.

For large scale simulations, SPH is not an appropriate solution, because huge amounts of particles normally don’t need the accuracy you would use for filling glasses or neat splashes around an object. Another issue with SPH is simulation speed. With “normal” SPH particles you’d also need a huge amount of particles to fill a large volume and that’s not really pratical: RealFlow’s grid-based approach is much faster and better suited for this purpose.

Grid solvers subdivide a certain space into small cells – a process that’s also known as discretization. The entire simulation happens within this grid and particles cannot leave it.



Introduction | 66

Such a grid space is also called “domain” and the number of cells is known as resolution. A grid’s resolution is different from the traditional understanding of the term resolution that’s used with standard emitters. In the second case, resolution is directly connected to the number of particles, whereas in grid domains, the amount of particles is only indirectly determined by resolution. Therefore it’s necessary to differentiate between “grid resolution” and “particle resolution”. The higher the number of cells, the better and more accurate the final simulation will be.

The grid domain, as shown above, is actually nothing more than an empty space of a certain size, subdivided into cells. This definition is important, because other grid fluid related emitters also use domains, for example the splash emitter (see page 77).

7.02 a Basic Workflow For Grid-based FluidsCreating a working grid fluid requires three easy steps:

1. Creating a grid fluid domain.2. Adding a supporting object to define the emitter’s shape.3. Applying a grid fluid emitter and attaching the supporting object.

The very first action with grid-based fluids should be the creation of a grid domain:

Menu bar > Edit > Add > Grid fluid > Domain

Right click menu > Add > Grid fluid > Domain

Toolbar > Grid fluid menu > Domain

u In the following sections and chapters there’ll be only one method for adding objects or calling functions. Since all methods yield equal results, it’s not necessary to list them each time. You can just use the method that’s best suited for your workflow.

Together with this entry you can also see “Emitter”, “Splash”, “Foam” and “Mist”. Except from “Emitter”, all the other items are discussed later, because they’re not necessarily needed with this type of fluid.

The viewport now contains a box with a dimension of 10 x 10 x 10 units and the Nodes/Global Links windows show a “GridFluidDomain01” node. When you take a closer look you can see 8 little cubes at the corners of the domain. These cubes represent the current cell size of the grid and by changing resolution the cells become smaller or bigger (see the image on the left).

Usually the next step would be to add an emitter, but here it’s a bit different – you’ll need a supporting object first. A grid fluid emitter has no predefined shape by default. The final shape and size of the emitter is given by the supporting object. Such an object can be (almost) any item, regardless of whether it’s one of RealFlow’s internal bodies or imported from an SD file. Even 2D objects, like triangles or discs are accepted. For the very first project a standard cube is used:



Introduction | 67

Menu Bar > Edit > Add > Objects > Cube

The supporting object can be rescaled, rotated or positioned to your individual needs at any time. In this case, the cube is going to be enlarged and lifted upwards. Select “Cube01” object from the Nodes panel or the viewport to make it active, and enter the following values:

Node Params > Node > Position > 0.0 | 2.5 | 0.0

Node Params > Node > Scale > 5.0 | 0.5 | 5.0

In the last step the grid fluid emitter itself is placed in the scene:

Menu Bar > Edit > Add > Grid fluid > Emitter

Directly after this action, RealFlow opens a window containing all available objects that can be used with the emitter. In this case it’s only the previously added cube. By selecting it, the object will be linked to the emitter automatically. Now you have a complete setup for your first grid fluid simulation. The attached cube is only visible for the emitter and ignored by other objects. To remind you on this fact, RealFlow prints out an appropriate warning message at the beginning of the simulation. If you want to get rid of this message, simply remove the attached object from the Global Links panel.

Finally, to achieve a reasonable result, a gravity daemon is attached to the scene. Hit “Simulate” and shortly afterwards you should get a result similar to the images on the right. The fluid that you can see here is also called the core fluid. It’s called this way, because it lacks the highly detailed splashes and turbulences you can observe with standard fluids. Details and secondary particles are generated from the core fluid using special emitters, such as splash or mist.

The entire scene is simulated using the standard preferences. If you haven’t made any settings for “MIN” and “MAX substeps”, “FPS output” or scale, then standard values are applied. This may result in a rather slow simulation, depending on your computer. To lower calculation time, edit the “Simulation options” tab to establish new settings for this project. The simulation speed of grid fluids is influenced by the same parameters as standard fluids, especially “MAX substeps”.

Grid fluid simulation using the settings given before. The red square shows the inner boundaries of the domain.

As you can see from the images above, grid fluids have some specialities. The most obvious is that all particles stay within the grid domain. As mentioned before, the domain acts like a bounding box, enclosing the fluid. The next issue concerns these boundaries, too. From a side view you can see that the fluid doesn’t entirely fill the grid space. There are invisible walls of an inner cube, indicated as a red square inside the domain. These walls are represented by the little boxes in the corners of the domain. The last thing to consider is that its not possible to create particles from the inside of an object. For example, you cannot place a grid emitter inside a cube and produce particles. In such a case nothing happens. If you want to achieve such a situation, you’d have to represent the walls of the cube with individual objects.

If you’re familiar with RealFlow’s standard emitters you’ll certainly notice a different behaviour with Hybrido fluids. The reason, of course, lies in Hybrido’s operation mode with grid cells. Standard SPH-based fluids have more parameters for control, simply because more detail is required with this type. On the following page you can see a comparison between a grid fluid and a standard emitter. Though both emitters share an almost equal number of particles (approximately 135,000), the results are completely different.

u There’s no limit for the number of domains in a scene. You can apply as many grid domains as you want, but please keep in mind that domains cannot interact with each other – they’re all treated separately.

Direct comparison between grid (left) and standard fluids with identical settings.



Introduction | 68

7.03 common settingsThe entire range of grid fluid nodes shares a variety of common settings. Though there are slight differences, they’ll be discussed together in the following sections. Differences and exceptions are always marked and you’ll find hints when a parameter is only available for a certain node. Common settings are mostly related to a node’s orientation in space or viewport representation. Everything can be found under Node Params.

a. The Node panel

The domain’s scale, initial rotation and position can be changed here, together with some other node-related settings.

SimulationThe first entry is used to specify how a node contributes to a scene. The default option is “Active” and tells RealFlow that the currently selected node will be considered during simulation. “Inactive” disables it and the node is greyed out. “Cache” is of special importance, because with this method it’s possible to read already simulated data from disk and use them in a new simulation pass. The cached item won’t be affected by forces

or other nodes anymore. On the other hand, a cached node is still able to influence other bodies or fluids. In the Nodes panel, cached nodes are displayed with a yellow font.The Node panel, common for all grid fluid items.

PositionTo specify a node’s position in 3D space, RealFlow expects 3 values for X, Y and Z. You can enter any negative or positive value, including 0.0. By default, objects are always drawn to the origin at [ 0, 0, 0 ]. “Position” is closely related to the viewport’s grid: the distance between two grid lines exactly represents one unit, respectively 1 m.

Rotation“Rotation” actually works the same way as “Position”, but here angles are needed. RealFlow accepts any positive or negtive angle in degrees – 0.0 is, of course, also supported.

ScaleThis parameter determines a node’s dimensions and again consists of 3 values. Like “Position”, “Scale” relates to RealFlow’s viewport grid.

ShearWith this parameter it’s possible to create a spatial distorsion of a node. Please note that the influence of “Shear” is very limited with grid fluid nodes and in many cases you won’t see any effect, except a graphical deformation in the viewport.Parent toNodes can be bounded to other objects, forcing them to follow their motions and rotations.



Introduction | 69

By parenting a node to another object, it’s possible to transfer already animated attributes (for example position changes) to the desired item.

ColorIn many cases it’s required to differentiate nodes in the viewport to avoid confusion. By simply applying a colour you can separate similar or equal nodes from each other visually.

b. The Initial state panel

An initial state can be seen as a kind of preset. Whenever there’s a certain state during a simulation you really like or which carries specific attributes, you can create an initial state and resume the calculation from this certain point. Existing files will be overwritten, though, except if you’ve made a backup before. RealFlow saves a single BIN containing all necessary information in the appropriate folder of the current project.To make an initial state some easy steps are required:

1. Simulate to the desired point.2. Click on “Make Initial State”. and set “Use Initial State” to “Yes”.3. Click on the triangle next to the “Reset” button and choose “Reset to Initial State”.4. Reset the scene and simulate.

c. The statistics panel

The statistic panel informs you about the most important attributes of the selected grid fluid domain or emitter. This is especially useful when you want to check the total amount of particles, for example for estimating the final file size, or dying the particles based on

their velocities. Please note that there are slight differences between the individual grid fluid node types regarding this parameter set. Furthermore, all values are for information only and cannot be changed.

Particles (Grid Fluid Domain) / Existent Particles (Splash and Foam)Here you can check the amount of particles for each emitter individually. If this value is greater than an emitter’s “Max particles” settings, no more particles will be generated.

Emitted Particles (Splash and Foam)This is the amount of already emitted particles at the current time. It also counts particles that already vanished or were deleted with appropriate daemons.

Particle mass (Splash and Foam)Here you can monitor the mass of a single particle. It strongly depends on “Density” and “Resolution” and is updated automatically.

V min/V maxThese values print out the minimum and maximum velocities for all particles of the selected domain or emitter. Very high values are very good indicators of stability or memory problems, as they sometimes occur with errors in custom Python scripts. Therefore, “V min” and “V max” are essential helpers for debugging operations. Another application is the relaxation of a fluid with a k Speed daemon, where you need these values, too.



Introduction | 70

d. The Display panel

Experienced users will surely recognize many settings from RealFlow’s standard emitters, but there’s also something new to explore. A few parameters are only available for certain nodes, but that’s indicated.

u The Display panel for mist emitters is completely different from other grid fluid nodes and therefore treated separately under the appropriate section on page 83.

VisibleThis setting is used to make the selected domain invisible or visible. It’s sometimes necessary to look behind or inside a fluid’s particle cloud to evaluate the movement of rigid bodies or other particles, for example. You can easily toggle between the individual modes with this switch.

Domain (Grid Fluid Domain) With grid fluid domains you can select from four different modes to determine how the domain’s box should be displayed:

• None The box of the domain is hidden.• Box This is the default setting. With this mode you can see eight small boxes at the corners indicating the domain’s resolution of the domain.• Cells All the cells of the domain are shown. With particles this mode can be a little confusing due to the large number of objects.• Back cells The grid elements are projected on the domain’s walls like a 2D raster.

DetailHere you can choose from 5 different modes (“Draft” - “Best”) to adjust the representation of the domain’s particles in the viewport.

Point size Each particle is represented by a dot. With point size you can adjust the size of this dot.

Show arrowsInstead of points the particles are displayed as arrows indicating an particle’s property vector, e.g. “Velocity”. The direction shows the direction the particle is travelling, while its length illustrates the magnitude or “speed value”. Arrows are also tinted to represent a parameter’s differences. For this, “Min range color” and “Max range color” are used.

Arrow length (Splash and Foam)This option requires that “Show arrows” is set to “Yes”. Then you’ll be able to specify the length of the displayed arrows individually. That’s especially useful when the selected property only shows very small differences.

PropertyThis mode is used to show different physical characteristics of the fluid. With grid fluid domains you can choose from:

• Velocity Shows the velocity for all three directions in space X, Y and Z.



Introduction | 71

• Velocity.[a] Displays only the X, Y or Z part (= [a]) of the velocity.• Pressure Indicates the pressure for each particle.• Constant Used to apply one colour for all particles without shades or gradients.

Splash and foam emitters additionally provide these attributes:

• Pressure Indicates the pressure for each particle.• Density This is the density gradient within the fluid.• Vorticity If “Vorticity” is switched on, it can be shown with this parameter.• Temperature This setting is only useful for gaseous fluids.

Automatic rangeThis option automatically calculates the colour gradient for the selected property. The colours that are used for this purpose can be selected from the “Min range” and “Max range” color fields.

Min range / Max rangeWhen “Automatic range” is turned off, you have to specify these minimum and maximum values for displaying the colour gradient. The minimum values will then be represented by “Min range color”, the maximum values are shown with “Max range color”. To find out minimum and maximum velocities, for example, open the Statistics panel for “V min” and “V max”.

Min range color / Max range colorClicking on these fields opens a system colour picker to choose any RGB value from a given palette. These colours can be used to create certain impressions, such as fire or smoke.

7.04 Grid Fluid DomainThe grid domain offers a variety of settings to customize the appearance of the fluid. One of the most critical and important settings is size. The default dimension is 10 x 10 x 10 units. If you’ve left the standard grid size (Preferences > Display > Square size > 1.00) untouched, then this scale equals 10 m x 10 m x 10 m. By stretching or rescaling the domain it’s possible to create large fluid surfaces, e.g. for oceans or floods.

It’s important to understand the role of particles in the grid-based solver. Basically they

are massless particles that flow with the fluid. Their main role is to visualize the core fluid, but they are not considered at the time of computing the fluid dynamics. For this reason even with millions of particles describing a fluid, the computation process is very fast. The particles are cached into files with the GDC extension (see page 59, “Export Central”). The amount of data needed to store a grid-based fluid can be enormous. For that reason the files are “lossy compressed”. The consequence is that resuming a simulation from a cached sequence will give you a slightly different result than an entirely new simulation.

Aside from the Fluid tab there’s also the Displacement panel, providing all necessary settings for an ocean surface. You cannot only define different levels of quality, you also have full control over the appearance, e.g. the amount of cresting waves to simulate various stages from breezy to stormy. Displacement uses a statistical model to create the surface structures and this model strongly depends on the ocean’s dimensions. The method used is actually the same as that’s used with the new statistical wave modifier from RealWave. Therefore you’ll see some parallels regarding final output and parameters. If you want to get an impression of the look and feel of these displacements, it’s a good idea to perform some calculations with RealWave, because it’s very fast and easy to control.

a. The Fluid panel

This parameter set is used to specify a grid fluid’s physical properties to achieve a certain behaviour. You’ll find some similarities with standard fluids, but they’re actually not really comparable, because of different modes of operation. As mentioned several times before, grid particles only describe the core of a large scale fluid and therefore require fewer settings.



Introduction | 72

ResolutionBesides scale this is the other critical parameter. You’ve already heard about the domain’s resolution and its impact on the grid. The value itself roughly defines the total number of cells within the domain’s volume. The entered value is just an approximation, because it’s not possible to subdivide each object into an even number of cells. The effective number of cells is printed in the viewport next to the grid node’s name. In the picture below the real number of cells is 103,823 and the adjusted “Resolution” value is 100,000.

“Resolution” only defines the number of cells, not the amount of particles. Of course, you’ll get more particles with higher “Resolution” values, but you won’t be able to directly control this number. Additionally, the amount of created particles also depends on the size of the grid fluid emitter.

DensityThis value has exactly the same function as with standard emitters. “Density” is defined as

Density = Mass / Volume [ kg · m-3 ]

Since pure water has a density of roughly 1.000 kg · m-3, we can follow that 1,000 litres of water exactly weighs 1,000 kg. Or: One litre equals one kilogram. Conversely an amount of 1,000 litres (or kilograms) fills a volume of 1.0 m3. “Density” is used to simulate “heavier” or “lighter” fluids, such as alcohol, salt water, oil or liquid metals. On page 326 of “Tables and Values” you’ll find a list of the most common fluids and their densities.

It’s very important to understand that a change of “Density” does not affect the fluid’s dynamic behaviour. This means that your simulation will be exactly the same, even if you

change “Density” to very high values. The reason is that RealFlow grid fluids use kinematic viscosity, not dynamic viscosity!

Different “Density” values show exactly the same behaviour.

ViscosityWith grid-based fluids viscosity is directly connected to density, although it‘s not visible to the user. RealFlow uses kinematic viscosity depending on a fluid’s density. Kinematic viscosity is a measure for the inner friction of a fluid and its dimension is [ m2 · s-1 ]. Each fluid has a certain amount of viscosity, due to the fact that the fluid particles collide with each other, causing the previously mentioned inner friction.

Substances with low viscosity are different types of alcohol, solvents or water. High viscous substances are honey, tar, crude oil or syrup, for instance. The minimum allowed value is the viscosity of water (approx. 0.000001 m2 · s-1) and the maximum value represents melted glass (approx. 1 m2 · s-1).

Splashes turn out completely different with growing viscosity.



Introduction | 73

CompressibilityThis value can range between 0 and 1 and doesn’t have a dimension or unit. Compressibility is mainly responsible for a fluid’s tendency to bounce. A value of 0 means that the current fluid cannot be compressed anymore and the fluid particles rest together as closely as possible. With 0 you can eliminate any bouncing effect, but it takes longer to perform such a calculation, because the solver also has to check if the compressibility condition is fulfilled or not.

A value of 1 indicates minimal compressibility and it’s the fastest method. In this case you’ll observe clearly visible bouncing effects and some turbulence within the fluid. All values between 0 and 1 damp/increase the bouncing effects accordingly. The default value is 0.5 which is best suited for water.

Compressibility increases from the left to the right: 0.1, 0.5 and 1.0.

b. The Displacement panel

This parameter set is used to apply a wave structure to meshed grid fluids. This structure is similar to the new statistical spectrum modifier for RealWave. With grid-based fluids, the displacement is calculated during a fluid simulation, though not displayed. Even with activated displacement, you can only see a particle representation or the mesh you’ve create from the simulation. To make it visible, a grid mesh is needed together with an appropriate shader:

GridMesh node > Shader > Type > Displacement

GridMesh node > Shader > Source > Domain

CalculateBy default, RealFlow does not calculate the displacement information of the current grid fluid simulation, but by turning this on you’ll have access to a variety of settings. The displacement is only visible with the final mesh, not during the particle-based simulation.

QualityYou can choose from 6 different levels of quality. Of course, higher quality settings require longer simulation times, but also create more details. The displacement of the surface is achieved by using maps and by altering “Quality” you actually change the underlying map. To export this map, you have to tick the appropriate section for the grid fluid domain under Export Central – it’ll be saved as a 16-bit TIF file. The resulting file sequence is then used within your 3D application to calculate the fluid’s displacement.

Auto depthThe appearance of the surface waves strongly depends on the ocean’s water depth. With activated Auto depth, RealFlow automatically “measures” the current depth of your grid domain fluid and uses this value for the statistical wave generation method. By setting this parameter to “No” the following values become unlocked.



Introduction | 74

@ depthWhen “Auto depth” is set to “No” you can easily specify the desired ocean depth by entering any positive number.

Vertical ScaleTo alter the height of the statistical waves, “Vertical Scale” is used. You normally have to adjust this parameter when you’re changing the surface’s dimension value. “Vertical Scale” has a significant influence on the credibility of the entire simulation and can also be used for the creation of heavy storms with high waves.

Auto dimensionThis parameter is very similar to “Auto depth”, but here, RealFlow doesn’t detect depth, but rather the horizontal dimensions of the grid fluid container which it uses for the calculation of the waves. By default it’s set to “Yes”, but you can also specify your own settings if you change it to “No”.

@ dimensionYou can only define your values when Auto dimension is set to “No”. Please note that you can enter only one value. This means that the shape of the domain is always considered as squared. When you change “@ dimension” you’ll most probably have to alter “Choppiness”, too!

@ dimension = 5 @ dimension = 12

Auto wind speedRealFlow automatically calculates the used wind speed when this parameter is turned on. With “No”, you can enter the desired wind speed in the field below.

@ wind speedThis parameter is only accessible with “Auto wind speed” set to “No”. You can enter any positive or negative value, including 0.

Auto wind directionWith this parameter set to “Yes”, RealFlow automatically reads the directions of existing wind daemons and translates their values into the direction the waves are travelling. With “No” it’s possible to specify a custom wind direction.

@ wind directionThis is the wind direction in degrees. Please note that in the case of using the linked daemons, the velocity vector is projected on the XZ plane and then converted to degrees. If you use another axis setup, where Y does not serve as a height axis, the orientation of the wind direction changes. By default (with YXZ orientation), RealFlow uses this notation:

0° Wind comes from the positive X axis (1,0). Positive wind directions are counter clockwise.90° Wind comes from the positive Z axis (0,1)

Min Wave LengthWith “Min Wave Length” the amount of details on the surface can be controlled. Higher values flatten the surface and create fewer ripples. Please keep in mind that the parameter is connected to “Dimension”. When entering lower values, this parameter should be decreased, too, to guarantee that the RealWave object still shows enough structures.

Weight Against WindThis is a weighting parameter for waves which are travelling to some extent in the opposite direction to the wind. If “Weight Against Wind” is 0.0 then all waves against the wind are eliminated. If it’s set to 1.0 then its normal strength is used. Values between determine the amount of waves being eliminated.

ChoppinessWith growing wind strength you can often observe near-breaking waves with pronounced crests. These sharp crests give you much more realism and are a direct result of the used statistical wave creation model. With “Choppiness” you can determine the sharpness of the surface waves and adjust them to the environmental conditions. By leaving “Choppiness“ at 0.0 the appearance is similar to the fractal modifier of RealWave (see page 210). Very high values might create unwanted effects, such as interpenetration.



Introduction | 75

Choppiness = 0.0 Choppiness = 0.5

Repeat U/VSince the displacement is calculated from a texture map it’s also possible to define the number of repetitions both in U and V direction of the mesh grid. U and V coordinates are related to the UV grid that is created with the mesh. Displacement maps are seamless, though very high values are very likely to create regular patterns on the surface.

7.05 Grid Fluid emitterAs you’ve already seen, it’s always necessary to attach an object to a grid emitter to make it work. The shape and size of this object is irrelevant, but please remember that particles will only be created inside a grid domain. The mode of operation and handling of a grid fluid emitter is similar to RealFlow’s traditional emitters, so experienced users will get along with them easily, but the settings are completely different. Some well-known parameters like “Resolution”, “Density” and “Viscosity” are now located under the grid fluid domain’s Node Params panel.

A grid fluid emitter doesn’t have any display options and the various settings for particles can be found under the grid domain’s Display panel (please see page 70) and it’s exactly the same with the Statistics window.

u The Node panel is common to any object inside RealFlow, regardless of whether

it’s an emitter, a daemon or anything else. Some settings don’t show any visible effect with certain object classes, for example emitters. For more information about the individual functions and their mode of operation, please see page 68 or 95.

a. The emitter panel

A grid fluid emitter always needs an object applied to be able to generate particles. The following settings are used to establish this connection and define the emitter’s mode of creating particles.

ObjectThis setting defines the object used for creating the particles. You can attach a new object at any time, but it’s not possible to bind more than one object to an emitter. To avoid an error message, it’s recommended to remove the attached object from the Global Links panel, because the emitter object is not meant to interact with other nodes. The attached object can have any shape and it’s also possible to use imported objects.

StreamBy default particles are created inside the volume of the attached object and then released. With this parameter it’s possible to switch on a continuos particle stream, similar to RealFlow’s standard emitters. To make the emitter create particles with “Stream” turned on, “Initial speed” must be greater than 0.0.

Initial speedThis parameter indicates the magnitude of the initial velocity of the fluid and is measured in m · s-1. The direction of the initial velocity can be controlled by simply rotating the emitter node in the viewport. An arrow in the centre of the emitter’s symbol indicates the direction.



Introduction | 76

JitteringRealFlow spreads the particles of the emitter equally over the entire grid, respectively over the attached object’s volume. This results in a regular pattern and in some cases to slightly uniform simulations. To avoid this, it’s possible to apply a random value to displace the particles from their original positions. The value determines the maximum distance from the original position without colliding with a neighbour particle. You can choose from values between 0 and 1 and, of course, “Jittering” yields to completely different simulations, as you can see below.

Jittering = 0.0 Jittering = 0.5 Jittering = 1.0

@ seedThis value is connected to “Jittering” and produces a random number for initializing the particles’ displacement.

7.06 secondary particle emitterBy now you’ve learned how to create a core fluid with the help of Hybrido’s basic elements: Grid fluid domain, grid fluid emitter and a helper object, defining the emitter’s volume and position. Though the core fluid already has a convincing appearance, it’s obvious that the simulation lacks those neat splashes experienced users know from RealFlow’s traditional fluids. The reason for this behaviour is the grid-based approach, which isn’t suitable for high resolution simulations, because it’s simply not fine enough to create those tiny and detailed splashes in certain areas.

Hybrido provides a technique to bypass this limitation on demand without the necessity of raising the grid domain’s resolution to super-high values. If Hybrido detects an area that’s not resolved highly enough, it automatically switches to the standard particle mode and creates detailed splashes in these areas. With this sophisticated method it’s possible to spawn different kinds of foam and spray particles directly from the core fluid. The only requirement is the presence of a splash or foam emitter. These types are also called secondary emitters.

These secondary particle emitters are true all-rounders, because they can act independently from the grid fluid and become influenced by all kinds of daemons and objects. They really behave exactly like RealFlow’s standard particles and you can even choose between dumb, fluid, gaseous and elastic particles. Dumb particles are surely the best choice, because they are very fast to compute. Splash and foam emitters establish a seamless connection between the core fluid and particles to enhance the realism of your simulation.

Splash particles, generated from a cached grid fluid simulation.

Since secondary particles are not bounded to the grid domain they’re able to leave this space. For that reason it’s always recommended to either enclose the particles with supporting objects or delete them with a k Volume (see page 125).

a. concepts

The great advantage of these emitters is flexibility. Each secondary particle emitter can



Introduction | 77

be restricted to a certain space, also called a domain. But in this case the term is actually only used for the space or volume where the secondary particles are created. This concept allows you to create defined zones within the grid fluid domain – virtually a domain within a domain.

Splash particles (red) created within separate domains.

The emitters can be placed anywhere within the higher-ranking grid fluid domain and there’s no need to make them available to the entire scene. For example, it’s possible to restrict a splash emitter to a rocky coast line, where you’d expect impressive splashes. Another idea would be to place an emitter only around an island or bound it to a moving ship for creating foam along the body. You can use as many emitters as you want and control their resolution independently from each other. This allows you to adjust the accuracy and the number of particles based on the viewer’s distance: nearer parts will use high-resolution emitters with fluid-type particles, while distant splashes consist of just a few hundred “dumb” particles.

Another sophisticated feature is the user’s freedom to decide whether the particles should be generated while simulating the core fluid or create them in a post process from a cached grid fluid sequence. With small scenes it’s surely not a problem to do all this within a single scene, but with multiple secondary particles from different emitter sources, it’s the right time to think about network simulations! You can access core fluid particles from several computers and each of them carries out a certain number of splash domains, for example. As long as the domains are calculated on different machines, they do not interact

with each other, but in most cases that’s not really necessary. Of course, this workflow requires an appropriate number of RealFlow licenses. For more information please contact Next Limit’s sales team.

7.07 Grid splash emitterThe grid fluid splash emitter is capable of producing spray particles on collisions, particular angles, or velocities. Particles are emitted automatically from the core fluid’s boundaries or areas with contact with other scene elements, for example walls or rocks. These areas require higher resolution and more details – that’s the condition when splash particles are generated. It’s also important to add that particles are automatically destroyed in which they pass the core fluid’s surface. Particles that don’t fulfil this condition can leave the grid domain and should be deleted with an appropriate daemon, for example k Volume.

Grid splash emitters share all the parameters of a “normal” particle-based fluid emitter, plus some additional parameters to control the emission of the splash particles. Actually a grid splash emitter is a standard fluid emitter and anything you can do with the standard emitters can be done with the grid-based splash, as well. Of course, it’s possible to adjust the splash domains size, rotation and position to your individual needs via the Node panel. Other options are defining an Initial State, reading out values from the Statistics panel and using Display parameters for managing the fluid’s look in the viewport.

a. The Grid Fluid splash panel

This is the place where all splash creation parameters are adjusted. The number of splash particles strongly depends on these settings, but also on the grid domains “Resolution” value. An effective way to increase the number of splashes is to create more turbulence within the core fluid, for example with collapsing columns of grid fluid particles.

Emission rateThis value tells the fluid engine how many times per second the grid fluid is examined to look for low resolution areas that have to be refined. You may remember that the core fluid itself cannot achieve enough resolution to produce the fine details, which are necessary for a believable simulation. By default, “Emission rate” is set to 10.0. Higher values will create more splash particles.



Introduction | 78

Detail threshold“Detail threshold” can range between 0 and 1 and it’s a very “technical” value, connected to the grid’s resolution. As mentioned before, the fluid engine is always looking for low resolution areas. If the solver has detected such a zone, Hybrido refines the grid internally to produce the fine splashes. “Detail threshold” can be seen as the sensitivity of this process. With 1, Hybrido can detect almost any low resolution area in the scene, while 0 only produces splashes in zones with a high need for detail. So with this parameter it’s also possible to reduce or increase the final amount of particles.

Angle thresholdOnce the “Detail threshold” criteria for splash generation has been fulfilled, there’s another value to control the spawning of particles: “Angle threshold”. The idea behind this parameter is to check only those parts of the fluid that are moving in the direction of the fluid’s surface. Once a potential splash particle has been detected, Hybrido checks if it meets the adjusted “Angle threshold”. If this check is successful, the particle will be generated and inherit the velocity of the corresponding core fluid particle. The unit for “Angle threshold” is degrees. 90° means that Hybrido checks for splash particles between 0° and 90°, while 0° tells the engine that the valid angle really is 0°.

Min # childThis is truly a very useful parameter to avoid regular patterns. “Min # child” determines how many particles are at least created per grid cell point.

Max # childThis parameter is directly connected to “Min # child” and represents the maximum number of splash particles created per grid cell. The absolute number ranges between both values.

Position variationThe position of the splash particle can be modified randomly using a variation. This parameter indicates the maximum variation of the particle’s position. The random value is generated between 0 and this value. The unit of this parameter is meters.

High resolution splash creation from 2 collapsing and colliding piles of grid fluid particles.

Regarding “Min # child”, “Max # child” and “Position variation” further explanation is required, because these parameters are in close relation to a splash emitter’s “Resolution”. The number of particles that can be created inside a certain volume is limited, depending on “Resolution” So in some cases, the entered values can not be reached. The reason lies in RealFlow’s method of calculating a particle’s radius of influence:

radius = 1 / (10 · resolution1/3)

If the entered position variation is very small, for example smaller than the given radius, then you’ll only get a limited number of particles.



Introduction | 79

Angle variationAnother setting to suppress regular patterns. It is related to “Angle threshold” and uses degrees, too. Use this setting for applying a random number that’s between 0 and the entered value.

Velocity variationThe last setting for avoiding regular patterns randomly modifies the original particle velocity, and uses the entered value as the maximum variation. The unit of this parameter is given in m/s.

Foam strengthAs mentioned before, a splash particle dies when reaching the core fluid. With an existing foam emitter, the splash particles create foam at this point. With “Foam strength” you can control the amount of foam. Foam particles are also capable of generating texture maps that perfectly match the fluid’s surface.

7.08 Grid Foam emitterThis type is also completely automated and the generation of particles is closely linked to the grid splash emitter. When splash particles hit the surface of the core fluid they are destroyed. At this moment they’re capable of producing foam. So actually foam particles are tertiary particles, because they cannot be created without the presence of a splash emitter. RealFlow knows several parameters to control strength and visibility of the foam. Like splash, the grid foam emitter has its own domain represented by a box. Foam particles are created at the surface of the fluid, but if you are generating a surface displacement with the grid domain (see page 73 and the following) they will follow this displacement.

Foam must be linked with a domain in order to become created and any splash, attached to the domain, will generate foam.

Foam particles are only generated within this domain, but can escape from it, as well as the higher-ranking grid domain of the core fluid. Foam particles are true traditional fluids

and can interact with various daemons. Different foam domains can be added and placed inside the grid fluid domain and computed on different machines at the same time.

There are two methods to create foam. Both methods can be combined easily and even used at the same time. The first option is based on particles, similar to foam maps from RealWave, the second can use already existing maps. It’s possible to either create particles from these maps or directly use them as a texture. The output of the grid foam node is a grey-scale image in the case of using a texture. If the chosen format allows 16-bit then this depth is used to store the foam’s density, if not then you’ll get 8-bit images. For areas far away from the camera it’s often enough to use maps instead of particles.

u Foam particles are often linked to gravity daemons, but this connection is not always wanted – due to gravitational attraction, foam particles might accumulate in the valleys between waves, leading to an unnatural look.

Foam particles are stored in the standard BIN file format. The “normal” attribute per particle that you can read from the file is a vector indicating the direction of the surface. Creating a mesh around foam particles gives interesting results and the impression of real 3D foam on top of the waves.

u The Node, InitialState, Particles, Statistics and Display tabs are the same as for standard emitters. For more information and the individual settings, please visit page 95 and the following. Aside from these panels, there’s also the Grid Fluid Foam window containing the emitter specific parameters.



Introduction | 80

a. The Grid Fluid Foam panel

The creation of foam is bounded to a variety of parameters and it’s even possible to generate these particles from images or bake them into textures. This versatile behaviour is controlled with the following parameters.

Radius thresholdFoam particles are generated from splashes and this parameter determines the minimum radius of the splash particle that is able to produce foam. Splash particles with a radius below this value cannot contribute to foam anymore. That’s not only interesting for controlling the amount of foam, but also if you want to use mist to fragment the splashes: The basic idea is that after the fragmentation into mist, the splash particles are so tiny that they won’t create more foam.

BoundedBy default, “Bounded” is set to “No”, and foam is created inside the entire grid fluid domain. By setting this parameter to “Yes”, RealFlow only takes the outlines of the foam domain’s box into consideration. By adding multiple bounded foam emitter nodes you can directly control where foam particles will be created.

Calculate particlesBy default this parameter is set to “Yes” to enable the particle-based creation of foam.

@ detail thresholdHere you can define the particles’ distance from the grid fluid surface. This parameter is closely linked to the mesh’s “@ detail threshold” value, but has an option to place the particles a little bit above the fluid surface.

@ min lifetimeIn contrast to splash particles, which are removed by hitting the surface, foam is preserved. With this setting it’s possible to define a minimum value in seconds for its life-span.

@ max lifetimeSpecify the maximum amount of seconds for the foam particles’ existence. RealFlow calculates a random value between “@min lifetime” and “@max lifetime” to achieve a realistic and randomized vanishing of the foam structures.

@ min friction/@ max frictionThe actual friction value lies between these two values and specifies what amount (in percent) of the grid fluid’s velocity will be transferred to the foam particle. A value of 1.0 means that the entire velocity is transferred and this means that the foam particles are stuck to the grid fluid. A value of 0.0 indicates that the foam particles aren’t affect by the grid’s fluid’s velocity at all.

RealFlow foam: particle representation and the related mesh (RFRK mesh).



Introduction | 81

Create particles from image... This button opens a browser dialogue giving you the possibility to select an image that will be used to place foam particles on the surface of the grid-based fluid. Please note that only the red channel in the case of multi-channel images (for example RGB) will be used. A pixel value different from 0 will trigger the generation of foam particles. The image is projected on the surface of the grid-based fluid using the XZ plane of the foam box, so please mind your axis setup. The number of particles to be created depends on the resolution of the foam emitter: the higher the resolution, the more particles will be created.

With this function it’s recommended to create an initial state for your grid-based foam and reset to it, otherwise the position of the foam particles will not properly match the underlying grid-based fluid.

Calculate textureThis mode allows you to store a grayscale texture map for each simulated frame. Calculating a texture map is a computationally intensive process and should only be activated when you really need it. Activating this feature is only one half of the process. To store the maps this feature has to be activated under Export Central (look under “Particle Emitters”). You can choose between four different image formats: BMP, JPG, TGA and TIF. If the selected format is capable of 16-bit (e.g. TIF), the texture will be saved as 16-bit grayscale, otherwise the 8-bit mode is used.

u Foam-maps and textures made from RealFlow particles often require a certain amount of post-work with appropriate image processing programs. Map sequences can also become assembled to video files, showing the motion of a foam layer.

@ resolutionIn RealFlow texture maps are always square, regardless of their origin. Therefore this concept is also valid for foam maps. Whatever shape your grid fluid domain might have, the resulting texture map shares equal side lengths. For that reason there’s only one value available. By default a foam map has a size of 256 x 256 pixel, but in most cases that’s not enough. Very large texture maps might slow down RealFlow’s simulation process.

@ diffusionReal foam shows areas of high and low concentration. Between these areas, foam flows in and out creating the typical patterns. “@ diffusion” simulates this process and in technical terms it’s the rate per area unit at which foam moves between these zones.

@ dissipationUnder real conditions foam disappears depending on the surrounding conditions, like weather, wave height, or pollution. With “@ dissipation” it’s possible to make foam last longer or disappear very fast to mimic these environmental influences. Higher values will keep the foam longer.

Create texture from image...Similar to “Create particles from image...” this button again opens the file picker dialogue to load an image. This picture will be projected on the fluid surface in XZ direction. When you work with this function, only the red channel from RGB images is used. The pixel values represent the foam’s density.

7.09 Grid Mist emitterMist is the third grid emitter type and very important for believable mid or large scale simulations. It is produced when a fluid droplet is fragmented into smaller droplets. This fragmentation process is known as “droplet breakup” and is characterized by the ratio between aerodynamic forces and the droplet’s surface tension. Large water droplets have weaker surface tension forces compared to aerodynamic forces, so they have an increased chance of splitting into smaller droplets. Though we’re talking about droplets here, it’s important to know that mist cannot be exported as particles. In RealFlow, mist is the graphical representation of a density field and hence completely different from splashes and foam. You won’t, for example, find any particle-specific parameters, such as “Viscosity” or “Density”.

Since mist is a consequence of fragmented splash particles, the presence of a grid splash emitter is essential. Mist creates a fog-like density field around the fluid and RealFlow is capable of displaying it in realtime. Support for loading and rendering this density field is also implemented in Next Limit’s RealFlow RenderKit.

But there’s a little more to know about the creation of mist. When mist is generated from a cached splash sequence, mist modifies the original splash simulation and often particles will be removed. RealFlow keeps a copy of this sequence, which is also called “primary”. Under Display you can find a corresponding parameter to show the original splash particles instead of the modified version. The “children” of these primary fluids even show up under Export Central and you can also save more than one version.



Introduction | 82

Like any other grid fluid emitter, mist is also produced within its own domain. To distinguish the mist domain visually from the other particles spaces, it looks a little bit different. Similar to grid fluid domains, a mist domain shows small cubes at its corners. The only difference is that the mist domain boxes are placed exactly at the corners of the box, whereas a grid domain’s cubes are located inside. Smaller cubes indicate higher resolution and more accurate results.

Mist clouds in combination with grid fluid particles and without any other particles. Splashes are hidden!

It’s already been indicated that mist requires a certain workflow and the presence of some grid fluid nodes:

1. Add a grid fluid domain to the scene.2. Since mist is generated from splashes, a splash emitter is required as well3. Make the mist emitter exclusive to the grid fluid domain to prevent the particles from

getting through objects or even the grid-based fluid. Only the grid fluid domain stores the information about which parts of the simulation act as air, fluid or obstacle.

4. Optionally you can add daemons, like wind, noise or vortex to the scene, because these forces play an important role in the generation and vanishing of mist. They create a velocity field which is important for the breakup process of the splash particles. The relative velocity of splash particles is a decisive factor.

u Node and InitialState work exactly as described with standard or other grid fluid particle emitters. Please visit page 68 or 95 to find out more about these parameters.

a. The Mist panel

Mist creation is very complex process and computationally intensive. Therfore it’s advised to have a close look on the parameters and their dimensions.

ResolutionThis parameter determines the accuracy of the shown density field. Since mist is a grid-based phenomenon, “Resolution” is directly connected to the number of grid cells. The small boxes at the domain’s corner represent this value graphically.

SolverYou can choose between “Stable” and “Fast”. The first option always works reliably, regardless of the adjusted “Resolution”, “Diffusion” and “Dissipation” values. The second one, “Fast”, can be used with some specific combinations of the three values. Unfortunately, this is a matter of trial and error, but with the right configuration, this mode is much faster than “Stable”.

BoundedBy default, “Bounded” is set to “No”, and foam is created inside the entire grid fluid domain. By setting this parameter to “Yes”, RealFlow only takes the outlines of the mist domain’s box into consideration. By adding multiple bounded mist emitter nodes you can directly control where mist will be created.

DiffusionActually, diffusion works equal to the foam map’s “@ resolution” setting (see page 81).



Introduction | 83

It mimics the movement of particles between areas with high and low mist particle concentration. This movement creates typical patterns.

DissipationThis defines how fast the mist particles will disappear. The mode of operation is equal to the “@ dissipation” setting which can be found under grid foam’s texture map parameters (see page 81).

Strength“Strength” is closely connected to splash particles. When RealFlow has identified a splash particle that will be transformed into mist, the fluid engine transfers a certain amount of mass from the splash particle to the mist droplet. The transferred amount of mass is used to calculate the density field based on the mist domain’s resolution. So, for instance, if the cell volume of the mist field is 1 m3 and the splash particle volume is 0.05 m3, a density value of 0.05 is added to the mist field at the splash particle position. If the splash particle volume is 1 m3 then a value of 1 is added.

With “Strength” it’s possible to influence this process. “Strength” acts like multiplier for the calculated density value. With values greater than 1.0 you can increase the mist’s density; values smaller than 1.0 lead to a less opaque cloud.

Breakup thresholdRealFlow uses internal criteria to detect mist. It’s based on a physical breakup model that uses the splash particle radius and relative velocity. With “Breakup threshold” you’re able to shift the limits of this model. Please note that this parameter works in the opposite way to “Strength”! Values smaller than 1.0 create more mist particles, while settings above 1.0 reduce the amount of mist.

Radius thresholdAs explained before, the initial splash particle radius and mass are essential factors for the creation of mist. To finally generate mist, the fluid engine reduces the splash particles’ radius until the criteria for mist is fulfilled. This parameter specifies the minimum value of the radius that the splash particle is allowed to have, before it becomes mist and all of its mass is transferred. Please keep in mind that a value of 0.0 deactivates the creation of mist completely and conserves the splash particles.

Velocity ScaleSplash particles, turning into mist, are used to update the velocity field that advects the

mist’s density field. This is simply done by adding the splash particles’ velocity to the mist’s velocity field and the parameter controls exactly this influence. A value of 0.0 means that splash particles won’t contribute to this velocity field at all.

b. The Display panel

Mist emitters offer a variety of settings to visualize the density field at different quality levels. A “highlight” is a mist node’s capability to show a daemon’s force field. This can be achieved with “Show velocity field”.

Visible This switch is used to show or hide the grid mist emitter domain and its particles.

Domain You can choose from three different modes: “Box” is the default setting and represents the area of your scene where the mist is computed. Small boxes at the corners indicate the resolution of the mist. The “Points” option shows a point at the cells positions, giving you an idea of resolution and the places where mist is computed. If you don’t want to show any representation of mist in your viewports, select “None”.

Quality Displaying and updating the emitter’s density field in your viewports is computationally intensive if you have a high resolution mist. Additionally there are some graphics cards with strong memory restrictions being unable to show the mist at original resolution. For that reason you can select the quality of the mist field’s representation. Please note that this parameter only affects the visual representation and of course the internal resolution/quality is computed physically correctly.



Introduction | 84

Show velocity fieldFor evaluation and shading purposes it’s often necessary to visualize the mist’s velocity vector field. With this option it’s also possible to visualize a daemon’s force field. You can switch this feature on and off by choosing “Yes” or “No”. It was already suggested that you can make a daemon’s force field visible with this option.

A magic daemon’s force field in perspective and top view.

Please follow the these steps:

1. Add a daemon of choice and a mist node to your scene.2. Set the mist node’s “Bounded” option to “Yes” and rescale the domain, if necessary.3. Activate “Show velocity field”.4. Simulate the scene.

7.10 Hybrido IDocsCalculating certain parts of fluid simulations over a network is a completely new feature in RealFlow 5. The Job Manager now gives you the possibility to monitor and organize this process, while the IDOCs (“Independent Domain Of Computation”) are the elements responsible for preparing the fluids for network rendering. Each standard fluid emitter, including the grid fluid emitters for splashes, foam and mist, can be send to several

machines. But there’s a restriction: particles, rendered in network, cannot interact with each other and each emitter will be treated as an independent node. This is, for example, a convenient way to simulate side-by-side comparisons from a single scene.

For grid fluid emitters this workflow also has some great advantages, because in many cases you’ll restrict the creation of secondary particles only to certain areas of the grid fluid domain. These splash or mist domains normally don’t have to interact with each other to enhance realism. They can be treated as independent sources and simulated on different computers. Even mist can be spread over several computers, making it easy to calculate appropriate domains with high resolution. A set of networking tools makes it easy to spread simulations and a sophisticated Job Manager helps you to monitor everything.

For a convenient workflow, RealFlow provides these emitters also in an IDOC version. Before you can make use of this exciting feature, an IDOC must be added from:

Menu bar > Edit > Add > IDOC > Single or Multiple

You can use single domains, if the distance between the individual emitters is rather large, or a multiple IDOC node for emitters which are close together. A multiple IDOC allows you to subdivide the IDOC domain into several independent areas, based on a bounding object, for example a cube (other objects work as well, but RealFlow only takes their boiunding box volume into consideration – this means that it’s not possible to create a spherical or cylindrical IDOC, for example). Once you have created your IDOC areas, simply click on “Splash per IDOC” or one of the other nodes. RealFlow now automatically adds a new splash, foam or mist emitter and directly attaches it to the IDOC domain. Finally, you can relocate the emitters to the desired places and fix your settings, just the way you’re used to.

u You can read more about IDOC’s and the Job Manager starting on page 228. It’s also important to mention that network simulations require appropriate RealFlow licenses.

a. splash per IDoc

This option simply adds a splash particle emitter to an existing IDOC and to the Node window for making your settings. As long as there is no IDOC object in your scene, this function simply does nothing.



Introduction | 85

If you have to use a single object for some reason, remove the enclosing cube from the Global Links panel and make it exclusive to the splash emitter. Another workaround is the use of individual cubes or objects, serving as walls. These nodes can also interact with grid fluid particles without limitations.

The last speciality concerns the secondary particle emitters splash and foam. In the same ways as with standard fluid emitters, these types have a “Max particles” option. By default it’s set to 5,000,000. Standard emitters stop spilling out particles when this limit is reached, but grid fluid emitters are not affected by this parameter.

Standard fluid particles and grid fluid particles cannot interact with each other.

7.12 a Grid Fluid scene (Tutorial)The new Hybrido hybrid fluid solver opens up a whole new world of possibilities and is one of RealFlow 5’s key technologies. It makes it possible to create large scale fluid simulations including all the secondary effects you can observe in nature, such as foam and spray. The fundamental element in Hybrido is a customizable grid domain consisting of cells. The number of cells determines the fluid's resolution and indirectly the number of

b. Foam per IDoc

The mode of operation is exactly the same as for Splash with IDOC: create an IDOC domain and click on Foam per IDOC to add the emitter.

c. Mist per IDoc

Even mist particles can be simulated via a network and the proceeding is the same as “Splash per IDOC” and “Foam per IDOC”.

7.11 Notes about Interactions With Grid FluidsHybrido is a brand new technology and therefore even experienced users will have to learn how it behaves. For a better and faster workflow many of its specialities are explained here. A domain’s borders can neither be seen by rigid or soft bodies, nor by standard fluid particles. If you want to restrict an object’s movement to the domain it’s necessary to enclose it with other other objects, e.g. one or more cubes serving as walls. Exclusive links (page 24 and 25) will help to establish the appropriate connections between the desired fluids, daemons and objects.

Another relevant topic is interaction between grid fluids (core fluid, splash and foam) and standard fluid emitters. Though the secondary emitter particles act like standard fluids it’s not possible to simulate interactions between them and RealFlow’s traditional emitters. The different particle types will interpenetrate without any consequences, as seen below. To give you the possibility of simulating interactions between both types, Next Limit provides a plug-in to convert standard emitter particles into splash emitter particles.

Another restriction concerns grid fluid emitters (core fluid) which are completely enclosed by other objects. In this case the grid fluid emitter won’t be able to generate particles and the emitter will remain empty. An example: Imagine that you want to create a scene with a grid fluid and a splash emitter. The splash particles should remain within the scene, in this case the domain. For that purpose it’s easiest to enclose everything with a cube. The splash particles can be reflected from the cube’s walls and won’t leave the domain anymore, but there won’t be any core fluid particles created.



Introduction | 86

particles. This concept is exactly the same as with standard fluids: more particles create a better and more accurate simulation, but take longer to simulate. Other concepts are completely different: for example the level of detail, the amount of particles you'll need to fill a volume, and the files that will be exported to store the results.

Grid fluid simulations also require a certain workflow to get the maximum out of your computer resources. With Hybrido and its associated technologies, a simulation normally consists of several passes. The first pass is the creation of the core fluid. This part is very important, because the behaviour of the core fluid has a strong influence on secondary particle effects, such as splashes. This tutorial gives you an introduction to how to create a turbulent ocean scene with a rocky coast.

a. creating an ocean

For this scene, a landscape model is required. It's just a basic terrain object from a 3D program with a dimension of 50 m x 50 m. The height is completely up to you. Please don't forget to triangulate your object before you export it as an SD file to RealFlow 5. It's also important to use detailed ground structures, because they will be responsible for the turbulence of the fluid. The environment could look like this model:

The next step is the definition of the grid domain parameters. First, there are the dimensions - the horizontal expansion should match the size of the 3D model. In this case it's 50 m x 50 m. The domain height should be about twice the height of the 3D environment. In most cases, this height scale provides enough space even for turbulent splashes. The other parameters will remain untouched to see what will happen during

a first test. Grid fluid domains can be changed like any other RealFlow node: they can be scaled and repositioned, either with the mouse or the Node Params panel. To add a domain, simply select

Node Bar > Grid fluids > Domain

A grid emitter will serve as a particle source. To make it work, it’s necessary to define a volume, for example a Cube object.

Nodes Bar > Grid fluids > Emitter

Nodes Bar > Objects > Cube

We recommend removing the “Cube01” object from the Global Links panel to make sure that it cannot interact with elements of the scene. Once an object has been attached to the grid emitter, RealFlow excludes it from the simulation automaticallytrouble. Global and Exclusive Links play an important role with grid fluids in general and you'll learn more about this topic a little later. If the cube is not automatically linked to the emitter, the following action will be required:

GridFluidEmitter01 > Node Params > Emitter > Object > Cube01

The cube's volume will be filled after the first simulated frame, which iswhy you can't see any particles at the moment. Similar to standard fluids, you can choose between two modes of operation:

1. Volume-based particle creation2. Speed-based particle creation for a constant stream

The first method is RealFlow's default setting, which is what will be used here. The cube's default volume is currently too small to fill an entire ocean, so it has to be rescaled. The image on the following page shows you the dimensions and the positions.

As you can see, the cube is located a few units above the environment and the particles will simply fall down on the model creating lots of turbulence. To release the particles, a “Gravity” daemon is added; otherwise they'd simply stay within the cube object. A k Volume daemon is not required at the moment, because the grid fluid particles will remain inside the domain and cannot leave it.



Introduction | 87

The red box indicates the grid fluid emitter's volume.

Another setting concerns the environment model. Each object within a grid fluid scene has its own “Grid Fluid Interaction” settings (see page 149). There you have a parameter called “Raster mode” which is set to “Dynamic” by default. This setting should only be used for moving objects, but an environment is always static and should have the relevant flag activated. This setting has a significant influence on simulation time.

Now it's time to start the first simulation. You'll see that the calculation is really fast, but the particle resolution isn't sufficient. The fluid behaviour already looks impressive, but there are many things to improve. As already stated, the number of particles is one thing, but currently the fluid is simply sloshing inside the domain, and lacks swelling ocean waves. On the other hand, we have a really turbulent ocean surface, because of the rocky and rough ground used in the environment model. The solution to get travelling waves which collide with the rocks and cliffs of the underlying environment is a “Wind” daemon with an oscillating strength. This is a typical task for an expression (see page 252). The expression that is perfectly suited for the required wave type is:

a*(1-sqrt(tanh(b*(sin(t/c)̂ 2))))

“a” is the force amplitude that will produce a certain wave height. “b” determines the sharpness of the wind force pulse and “c” is the frequency of the pulse, also known as wavelength. To apply the formula, add a “Wind” daemon with

Nodes Bar > Daemons > Wind

Then, please go to:

Wind01 > Node Params > Wind > Strength > Right-click > Open curve

With this action you can open the Curve Editor (see page 242) and copy/paste the wave formula, but first you have to replace a, b and c with appropriate values. The dimensions of these values require some testing. For this scene, the inserted values can be seen below, but maybe you have to use slightly different values:

8*(1-sqrt(tanh(10*(sin(t/1.1)̂ 2))))

It has already been mentioned that grid fluid simulations have a slightly different workflow than standard fluids. Global and Exclusive links play an important role and now it's a good occasion to clear up the links. The following steps are not always necessary and the simulation will lead to correct results, but you should always follow this workflow with grid fluids. The reason is that the number of nodes can quickly grow and the entire scene setup might become totally confusing. On the other hand, some elements, for example grid foam, require exclusive links and therefore it's really a good idea to separate things and keep everything clear with Exclusive Links.

Now you can perform your tests and adjust things like scale, positions or force strength values. You'll also notice that it takes a while until the fluid starts behaving the way you'd expect it, forming these swelling and breaking waves you will recognize from real oceans.



Introduction | 88

To save time and computer resources, an initial state should be used, because then it's possible to start the simulation with an already useable state. Please keep in mind that the initial state has to be made for the grid domain, not the grid emitter. Instructions can be found on page 96. Though the instructions are for standard particles they can be used for grid fluids as well. When you're satisfied you can increase the domain's resolution and make an initial state from the desired frame. The final simulation will then start from this point in time.

b. Displacement

Before you start with the core fluid simulation, a useful addition can be made: displacements. This feature adds a statistical spectrum surface with cresting waves to the grid fluid simulation. The displacement information can also be exported as a sequence of image maps and then rendered in your 3D program. Another sophisticated feature is that it's possible to use the maps in combination with an OpenGL shader directly inside RealFlow 5 for a realistic preview.

The displacement information can be used any time without having to recalculate the entire core fluid simulation. Once it's applied you can cache the simulation and try out different parameters to create the look you want. The most important issue is to create plausible relations between the core fluid waves, the environment and the displacement. If you want to get familiar with the parameters then it's a good idea to experiment with a

RealWave surface first. The Statistical Spectrum modifier provides the same parameters, but can be calculated much faster. To activate a domain's displacement feature, please go to

GridFluidDomain01 > Node Params > Displacement > Calculate > Yes

In most cases, the default settings will give acceptable results, but if you want to make changes, feel free to do so. If you want to visualize the surface waves, just follow these steps:

1. Calculate the displacement information during the grid fluid simulation or in a post process.

2. Create a mesh from the simulation.3. Choose “Shader > Shader Type > Displacement” from the mesh's Node Params menu.4. Switch to “Smooth Shaded” mode under “Display”.

Just one note about the displacement shader: by default, the “UVW Mapping” parameter is set to “Top projection”. In this scene, the selection should be “Top projection (average velocity)”. With this setting, the waves will move with the fluid based on its average velocity. Now you can directly see the displacement, and the best thing is that you can influence the shape and characteristics of the waves even now. When you go back to the domain's displacement menu you can change the parameters to your needs and directly evaluate the results. Once you're happy with your settings, you can mesh the entire sequence.

Wave displacement of the mesh near the coast.



Introduction | 89

c. evaluating The simulation

In most cases, the standard setting of 200 frames won't be enough, because it takes some time for the fluid particles to reach the shore and form waves. Frame ranges of 300 or even 500 and more frames are absolutely normal. Another thing you should consider is testing whether your hard disks have enough free space. Simulations with 4, 5 or even 10 million particles will need lots of disk space. On modern computer systems the core fluid simulation will be performed very fast. Once the simulation has been finished it's a good idea to make a video preview and watch the result in realtime:

Menu Bar > Playback > Video Preview

Previews should also be made during the testing process to evaluate the simulation data in terms of wave speed and frequency.

d. splashes

When ocean waves break or collide with each other or rocks and other obstacles, the fluid dissolves into drops of various sizes. This is what we finally observe as splashes. From this description you can already see that splashes will be created under certain conditions and RealFlow 5 is capable of detecting these areas. Since grid fluids are not suitable for simulating these fine structures, the splashes are represented as standard fluid particles. So, a splash emitter is actually a standard emitter with all the relevant properties and parameters, but it depends on the core fluid simulation. With foam it's exactly the same, by the way. This also means that splash and foam particles will be saved as “normal” BIN files – the same format you already know from standard fluid simulations.

To define the areas where the splashes should be created, you can use one or more domains. In contrast to the grid fluid domain, the splash domain doesn't consist of cells. It just indicates the volume where something happens. Another difference is that splash particles can leave their domain and therefore you should add a k Volume daemon to remove these particles or a bounding cube to keep them. The splash emitter can be found under

Nodes Bar > Grid fluids > Splash

First, the global and exclusive links will be set. For this scene, a setup like the one in the image on the right should be used:

Now you can position and resize the splash domain to your needs. There will be some areas where it's not necessary to create splashes, which should be left out to reduce simulation time. In most cases you won't need splashes at the grid fluid domain's borders or in areas which are invisible for the camera. You can also add more than one splash domain and restrict the zones of creation to certain areas. Multiple domains can also be simulated as IDOCs over a network (see page 84 and 225).

The most important parameters for the creation of splashes are “Emission rate” and “Detail threshold”, because they're mainly responsible for the number of particles you'll finally get. The values will vary from scene to scene, but if you can only see a few particles, you should increase “Emission rate” and decrease “Detail threshold”. The emitter's “Resolution” also has a significant impact on the total number of particles. It's also used to determine a particle's radius for the creation of mist. Another very effective method to increase the number of particles is the “Split” option: you only have to set “Min # child” and “Max # child” to higher values to detect areas without a sufficient resolution and fill them with particles. Please also keep in mind that even a very high number of particles can only fill a certain volume. Once this limit has been reached, no more new particles will be created. Please also keep an eye on the emitter's “Max particles” parameter to make sure that you won't run out of particles. Here are the settings:



Introduction | 90

The value for "Resolution" is 250 here. Before you can start a new simulation pass, it's important to set the grid fluid domain's “Simulation” parameter to “Cache”. If you have used an initial state with the core fluid simulation then please don't forget to check if “Reset To Initial State” (see page 41) is active. Now you can hit the “Simulate” button and create the splash particles or you can go on and add foam and mist emitters.

e. Mist

When splash particles dissolve into tiny drops, you can see fog-like haze clouds. RealFlow is not only capable of simulating mist, but can also visualize these clouds of varying density in the viewport. Displaying mist is a true challenge and this is the reason why RealFlow offers a several levels of detail:

Grid Fluid Mist01 > Node Params > Display > Quality

Mist is an exception, because it doesn't consist of particles. It can be described as a density field that's represented as a cloud-like structure which can be made visible in the viewport. Mist has to be created before the simulation of foam. The reason is that mist can remove splash particles which then wouldn't contribute to foam creation anymore.

Like any other of the secondary particle effects, mist is also created in a separate simulation pass. Since mist is derived from splash particles, the associated emitter has to be set to Cache mode. If you have foam particles in your scene, don't forget to activate “Cache” for this emitter as well. Another important setting concerns the Exclusive Links panel. The mist emitter has to be linked to the grid fluid domain node and the splash emitter. Additionally, it's required to add the mist emitter to the Global Links window and establish a connection between this and the splash emitter. Mist can also be influenced by force daemons, and it's possible to create the appropriate dependencies. This is how the Exclusive Links panel should look now:

To trigger the creation of mist, a few parameters have to be adjusted. The first one is “Resolution”, which can be compared to the grid fluid domain's corresponding parameter. When mist occurs, you can instantly see the cellular structure; “Resolution” is responsible for the final quality of your simulation. Higher settings yield better results. The settings “Breakup threshold” and “Radius threshold” determine the amount of mist. With “Breakup threshold” you have to use smaller settings (< 1.0) to create more mist, while values above 1.0 reduce its amount. “Radius threshold” again depends on the splash particles' radius. Mist can be seen a cloud consisting of tiny droplets. So, the solver checks if the radius of the existing splash particles is small enough to create mist.



Introduction | 91

Once this radius is reached goes below the adjusted threshold value, the typical hazy clouds will be added to the simulation. In some cases it's not possible to see mist, even if your settings should create this effect. To make mist clouds visible, just increase “Strength”. Though the parameter has a physical background (see page 83), it can be seen as an “amplifier” to enhance the mist simulation.

The white spots near the coast are mist.

f. Foam

This is the last effect that will be added to this scene. Foam is another phenomenon that can be observed on water surfaces. In RealFlow, the creation of foam should also be realized in a post process, because it's faster to simulate the individual passes than putting

everything into a single scene. Since foam can only be generated from splash particles, an appropriate previous simulation is essential. Like any other grid fluid element, foam also uses the domain concept. By default, the foam domain is not bounded and particles will be created over the entire surface. To restrict foam creation to a certain area, please activate:

Grid_Fluid_Foam01 > Node Params > Grid Fluid Foam > Bounded > Yes

In this case, foam can be simulated on multiple computers as IDOCs – just as with splash particles. Please note that network simulations need appropriate licenses. For more information, please contact Next Limit Technologies' SalesDesk.

To follow the workflow, the emitter will be made exclusive to the grid fluid domain and the splash emitter, but there's one key difference: the foam emitter should not be affected by gravity to prevent the particles from gathering in the wave troughs. You don't have to worry about the behaviour of the foam particles without the influence of gravity – the foam marks will rest on the water surface. Exclusive Links should now look like this:

From the screenshot you can also see that the splash emitter is also in Cache mode. You should not forget to make this adjustment, otherwise the splash data will be (partially) lost when you start simulating again:

GridSplash01 > Node Params > Node > Simulation > Cache



Introduction | 92

Another thing to remember is the fact that foam consists of standard particles as well and they can leave the grid fluid domain. Hence a connection with the already existing k Volume daemon should be established.

The most important parameter to adjust is “Radius threshold” which directly depends on the splash particle's radius. As mentioned before, this radius depends on the splash emitter's resolution:

radius = 1 / (10 * resolution)1/3)

The “@ min lifetime” and “@ max lifetime” of the particles also determine the amount of particles you'll finally get. With turbulent waves and a rough ocean surface, the foam marks should stay longer than under calm conditions. During heavy storms, an ocean surface can even be completely white, especially near rocky coasts where the splashes will be constantly dissolved into smaller droplets. To get a first impression, it's a good idea to work with the default settings or only make minor changes. Here are the settings for the current scene:

The results are already very impressive and show rich detail. If you want to reduce the amount of foam, just decrease “Radius threshold”.

With a new technology it always takes a little practice and patience to get a feeling for the parameters, how they react to changes and how the individual parts interact. The current tutorial is simply a basic overview. Therefore, Next Limit Technologies has created a large

number of video tutorials with different scenes where you can study the results in motion. We recommend that you also visit the RealFlow Tutorials site here:

http://tutorials.realflow.com and http://www.realflow.com

Foam particles on top of the core fluid.

g. Grid Mesh

Splash and foam particles can be meshed with the RFRK meshing tool because they are standard emitters. A detailed workflow can be found on page 118. Mist cannot be meshed,



Introduction | 93

because it doesn't consist of particles, as mentioned before. So, what can be meshed is the core fluid simulation. To apply a grid mesh container, please go to:

Nodes Bar > Mesh > Grid mesh

Under Nodes you can now see the mesh node, which already contains the appropriate domain. If your scene contains more than one domain then you have to select them manually by right-clicking on the mesh container and choosing “Insert emitters” or “Insert all emitters”. With meshes, it's always a good idea to try out the default settings first to get an idea of what has to be changed. With the pre-adjusted values, the mesh will be created very fast and could look like this example:

All in all, this is already a very nice mesh, but you can also see that some particles are still “free” and not included in the mesh. This behaviour cannot be totally suppressed, because the grid fluid mesh uses a different method that's not based on metaballs. You also have to consider that coastal areas are normally covered by splash particles. If you can see a coarse mesh with clearly visible plateaus, then you have to increase “Detail threshold”. This value is responsible for the mesh's smoothness, but very high values can destroy the fine structures so you should only change it within a small range.

In most cases, “Auto polygon size” is absolutely sufficient, but if the mesh lacks detail, you can turn off this feature and define your own mesh size manually with “Polygon size”. You should be careful with this parameter as well, because settings smaller than 0.1

can create a huge amount of polygons, though the benefit isn't always visible. Finally, you should apply a certain amount of filtering to your mesh. This feature will iron out unwanted ripples and create a much smoother and more organic-looking mesh. The filters work exactly like their counterparts in the RFRK and standard meshes, and they're very sensitive. To avoid an artificial look, you should work with “@ Steps” values between 16 and 32 first. “@ Relaxation” and “@ Tension” don't have to be altered.

The linked domain doesn't provide any mesh-specific settings, as with the other mesh types. The grid mesh setup is a very fast and easy process, because there aren't many settings available. Nevertheless, the parameters work very efficiently and small changes can lead to a completely different look. Grid meshes are only there to represent the core fluid body. Structures, like cresting waves and smaller ripples will be applied with the “Displacement” function, and secondary particle effects will add the missing details.

Final scene with all particle types, a smooth mesh and a transparent OpenGL shader.



Introduction | 94

8 RealFloW eMITTeRs

In contrast to RealFlow’s new grid-based emitters, this type is suited for small to mid range simulations. These standard emitters show a very high level of detail, are easy to use and can be affected by any daemon to react with various forces. RealFlow emitters can interact with all kinds of solid or soft bodies and RealWave objects. Another, more advanced feature, is their scripting capability: RealFlow emitters can be completely customized and theoretically it’s even possible to write your own fluid engine.

Complex particle-object interactions with RealFlow 5.

An emitter’s particles can be stored in different file and data formats for further use. The standard format is called bin and stores a complete set of position and physical data. Other formats, such as PD, allow the user to store specific information, such as density or pressure. You can find out more about RealFlow’s export options with standard emitters on page 58 and 59, “Export Central”. The stored BIN files are normally used to create a polygon mesh inside RealFlow representing the three dimensional volume of the fluid. This mesh finally becomes shaded in your 3D application to render the fluid. Additionally it’s also possible to continue processing the particles to create foam or spray.

u If you’re working with Pixar’s RenderMan or compliant render engines for Maya or 3DStudio Max then you should consider using the RealFlow RenderKit (RFRK). Its advanced meshing and particle options are the perfect addition for processing huge

meshes or large particle amounts in production environments. For more information please visit the RFRK section on the RealFlow website or contact Next Limit’s sales desk.

RealFlow emitters are incredibly flexible. They’re not just particle sources, but also used to create splashes from interactions with RealWave and rigid bodies, calculate the behaviour of gaseous fluids, or produce millions of ultra-fast dumb particles to mimic spray, for example. With adequate Python scripts it’s also possible to simulate other natural phenomena, like fire, explosions or swirling smoke. Daemons and forces are added to shape fluids to your specific needs. You can even use animated objects and characters to emit particles from their surface or fill an object completely or partially with particles. With binary loaders you can even re-time, combine and manipulate already simulated particles.

As well as offering of many versatile applications, RealFlow emitters are both fast and very accurate. Especially interactions with particles from other emitters or solid objects are easy to use and it only takes a few mouse clicks to establish a connection. On the other hand you can create all kinds of combinations to make emitters, forces or objects exclusive to selected nodes. RealFlow’s particle interaction settings help you to refine a fluid’s behaviour in combination with solid objects.

Fluid-object interaction can create interesting patterns, e.g. an imprint of a rolling tyre.

Emitters can be added easily from various sources:

Edit > Add > Emitter > Choose the appropriate typeIcon bar > Emitter > Choose the appropriate typeRight click menu > Add > Emitter > Choose the appropriate type

Regardless of the method you use, you’ll always find a set of 14 emitter types.



Introduction | 95

8.01 common settingsRealFlow emitters provide various shapes and forms and each one is unique, but there are a couple of settings which are common to all emitters. These settings are responsible for the emitter’s position in RealFlow’s 3D space, parenting it to another node, but also for physical properties. The fluid-related parameters are of particular interest, because they finally determine the behaviour of a fluid and its “type”, for example water, alcohol or honey. Another field of application with these common settings is controlling an emitter’s visibility and information about important parameters, such as velocity. Some of the panels, described here, can also be found with daemons or other nodes, but with slight differences.

a. The Node panel

This part of Node Params contains everything that has to do with an emitter’s representation and orientation in the viewport.

u The settings under Node depend on the preferences for your 3D software package (see page 45). There you have to determine which axis serves as a height axis. For some programs it’s the Y axis, others use the Z axis.

SimulationThis setting offers three options to choose from – the default is “Active”. This means that the emitter (or any other object) can contribute to the currently opened scene, while “Inactive” disables the selected item. Inactive emitters cannot pour out particles. If the emitter is animated, you’ll see its movement, but without any influence on the scene. “Cache” is a very clever feature. It allows you to read already-simulated particle sequences and use them for further interactions, e.g. with rigid body dynamics. In this case you won’t have to calculate the fluid again and again in case of changes.

Position This setting consists of a trio of values. Each value represents one direction in space: X, Y, and Z. You can often find a certain notation for this trio: [ X,Y,Z ]. A position is always related to the scenes origin which is located at [ 0,0,0 ]. For this reason, it’s also allowed to enter negative values. Zero is, of course, valid as well!

RotationRotation works exactly the same way as position. Again, there’s a trio of values indicating the rotation settings in degrees for each axis. By default, an object has no initial rotation.

ScaleThis parameter determines the expansion of an object in 3D space. In the same way as with “Position” and “Rotation” you have to specify scale with three values. For some emitters, scale values are chained, e.g. the sphere emitter. This means that you’re not able to change the scale values individually from each other. Another exception are two-dimensional emitters, such as a circle or square. Since they have no physical height axis, height is always set to 1.0 and cannot be changed.

ShearThis is an interesting feature which makes it possible to deform the emitter’s basic geometry. By applying an appropriate factor you will notice that the nodes emission direction is affected, too, but that’s only valid for the viewport representation. Shear distorsion exclusively influences emission in the horizontal plane.

Pivot“Pivot” could also be called “centre of rotation”. By changing this point you can see a dislocation of the axes of coordinates. If the object becomes animated, the centre of rotation won’t be the centre of the object anymore – this will now be the new position of the axis of coordinates instead.



Introduction | 96

Parent toWith this setting you can attach the current object to an animated (keys or dynamics) item. The object will perform exactly the same movements as the parent body and follow its animation path. When you click on the hyphen, RealFlow will open a new window with all suited nodes.

ColorThis is the basic colour which will be used to display the emitter’s particles. If an emitter is selected, RealFlow displays a colour range for an attribute adjusted under “Display”. If the emitter is not selected, you’ll see all particles in grey by default. You can choose any available colour or RGB value from your operating system’s colour picker.

Xform particlesThis setting is only available for fluid emitters and only makes sense with animated emitters. You can see two options: “No” or “Yes”. “No” creates a particle trail behind the emitter, while “Yes” makes them following the emitter.

A moving emitter with “Xform particles” option “No” and “Yes”.

b. The Initialstate panel

This is a very useful function to create a kind of preset from which the simulation can be resumed easily. In many cases it’s necessary to create relaxed states for a fluid. Relaxed means that most of the fluid’s energy has been withdrawn and the particles are more less still. To achieve this state it’s important to perform a simulation allowing the particles to

settle. When the fluid’s surface is calm, you can create an initial state, resume from this condition and execute a new interaction, for example the impact of a body. An initial state can be saved at any time and the resulting file will be stored under the “initialState” folder of your project’s directory.

Use Initial StateThere are two options available with this setting: “No” and “Yes”. Yes allows you to use an initial state with the currently selected emitter, while “No” disables this possibility. Please note that initial states can be created individually for each emitter in your scene.

Make Initial StateThis is the button to create and save the initial state file which will be used to resume the simulation exactly from this moment.

To use an initial state with a simulation it’s not enough to activate “Use InitialState” –you also have to reset to this specific point. This can be done by tagging the “Reset To InitialState” option next to the Reset button. With the next reset, RealFlow will load the initial state file and the simulation starts from 0 again. Exisiting BIN files will be overwritten with a new simulation. Normally it’s not necessary to backup previously generated files, but if you need them, don’t forget to apply a new name for the emitter, for example.

Here’s the workflow:

1. Make an initial state with the “Make Initial State” button.2. Set “Use Initial State” to “Yes”.3. Activate the “Reset To InitialState” option next to the “Reset” button.4. Optional: Backup your previous data or apply a new export name for the emitter.5. Reset the scene to load the initial state at frame 0 (or any other specified frame).6. Simulate, using the initial state.



Introduction | 97

c. The particles panel

This panel is only visible with emitters and contains the fluid’s physical properties. Here you’re actually defining the fluid’s behaviour and final appearance. With “Particles” you can also specify which type of fluid you want to create: each type has its own special settings that will be available when you’re changing to another particle type. It’s possible to switch between RealFlow’s types at any time, but of course the fluid’s behaviour will change completely. Some of the settings can be found throughout all different types, others are unique.

TypeThis menu allows you to define the fluid’s behaviour. By default, RealFlow generates fluid particles used for all kind of liquids. Fluid particles can interact with other fluid particles and support self-collision. They are affected by any of RealFlow’s internal or imported objects, including RealWave surfaces.

RealFlow’s different particle types.

“Gas” is used to create substances like air. In this case the “Particles” menu becomes expanded and various temperature dependent settings are available. Gas particles tend to very strong expansion and high velocities. RealFlow gases are not grid-based and therefore behave completely different from other solvers.

“Liquid” is RealFlow’s standard setting and provide parameters for all watery or high-viscous substances. It’s surely the most often used type and is suitable for all kinds of particle-object interactions, but especially for small to mid-range simulations. For larger projects, you should consider using the new grid-based fluid solver. “Dumb” particles are perfectly suited for fast calculations of secondary effects, like spray or foam. Please keep in mind that these particles cannot react with each other and won’t be affected by other emitters.

“Elastic” establishes a so-called spring-mass system between the particles, making them behave like a soft body. This option can be used for interesting effects like jelly-like fluids or expanding an contracting substances. Please note that elastic particles are not ruled by RealFlow’s soft body solver – that’s a completely different system and can only be used with objects.

“Script” gives you the opportunity to write your own fluid behaviour with Python scripting, or the new SDK and C++. Choosing this type adds an “Edit” button to the menu. Clicking on “Edit” opens a new scripting window with a predefined function that’s used to enter your source code. By default, this window doesn’t contain any executable code. A detailed introduction into scripting can be found on page 268.

particles – liquid



Introduction | 98

ResolutionWith this setting you can increase or decrease the amount of particles, and therefore it’s one of the most important parameters. “Resolution” especially depends on scene scale and emitter scale, but it also affects the fluid’s mass and therefore depends on “Density”, too. By default, resolution is 1.0. A volume of 1 x 1 x 1 units filled with 1,000 particles has a mass of exactly 1,000 kg. In other words: Each particle has a mass of exactly 1.0 kg. By raising “Resolution”, an individual particle’s mass will be lowered and vice versa. You can monitor the relationship between mass and density under Statistics > Particle mass

Dependent on your scene, “Resolution” can dramatically increase, and values of 1,000 or even much higer are sometimes necessary. Another interesting issue – especially for scripting and plug-in development – is the relation between “Resolution” and a particle’s radius, ruled by this formula:

radius = 1.0 / (10.0 · Resolution1/3)

Density “Density” is defined as mass per volume unit and is expressed in kilograms per cubic metre [ kg/m3 ]. Water, for example, has a density of 1,000 kg/m3. “Density” is different for each substance and for some fluids, like crude oil or honey, there are only average values available, because they consist of variable amounts of ingredients.

u On page 323 you can find a list of densities for various important substances.

Int PressureEach fluid shows a more or less strong tendency to expand. With gases this behaviour can be observed best, but even liquid substances have this tendency. “Int Pressure” simulates the forces between nearby particles, and very high values make the fluid fill a greater volume. If “Int Pressure” is set to 0.0 the particles lose their fluid behaviour.

Ext Pressure This is “Int Pressure’s” counterpart and tries to limit a fluid’s expansion tendency. With very high values it’s possible to compress the fluid. Gases, for example, should have very low “Int Pressure” and rather high “Ext Pressure” values to prevent them from flying away. With both parameters it’s possible to fine tune a fluid’s appearance and behaviour, therefore they’re fundamentally important for a realistic simulation.

Int Pressure = 0.1, Ext Pressure = 10 Int Pressure = 10, Ext Pressure = 0.1

ViscosityEach fluid has a certain amount of viscosity, even water. It defines the tendency of particles to stick together. With very high values you can observe the typical strings in viscous fluids when they are torn apart. Substances with very high viscosity are honey, tar or syrup, for example. Fluids with low viscosity are alcohol, many solvents or liquid gases. Exaggerated settings can lead to misbehaving particles with high velocities.

Surface tensionOn a fluid’s surface we can observe forces that keep the outmost molecules together, creating a kind of skin. Some insects, such as water striders, can even walk on this tight skin. Surface tension can also prevent water from infiltrating cloth to dissolve the dirt. For that reason, detergents contain special substances to reduce the fluid’s surface tension”. These are called surfactants or tensides. A water drop’s shape is mostly a result of these forces.

InterpolationIn some cases it’s sufficient to raise the number of particles by selecting “Interpolation” instead of simulating the entire scene again. This feature gives you the possibility to generate more particles from an already cached BIN file sequence, but that’s not the real idea behind this feature: “Interpolation” was originally introduced to simulate until a certain frame with low “Resolution”, stop, adjust to a higher value and resume.

RealFlow analyses the fluid and places new particles where they will be safe. The new particles aren’t just filling the gaps, they completely satisfy the fluid engine’s equations.



Introduction | 99

RealFlow offers three options: “None”, “Local” and “Global”. Of course, “None” doesn’t create any new particles and disables this function. The second options creates the new particles only within the existing fluid cloud with rather high accuracy. Please keep in mind that there are always some particles that won’t fit. This is a good choice when the fluid should keep its shape. “Global” can be used when you don’t have to worry about the original shape. The new particles will be created with some tolerance leading to slightly fuzzy edges. This solution is perfect for larger amounts of fluids, for example inside water tanks.

Another important thing about interpolation is fluid-object interaction. If a fluid is close to an object, it’s very likely that new particles will suddenly appear inside the body. RealFlow does not check for collisions with objects and only examines the fluid.

Interpolation = None Interpolation = Local Interpolation = Global

Compute Vorticity Normally it’s not necessary to calculate this property and by default it’s set to “No” to save time. Vorticity is actually only needed for some shading effects and can also be calculated in a post process with the “Compute Vorticity” system script. If you want to add vorticity during the simulation, simply set it to “Yes”.

Max ParticlesRealFlow limits the amount of particles to 5,000,000, but this value can be changed any time, if you need more. Under “Statistics” you can see two entries counting particles

Statistics > Emitter Particles

“Max Particles” is connected to this value, and even if you currently have only 1,000 particles in your scene, but have already deleted 4,999,000 particles, RealFlow will stop creating new particles. “Max Particles” should also be raised if you want to use a Fill Object emitter. With insufficient particles the filled volume becomes cropped. Additionally you’ll receive an error message.

particles – Gas

u "Resolution", "Density", "Int Pressure", "Ext Pressure", "Viscosity", "Compute Vorticity", and "Max Particles" work as described under Particles – Liquid (page 97).

TemperatureTemperature plays a very important role with gases, because it directly influences their tendency to expand or rise. Very hot gases have a very strong tendency to expand and they raise quickly. A rising or expanding gas loses energy, becomes colder, and denser, and therefore starts falling.

In RealFlow, temperature is measured in Kelvin [°K]. The Kelvin scale is based on absolute zero point at roughly -273°C, which represents 0°K. A temperature of 0°C is 274°K, 100°C equals 373°K etc.



Introduction | 100

Ext temperatureThis is the temperature of an external static atmosphere. If this value is lower than "Temperature", the particles will cool down. A warmer environment will heat the fluid.

Heat capacityThis parameter controls the heat transfer between the individual particles of the emitter. A low value reduces the gas’s capability of propagating heat.

Heat conductivityThis is the ability of a substance to conduct heat. Good thermal conductors are generally materials with many free electrons, for example metals. A poor conductor shows low conductivity and is called an insulator.

particles – Dumb

u This type provides only three settings: "Resolution", "Density" and "Max Particle". All parameters work as described under Particles – Liquid starting on page 97.

particles – elastics

u "Resolution", "Density" and "Max Particles" work as described under Particles – Liquid starting on page 97.

SpringRealFlow creates virtual springs between the particles to achieve elasticity. The stiffness or softness of these springs is controlled with this parameter. Higher stiffness creates a

behaviour that becomes increasingly similar to rigid bodies. Though many terms may remind you on object dynamics, they actually have nothing (or very little) in common, because rigid and soft body dynamics solver work completely differently.

DampingIt’s always recommended to add some damping to the virtual springs between the particles to avoid vibrations or exaggerated results. Very low damping can affect the stability of the spring system, while high settings are able to slow down the motion significantly.

Elastic limitThis value is very technical and not easy to explain. It restricts the elastic behaviour of the elastic springs between the particles and is measured in percentage of the initial spring length (= 100%). A value of 120 means that the spring will lose its elasticity when it’s stretched to 120% of its initial length. At this point the spring becomes rigid.

Break limitThis value is related to a spring’s initial length. The spring connection between particles will break if the spring’s elongation reaches the adjusted value, also measured in percent.

particles – script

u "Resolution", "Density", "Int Pressure", "Ext Pressure", "Viscosity" and "Max Particles" work as described on page 98. For "Temperature" see page 99.



Introduction | 101

EditA click on this button opens an extra scripting window. It contains a few comments (introduced by a “#” symbol) and an empty function for introducing forces between the particles. This part can be filled with your script and RealFlow will execute the instructions to create the desired behaviour. Custom plug-ins for describing a certain fluid behaviour will also appear here. A plug-in can be added with RealFlow’s “User plugin manager...”

Menu Bar > Tools > User Plugin Manager...

d. The statistics panel

This panel helps you to monitor your scene and make the decision to increase “Max Particles”, delete particles on current velocity values, or adjust the colour range for RealFlow’s Display features. None of the entries is editable or can be changed. They’re for informative purposes only.

Existent ParticlesShows how many particles are currently available in the scene.

Emitted ParticlesDisplays the number of particles that have been emitted until now. If the number of emitted particles is greater than “Max Particles”, RealFlow stops creating new particles.

Particle massShows the mass of each particle in kg.

Min SpeedThis is the lowest speed measured.

Max SpeedHere you can get information about the highest speed. “Min Speed” and “Max Speed” are measured in m/s.

e. The Display panel

RealFlow provides a wide variety of different settings to visualize specific properties of a fluid. The settings under “Display” can be edited for each emitter separately and give you interesting and valuable information about a fluid or even a particle’s attributes. Different colours can also be used to mimic a certain behaviour or fluid type, e.g. fire or dust.

VisibleYou can choose between “Yes” and “No” to show or hide the emitter. Since the associated particles will also be hidden, this feature is perfectly suited if you want to monitor the motion of other bodes behind the fluid. You can also select multiple nodes and make them invisible in one pass.



Introduction | 102

Point sizeThis little feature lets you define the “thickness” of a particle in the viewport.

Show iconEach emitter is represented by an icon in the viewport and you can enable/disable it here.

Show arrowEach particle can be represented by an arrow indicating velocity and direction. The feature can be enabled with “Yes” and disabled with “No”. Since “Show arrow” visualizes the fluid’s vector field, programmers can use this feature for detecting misbehaving particles or exaggerated forces at certain points.

Arrow lengthThis setting assumes that “Show arrow” is set to “Yes” and defines the default length of an arrow.

PropertyRealFlow calculates fluids on many physical data. With “Property” you can make some of them visible. The range of values for each property will be colour-coded with “Min range” and “Max range”. You can choose between a variety of attributes. By default, Vorticity is not computed during simulation and should be activated first under

Particles > Vorticity

Automatic range“Yes” is the standard setting to create the colour gradient between “Min range” and “Max range”. The colours used for this purpose are shown in the “Min and Max range colour fields”.

Please don’t forget that the values aren’t normalized and this can lead to flickering effects while playing back the simulation. To avoid this it’s necessary to apply a normalizing script in a post process. Such a script analyses the entire particle sequence and limits the desired value to range between 0 and 1. This method isn’t only used in RealFlow, but also in other 3D applications to avoid shading problems because of huge differences, for example in velocity or pressure.

Min/Max rangeLets you manually adjust the minimum and maximum value for the selected property.

Values below or above “Min and Max range” will be visually clipped and represented with the appropriate “Min/Max range color”. When a fluid’s attribute only has mean differences you’ll hardly see a colour range. With ranges you should aim for better visual differentiation.

Min/Max range colorYou can select custom colours for the representation of the “Min and Max range” values. Clicking on the colour fields opens a picker from your operating system and you can choose any available colour from the RGB palette. This feature is often used to mimic certain fluid types, like oil, coffee, fire or similar.

FluidThis setting requires some explanation and is related to grid-based fluids, specifically splash emitters: you might have already read that mist is created from splash particles. In this process, the splash particles’ radius is changed and some of the particles are most likely removed. This action changes the splash fluid and you’ll get different results. For that reason it’s necessary to introduce a new concept, called “secondary fluids”. This subtype contains the modified splash particles, while the originally cached BIN sequence can be considered as primary. With “Fluid” you can visualize either the primary BIN sequence or the secondary modified particles. If you have more than one mist emitter attached, there’s an appropriate number of “secondary” entries.

The standard setting here is “Primary” and, by default, this is the only option. “Fluid” is exclusively related to grid fluid mist particles. Mist can be calculated from previously simulated splashes, for example from a cached BIN sequence. Since splashes are also standard fluids, it doesn’t make any difference whether you’re using a “real” splash emitter or any other type.



Introduction | 103

8.02 RealFlow emitter TypesEmitters can be separated into four basic groups, based on their functionality:

1. Standard fluid emitters2. Object-related emitters3. “Fibers”4. Binary loaders and containers

Binary loaders (Binary and N-Binary) and the Container node are in a separate category, because they don’t generate any particles. With them it’s possible to load a previously simulated particle sequence into a scene for further use. You’ll learn more about them later, starting on page 112. A container can receive particles, mainly in combination with a filter daemon. “Fibers” are a special case and they can be used to create all kinds of tentacles, algae or other filaments.

All the other types are able to generate particles, though some of them have certain requirements, e.g. an existing object. Standard emitters have a predefined shape from which the particles are poured out, while object-related emitters can accept any geometry. You can either fill an object’s volume with particles, for example, or use the surface’s polygons to spill out the fluid.

a. circle emitter

This emitter is surely the most often used type and suited for many different purposes. It can be scaled and also accept oval shapes, but it is not possible to perform any changes along the height axis – the vertical dimension will always remain 1.0. An arrow indicates the node’s emission direction and helps you to point the emitter to a certain target.

VolumeThis feature creates a defined volume of particles. The dimensions of this volume consist of the emitter’s scale settings and the value entered here, based on RealFlow’s grid units. By activating this option, the emitter’s speed value will be set to 0.0 automatically.

SpeedHere you can define the emitter’s initial speed. Higher values will generate more particles per frame. Faster particles act with stronger forces on other particles or objects. The number of emitted particles also depends on your resolution settings. A value of 0.0 disables the emission of particles. This value can be animated either with keyframes or expressions.

V/H randomBy default the particles are regularly emitted, showing a kind of pattern. The reason is that the particles are emitted as a homogeneous stream. To avoid and suppress this pattern, it’s possible to randomly displace the particles with these functions. The values should range between 0 and 1, but can be higher, as well. “V” stands for vertical, while “H” means horizontal.

Ring ratioThe standard emitter generates particles over the entire area. With “Ring ratio” you’re able to define a ring from the particles will be emitted. The value determines the ratio between the inner and outer radius. Small values create a larger area, larger settings are responsible for thin rings.

Ring ratio examples: 0.25 1.0 0.5

Side emissionNormally the particles are poured out along the emission axis. With this parameter set to “Yes”, a radial emission is performed from the outline of the emitter and the circle’s inner area remains empty.



Introduction | 104

Fill sphereSince a sphere is a 3D object, it can be entirely filled with particles. By setting “Fill sphere” to “Yes”, “Speed” is set to 0.0, but it’s also possible to initially fill the sphere’s volume and apply a new speed value afterwards. In the image, the left sphere creates particles from the surface, the right one is filled.

d. linear emitter

Linear is a two-dimensional emitter in the shape of a straight line. Therefore it’s not possible to alter any height information: only length can be changed. Particles are emitted in the direction of the green arrow from the “underside” of the line. The result is a thin, curtain-like stream of fluid.

HeightThis parameter has nothing to do with the emitter’s physical height, but is comparable to “Volume” and creates a rectangle filled with particles. When “Height” is adjusted to any value other than 0, “Speed” becomes disabled.

LengthIt’s recommended to change the emitter’s length with this parameter, instead of using the scale settings under Node. Scale is available, but works like a multiplier, if “Length” is activated: an emitter with “Length” = 3.0 and “Scale X” = 2.0 has a total length of 6 units.

b. square emitter

Square emitters actually have exactly the same properties and characteristics as “Circle”, with one exception: with this emitter it’s not possible to adjust something similar to “Ring ratio” – Square emitters always create particles over the entire area. For the emitter’s adjustments under Node Params, please visit the appropriate manual section under “Circle”. Square emitters can be scaled with the Node panel’s “Scale” settings and you’re also able to create rectangular shapes.

c. sphere emitter

This is a three-dimensional emitter type and you can set values for all three coordinates. Please note that the scale values are linked and it’s not possible to adjust three different settings for X, Y and Z. By default the particles are emitted from the sphere’s surface, but there’s also an option for filling the entire volume. In the second case, the result is identically to a “Fill Object” emitter.

SpeedAs always, “Speed” sets the initial velocity of the particles at creation time. Animated “Speed” values are often used to create all kinds of interesting effects.

RandomnessThis parameter can be used to avoid patterns and regular structures by displacing the particles randomly at creation time.



Introduction | 105

To give you a better understanding of this emitter, it’s necessary to know its parts and elements – a description of the individual handles follows:

RealFlow’s spline emitter provides various control elements for precise handling.

SpeedAs usual this parameter defines the speed of the particles at creation time. Please remember that higher speed values create more particles.

V/H randomThese settings add a certain amount of randomness to the emitted particles to avoid patterns.

e. Triangle emitter

This emitter creates particles within a triangular area and has exactly the same properties and restrictions as the “Square” emitter. Please visit page 104, “Square Emitter” for more information and settings.

f. spline emitter

Spline is a very interesting emitter with many fields of application. Its shape can be adjusted with control points (CP) and tangents using the “Move” tool. This type can be seen as a hybrid between an emitter and a daemon, because you can add forces that influence the particles. A standard spline emitter shows three control points, surrounded by yellow circles. These circles represent the zones of influence of the various forces. Each of these zones can be adjusted individually and it’s also possible to add or remove control points. Control points can also be animated, but it’s better to use a parented helper object, e.g. a Null for this purpose, instead of manipulating them directly. Of course, you can apply any particle type (fluid etc.) to the spline emitter. Changing and adjusting a spline emitter’s shape takes a little practice, but if you’re familiar with splines from other programs, it shouldn’t take very long to achieve full control. Moving one control point affects the shape of the entire spline.



Introduction | 106

Axis Tube Edge

RandomnessTo avoid a uniform look, the particles can be randomly displaced while leaving the emitter.

Kill leavingParticles will be automatically deleted while leaving the yellow circles.

EDITThis is the button if you want to change the positions and settings of control points. If the edit mode is enabled, the button turns yellow and the parameters become accessible.

Insert CPThis button is used to create a new control point (CP). To add a new point it’s necessary to select an existing point first. A new point is always created above the selected one. Custom points share exactly the same features and as their default “counterparts”.

Delete CPSelect a control point and click on this button to remove it. Adding or deleting a control point might change the spline’s shape! Please note that it’s not possible to delete the three default points. This action only affects subsequently added points.

@ CP indexThis field indicates the index of the currently selected control point. By entering a (valid) number you can jump directly to the desired point. Indices are enumerated from bottom to top.

1. The small yellow dots are the spline’s control points.2. Each yellow circle shows a control point’s radius. This radius can be seen as the

zone of influence of the control point’s settings and parameters. Particles can also be deleted when leaving the yellow circle.

3. The light blue arrows indicate the emission direction for each control point.4. The straight line from up to down represents the spline’s curvature or path. It will be

adjusted dynamically while moving the control points.5. The dots at the beginning and the end of the spline are tangent control points. They

can be adjusted independently from each other.

AffectThis feature is normally only available with daemons (see page 128), but since the control points are able to exert forces on the particles, it’s necessary to introduce the options here. Particles can be affected in two ways: Either by “Force” or “Velocity”. The first option applies an external force, resulting in an acceleration, while the second one only modifies the velocities of the particles without introducing an additional acceleration.

“Forces” takes a little time to display their full influence. This means that they accelarate the particles over a certain time span, depending on their strength. High forces exert stronger accelerations and the particles or bodies become faster and faster as long as the force acts on them. The result is a curved stream of particles.

“Velocity” directly affects the particles from the very beginning without any delay or deceleration. The result is an apparently stronger influence, because the deflection of the particles starts from the very first moment. In this case the result is a linear, diagonal stream of particles.

CreationYou can choose from three different options: “Axis”, “Tube” and “Edge”. Particles are always influenced by a control point’s settings, such as radius. “Axis” works similar to the “Linear” emitter (see page 104) and the entire spline is used to create particles. “Tube” creates a hose around the spline and with the “Kill leaving” option you can create a tube that’s limited by the control points’ radius settings. “Edge” can be seen as a circular mode. The radius of the first (lowest) control point acts like a circle emitter, creating particles in upward direction parallel to the spline. Please have a look at the images on the right.

SpeedThis setting determines the speed of the particles during creation time.



Introduction | 107

@ CP axialThis parameter introduces an axial force along the spline’s path near the selected control point.

@ CP radialWith this setting a radial force is added near the selected control point.

@ CP vortexYou can also create a vortex force around the currently selected control point.

@ CP radiusAlter the radius of the zone of influence for each control point individually. The radius is indicated by a yellow circle around the control point.

@ CP rotationUse this parameter to change the emission direction. The light blue arrow, indicating this direction, becomes rotated around the spline’s path. This is great to create twisted emissions and avoid patterns.

@ CP linkBy clicking on the hyphen, RealFlow opens a new node picker and you can choose the object that the selected control point will be parented to. You can even select animated objects to externally control the particular point – typically a control point is linked to a Null object. This workflow is much easier than directly changing the point’s position with the move tool.

g. cylinder emitter

This is again a three-dimensional emitter and the particles are radially emitted from the outside of the cylinder. The cylinder is represented by two circles, which define its length. Please note that it’s not possible to fill the emitter or create volumes. Radius and height can be controlled via the node’s scale settings.

u The only settings are “Speed”, “V random”, and “H random”. For more information about these parameters, please have a look at the Circle emitter’s characteristics on page 103.

h. Bitmap emitter

Bitmap gives you the opportunity to either load a single image or an entire image sequence used as an emission mask. You can choose any black and white TGA, BMP or JPG picture. Please note that RealFlow does not take any grey shades into consideration to adjust the emission rate. Even pictures with 256 shades of grey are treated as black and white images. This means that there are only two possibilities: either full emission or no particle creation at all, while the particles will be emitted from the non-black parts of the image. Please make sure that the file formats are supported by next limit and share a common extension.

Emission maskOpen RealFlow’s file picker to choose a single image or a sequence from a folder and attach it to the emitter. If you want to use an image sequence, all the other images must be stored in the same folder and contain a five-digit file padding.

File listThis parameter contains four entires. The default option is “Single”, which should be used if there’s just one image you want to make emit particles. “Sequence-end” loads a series of images and the emission will stop with the last file. “Sequence-keep” stops with the last image, but this final bitmap will continue generating particles. “Sequence-loop” simply



Introduction | 108

creates an endless loop and once the end is reached, RealFlow starts again with the first image.

Number of filesThe length of an image sequence can be adjusted here by specifying the last frame’s number.

AffectThe standard setting is none, the second option is “Viscosity”. This means that you can actively affect the fluid’s viscosity from the attached bitmap’s black/white distribution.

Val min/maxWith Affect > Viscosity turned on you can specify a minimum viscosity value, represented by the black pixels and a maximum value, represented by white pixels.

Volume As usual this parameter creates a volume filled with particles. The outlines of the white areas represent the volume’s borders, while the entered value determines its height.

SpeedThis value defines the speed of the particles at the time of creation and is only available when “Volume” is set to 0.0.

V/H randomYou can add some random displacement in vertical/horizontal directions to avoid patterns.

i. object emitter

Though RealFlow offers a wide variety of different emitters, they’re sometimes not flexible enough and it’s necessary to transform some custom geometry into an emitter. The outside polygons (faces) of the object will be used to create the particles. Normals play an important role here, because they determine the direction of emission. By default, the normals point outward, but it’s also possible to flip them and fill an object gradually. Please note that some particles might penetrate the surface in spite of adequate settings!

You can declare any item as an object emitter, regardless of whether it’s native or imported. The only premise is that it has to be triangulated, but that’s valid for any geometry inside

RealFlow. For even more flexibility it’s possible to select certain polygons or vertices for emission.

ObjectTo make an item creating particles it has to be defined as an emitter, of course. This function opens a node picker to select any available object from a list. Please note that you can only choose one object at a time. Multiple selections are not allowed.

Parent velocityAn object, meant to emit particles, doesn’t necessarily have to be a steady object it can also be animated or obey the rules of rigid body dynamics. If the emitter object is moving, RealFlow takes a certain amount of its velocity and transfers it to the particles during the state of creation.

Distance thresholdHere you can determine how far away the particles should be from the object’s faces during birth. This produces a visible gap between the particles and the object’s surface. The dimension of this value is measured in RealFlow grid units.

Jittering The arrangement of an object’s polygons always leads to unwanted patterns in the fluid. To avoid this, “Jittering” can be used. It ranges between 0 and 1 and adds randomness to the creation process.

SpeedThis value defines the speed of the particles at the time of creation.



Introduction | 109

Selected faces Selected vertices

j. Fill object emitter

This neat emitter is a true all-rounder. The emitter subdivides any object into a certain number of cells – a process that is also known as rasterization. The cells are then filled with particles representing the object’s volume. The higher the emitter’s resolution, the better the result, because resolution directly affects the number of grid cells. That’s the reason why you can see jagged lines at the fluid’s edges.

You have to be careful with double-walled objects. In this case only the space between the walls be filled, while the innermost volume remains empty. This often leads to confusion, but is not a malfunction of the emitter. Especially with low resolution values, you can sometimes hardly see the particles filling the object. To get a better impression and simulation result, raise “Resolution” to (much) higher values.

RandomnessYou can randomly vary the speed of the particles to avoid regular patterns. “Randomness” accepts any positive value, but as always you should avoid extremely exaggerated values in RealFlow. With very high values the particles might explode.

Smooth normalsThis function makes the particles follow the smoothed normals of the object’s surface. It’s recommended when the emission appears to random or fuzzy.

Use textureImported objects from SD files can be textured with a black and white image map. Similar to the bitmap emitter, the white areas will generate particles, while black pixels remain empty. Grey shades are considered as white pixels. If the item contains UV coordinates, they will be used for texturing.

Select FacesAs mentioned initially, you have the possibility to select particular polygons from the object and there are two ways to do this: The first method is to click on the desired face. Multiple selections are supported by pressing the Shift key. You can deselect faces by clicking on them with the pressed Ctrl (WIN/Linux) or Cmd (OS X) key.

Please note that “Select Faces” does not recognize hidden polygons by default. Everything what’s under the mouse pointer will be selected, but you can activate a function to limit a selection to polygons visible to the user:

Edit menu > Back culled selection

Another way is to hold the left mouse button and drag the mouse over the desired area. This will create a rectangular selection, including faces hidden to the viewer. Once you’re satisfied with your selection, deactivate “Select Faces” to confirm your choice and avoid unwanted changes.

Select VertexThis button works exactly like the “Select Faces” feature, but is limited to points.

Clear SelectionYou can clear the entire polygon and/or vertex selection with a single click on this button.



Introduction | 110

Another important thing to know about this emitter is that the particles are regularly arranged according to the given volume. If you add a gravity daemon, for example, the particles will collapse and the resulting fluid volume becomes smaller, because it’s not relaxed. This effect can be compensated with higher “Int Pressure” settings.

ObjectThis option is essential for the making the emitter work. You can choose any object from the appearing node list, but you cannot make multi-selections – only one object per emitter is allowed. Once an appropriate selection has been made, RealFlow unlocks a few more settings.

Fill volumeBy default this option is set to “No”. If you want to fill the previously selected node, simply switch to “Yes”. This action activates more parameters and simultaneously locks the “Particle layer” field.

fill X/Y/Z ratioThis emitter allows you to create particles along certain axes. It’s possible to combine all axes using different values to achieve partial filling. A value of 0.0 means that there are no particles in a certain direction, while 1.0 entirely uses the selected axis.

remove # layersWith this function it’s possible to delete particle layers from the outside to the inside. This creates a gap between the object and the fluid.

jitteringLike any other emitter, “Fill Object” uses a regular particle distribution and this leads to sometimes unwanted patterns. “Jittering” adds random displacement to the particles to

give a more natural look. The allowed values range between 0.0 and 1.0 for maximum randomness.

@ seedThis value is directly connected to “Jittering”: whenever a random value is used, it’s necessary to define an initial value and that’s called “seed”. It influences the way the particles are distributed and by changing “@ seed” you can easily achieve a different look.

Particle layerThis feature is only available when “Fill volume” is set to “No”. Instead of filling a volume, “Particle layer” regularly spreads particles over the node’s surface. The look is actually exactly the same as with the object emitter, but “Particle layer” doesn’t create a constant particle stream.

k. Fibers emitter

This emitter is something special, because it’s completely different from all the other types. With “Fibers” you can create filaments from an object’s vertices. These filaments are oriented along the surface’s normals. In contrast to RealFlow’s other emitters, there’s no constant emission of particles. All particles are arranged along a linear path and forces are used to disturb them.”Fibers” can be influenced by any daemon. By default, the standard particle type is set to dumb.



Introduction | 111

ObjectIt’s necessary to select an object first from where the fibres are created. This function opens an object picker with all suitable nodes.

LengthHere you can determine the length of the filaments in RealFlow units.

Length variationIf you need some randomness, add a variation to the filaments’ length. This value accepts any positive entry.

ThresholdThis setting defines the distance between the streaks and the object’s vertices.

StiffnessHere you can control and determine rigidity or softness of the fibres.

Fiber dampingTo make the filaments lose energy, adjust this value. Very low damping settings may cause unwanted movements and there should be a certain amount of damping to produce more realistic results.

InterpolateBy default, RealFlow creates one fibre along the normal of each vertex, but very often the objects are low polygon proxy versions from high-resolution models to save simulation time. So the amount of fibres is not sufficient. With “Interpolate” you can specify how many elements are generated between the initially generated filaments. This helps you to create a dense cover over the entire surface or between the selected vertices.

Select VertexActivating this button switches into selection mode. There are two ways to select vertices. The first method is to click on the desired vertex. Multiple selections are supported by pressing the Shift key. You can deselect points by clicking on them with the pressed Ctrl (WIN/Linux) or Cmd (OS X) key. Please note that “Select Vertex” does not recognize hidden points. Everything that’s within reach of the mouse pointer will be selected. Another way is to hold the left mouse button and drag the mouse over the desired area. This will create a rectangular selection, including points hidden to the viewer. Once you’re satisfied with your selection, deactivate “Select Vertex” to confirm your choice.

Clear selectionClick on this button to clear the previously made selection of vertices.

CREATE When you click on this button, RealFlow creates fibres from the selected points. You can also overwrite or replace existing fibres to achieve a different look.

Fibres on a hidden torus object, influenced by wind and gravity, as particles and meshed.

Mesh tubeThe standard setting for this feature is “Yes”. This means that the fibres are taken into account during the meshing process. If you don’t want them to become meshed, simply switch to “No”. “Yes” provides access to the mesh-related parameters below. The filaments will be meshed as (more or less) thin tubes.

@ Mesh widthThis parameter defines the diameter of the tube around the particles. If “@ Mesh” width and “@ Mesh width end” are identical, the diameter remains constant.

@ Mesh width endIf you don’t want a constant diameter of the mesh tubes then select an end value here. The result is a conical fibre.

@ Mesh sectionHere you can control the roundness of the resulting mesh. It determines the number of points that will be used to create the hull around the particles.



Introduction | 112

l. Binary loader

This type is an incredibly versatile helper. Actually a binary loader shouldn’t be considered as a typical emitter, because it’s not capable of creating particles, but it can be used to load previously simulated BIN file sequences into RealFlow and perform very interesting post processes. Binary loaders contain very strong features. One of these features is the ability to load a sequence and determine a certain point in time where the imported particles become released. From this point they can interact with other particles and objects again or existing structures can be dissolved. The released particles can accept any of RealFlow’s fluid types, react to daemons and obey fluid equations. The binary loader can only process one bin file sequence at a time, but it’s still great for side-by-side comparisons of different simulations in a single scene, because you can use multiple loaders per scene.

Another advantage is that the binary loader doesn’t care from which source the data has come from. You can use splash or mist particles from grid fluid simulations or fibres. Even if you have a script that converts particles from other sources into BIN files (e.g. Maya particles, ThinkingParticles etc.), you can use them with a binary loader.

Retiming is possibly the strongest function. In some cases it’s necessary to change a simulation’s frame rate or the fluid’s overall velocity. A binary loader provides a method to perform changes in time without having to simulate the entire project again. You’ll find a quick tutorial about how to achieve retiming on page 121.

BIN sequenceFrom this field you can load the desired bin file sequence. For best results the file names should follow RealFlow’s rules for naming and padding (see page 62, “Export Central”). The function opens a file picker for you to browse to the directory containing the bin files.

ModeYou can choose from: “Normal”, “Hold”, “Loop” and “PingPong”. With “Normal” the sequence simply ends with the last file. “Hold” saves the last BIN file and displays it in the viewport. With “Loop” the files sequence starts again with the very first frame. “PingPong” is a nice mode that plays the series of BINs forth and back. The last three options are only visible if the frame range of the current scene is longer than the loaded BIN file sequence.

Reverse If this setting is switched to “Yes”, RealFlow will playback the sequence in reverse order. “No” deactivates this feature.

Number of filesIt’s not possible to change this value – it’s only for your information. It shows how many files from the specified BIN sequence were found by RealFlow.

Frame offsetYou can specify the frame from which the files are loaded. This value does not truncate the sequence, but only shifts the starting frame to the entered value. An example: a file sequence consists of 50 files and you want to start at frame 30, instead of frame 0. With “Frame offset” = 0, the first file is shown at frame 0, the last one at frame 50. If offset is 30, the sequence still contains 50 frames, but playback starts with frame 30 and ends with frame 80. Frame offset can either be positive or negative.

Release particlesBy default, this field is set to -1. This means that the particle are not released and the entire sequence is read from disk. By defining a new value, RealFlow will stop reading further files with this particular frame and the particles will be released, obeying the fluid engine and the scene’s forces. From that point on you’re about to create a completely new simulation.

Load particlesBy clicking on this button you can either reload the existing sequence or load a series of files if you’ve replaced the previously displayed data.

Reset xformFor side-by-side comparisons it’s normally necessary to reposition the binary loaders and the key here is that the particles are emitted at their new position, taking the emitter’s offset into account. To reset to its original position, click on “Reset xform”.



Introduction | 113

SubdivisionsThis value can be seen as a multiplier. A value of 0 doesn’t create any intermediate files at all, while 1 exactly recreates the existing number of files. A value of 2 writes the doubled amount of previously stored files. With 3 you’ll get 2 files between each frame, and so on. For more information, please read the mini-tutorial “Retiming A Simulation With A Binary Loader” on page 121.

@ Output sequenceHere you can determine a file prefix for the interpolated particle sequence. For more information, please read the tutorial “Retiming A Simulation With A Binary Loader” on page 121.

m. NBinary loader

The NBinary loader could be seen as an expansion of the binary loader to combine multiple emitter sequences. This can be very important for meshing or importing particles into your 3D application, because in some programs it’s only possible to import a single BIN file sequence.

With RealFlow’s NBinary loader different sources can be combined and exported as one emitter. With this process, meshing can be accelerated, too, because settings have to made once only. Please note that it’s not possible to interpolate simulations with a NBinary loader or release the particles.

u The number of files must be equal for each emitter. It’s not possible to mix sequences with different number of files, e.g. Circle01 carries 78 BIN files and Square03 consists of 112 BINs. In this case RealFlow aborts the loading process.

BIN sequencesIn contrast to the binary loader, “BIN sequences” only shows a list of currently loaded files sequences. If you want to add a new series of files you have to press the “Load Bin Seq” button.

Load Bin Seq.This button opens the file picker to load a file sequence. You can only choose one series at once. If you want to add another series of files, click on the button again, browse to the desired directory, and grab your sequence.

Remove Bin Seq.To remove a sequence, choose it from the “BIN sequences” menu and click on this button. The name under BIN sequences will be replaced by “Empty” and the particles won’t be visible anymore.

ModeYou have exactly the same option as with the binary loader and their mode of operation is the same: “Normal”, “Hold”, “Loop” and “PingPong”.

Reverse Choose “Yes” to play back the sequence in reverse order.

Number of filesThis field shows you the number of currently loaded files.

Frame offsetIf you want to shift the starting point of the sequence, enter a frame number. This attribute accepts both negative and positive values.

Reset xformThis button is used to restore the original emitter position if you’ve performed some relocation and want to reset it.

n. container

Similar to the binary and NBinary types, a container isn’t really an emitter, as well. It can be considered as a kind of bin for receiving particles from other sources.



Introduction | 114

Normally this type is used in combination with a Filter daemon (see page 142). With the Filter daemon you can specify certain conditions to shift particles from a source emitter to the container. This easy workflow makes it possible to create foam or spray, and render out these particles separately. Though this type doesn’t create particles, it has all features you know from other emitters. The particles can react with rigid bodies or RealWave surfaces, and you have full control over the physical parameters.

The container’s own Node Params panel doesn’t provide any options, because it receives particles and fluid properties from other sources.

8.03 standard Fluid particles (Tutorial)The following chapters give an introduction about basic workflows with particle-based emitters. This fluid type is perfectly suited for small or mid-sized projects with a need for high details or close-ups. A wide range of emitter shapes will help you to create all kinds of fluid effects.

a. a Basic setup For standard Fluid emitters

Standard fluids are RealFlow's original field of application. Over the years this type of simulation has become highly optimized and the fluid engine has undergone many improvements, extensions and redesigns. You can choose from a wide variety of emitters which all share two fundamental goals: 1. Providing fluid particles for your simulations2. Making your life as easy as possible by offering a wide variety of different shapes

With many emitters you can even choose whether you want to create a stream of particles or a certain volume. Many settings also support animation and allow you to customize start and stop of an emission or define interruptions at certain points in time. RealFlow offers emitters for most possible applications, but if you're in need of something really customized then you have the option to convert any polygonal object into a particle source.

Before you can start testing, you need to specify a project name. Directly after opening RealFlow, the software shows the Project Manager. Here you have to choose a directory where the scene will be stored and give it an appropriate name. Choose whatever name you like. Once this has been done you can continue with the main project. For the very first scene a standard fluid will be created that's influenced by a force. Another requirement is that the particles don't live forever, but disappear after a certain time – let's say after approximately 1 second. The setup is pretty easy and consists of an emitter, maybe a circle emitter, and two daemons – gravity and age.

Emitter and daemon symbols in RealFlow's viewport.

Adding the nodes is done with just a few clicks. From the menu bar select:

Edit > Add > Emitter > Circle Emitter

Edit > Add > Daemons > Gravity / k_Age

Now you have to arrange the emitter, because by default all nodes are placed at the viewport's origin: this means that the position coordinates for each axis are [ 0,0,0 ]. You can check this by having a look at the emitter's Node Params panel. For this purpose the appropriate element has to be activated, either from the viewport or the Nodes window. Once selected it's displayed with a highlighted background and the corresponding Node Params panel appears, providing all available settings. The Node submenu provides information about scale, rotation, position and so on. Here you can see that the current position is the same as the viewport's origin at [ 0,0,0 ]. To move the emitter node, you can either directly enter fixed values or use the W key to get visual feedback while dragging the node to the new position in the viewport. This workflow should be familiar from other 3D applications.



Introduction | 115

In addition to the axis, which indicates the orientation of the emitter in 3D space, there is a fourth arrow which shows the direction of emission. To change this, it's necessary to rotate the node. The emitter should point into the “air” with a rotation of approximately 120°. Again, you have the possibility to enter values or perform the transition with the mouse and the E key. This action enables the rotation mode.

For the daemons it's not necessary to perform any position changes. The reason is that (unbounded) gravity is a global force, so it makes absolutely no difference where the daemon is located. You could shift it 100 units in Z direction and the result would still be the same. k Age, on the other hand, doesn't provide any forces, but instead depends on time. Therefore it also makes no difference where you place this daemon.

Without the gravity daemon, RealFlow only calculates the forces between the particles. Of course this is already a complete fluid simulation, but without an external force everything would react as if we were in space. Also the speed of the particles would be constant, representing the initial velocity we entered under the emitter's Speed parameter. External forces can accelerate or decelerate the particles. The Strength of a force-based daemon determines how strong the acceleration is and thus the final velocity of the particles. For our first test the default value of 9.8 is fine, as it represents the gravitational acceleration on Earth. If you want to change it, feel free to do so under:

Gravity01 > Node Params > Gravity > Strength

The last step is to adjust the k Age daemon. Similar to the gravity daemon, the relevant settings are located under an appropriate panel:

k Age01 > Node Params > Age

The life-span is given in frames. The second value adds some randomness to avoid an uniform or artificial look. The number of frames, of course, depends on your currently adjusted frame rate. RealFlow's standard value is 30 fps, but you can change it under Preferences (page 45) or Simulation Options (page 40). With 30 fps, 30 frames will last one second.

Finally it's time to start our first simulation. The particles pour out of the emitter and soon become attracted by the gravity daemon. This results in a downward motion and after one second the oldest particles will be deleted. Since you're working with Speed here, there's always a fresh supply of particles. If there was a volume, instead of Speed, all the particles

would be deleted after exactly 30 frames, because they have been created at the same time. The simulation should run nearly in realtime, especially on modern machines. You can also observe that the timeline becomes filled with a yellow bar indicating the already-simulated frames. This simple scene already contains a variety of standard workflows: • how to add nodes• where to find node-specific settings• how to reposition individual elements

You've also used more than one daemon and learned how they can work together. These methods are essential and the principle mode of operation is valid for many actions in RealFlow.

b. Working With Density

Density is one of a fluid's core parameters and of particular importance. Like viscosity, density directly determines the type of liquid substance. Density is defined as mass per volume. This property is not limited to liquids – each substance has a certain density. In daily life it's practical to compare an object's (or fluid's) density to the density of water. The density of water is given as 1,000 kg/m3, so this is used as the reference value. Substances with lower density, for example olive oil or cork, have the ability to float on water. Substances with equal density have the ability to mix completely. Materials with higher density, like lead or mercury, will sink instead. With RealFlow it's possible to mimic this specific behaviour by just entering the desired density.

An example project for this tutorial would be to create two fluids with different densities. Such a project is a useful example, because you can easily verify the results: all you have to do is to go into your kitchen and mix water with cooking oil, for example. You already have a certain idea how such an interaction should look and this makes it easy to see if the simulation results match your daily experience.

What could a scene like that look like? In this case it'd be a good idea to work with volumes for the emitters, instead of particle streams. Predefined fluid volumes can collapse under the influence of gravity and collide with each other inside a tank. Such a setup will produce enough turbulence to create an interesting simulation. Building the setup shouldn't be a problem anymore, because you can use the same basic methods discussed in the previous project. What you need now is just a closed water tank with sufficient dimensions. Create a cube object and change the scale settings to [ 6.0, 3.0, 3.0 ]



Introduction | 116

If you're working with a scene scale of 0.01 (3D Studio Max and Cinema 4D), then you'll see something interesting: the cube is hardly visible, because of the tiny scale. It's just one hundredth of RealFlow's default scale In this case you'll need to multiply each dimension value by 100, so the resulting settings will be [ 600.0, 300.0, 300.0 ]. There's another value that's heavily influenced by RealFlow's scene scale, but this parameter is introduced a little later. First you have to create the emitters for oil and water - two square emitters will be fine. Rename the emitters “Oil” and “Fluid”, and create a scene setup similar to the image below.

To create a defined fluid volume you have to enter

Oil / Water > Node Params > Square > Volume > 1.5

Once you've entered a value under Volume, the corresponding “Speed” parameter is set to 0.0, because it's not possible to define a volume and constant stream at the same time. What you finally need are the settings for the different fluids and a standard gravity daemon. The very first property you should change is “Density”. For water this is easy, because it's 1,000 kg/m3 and that's already the default value with RealFlow's emitter. When you have a look at page 326, you can see that olive oil, for example, has a density of 910 kg/m3. That's pretty close to water, so the differences might be subtle. Nevertheless it's a real value and there's no reason why you shouldn't rely on it. Now you can hit “Simulate”. Settings under Export Central are not required, because all relevant objects

will be exported by default. There are sometimes files we don't need, for example the data files for the tank, but this issue can be neglected with such a simple scene setup. This is the result after 50 frames:

The result doesn't really meet our expectations at the moment and it's not easy to evaluate the quality of the scene. The scene has been simulated pretty fast, but obviously lacks an adequate amount of particles. Therefore, we'll need to raise the emitters' resolution values. The Statistics panel tells you that each emitter has 2,250 particles. A factor of 10 should produce a much better simulation. Of course the simulation time will increase drastically with more particles, but fortunately RealFlow 5 is up to 20 times faster than RealFlow 4 with standard emitters. To speed up the calculation it's also recommended to disable the viewport while simulating. To do this, click in the viewport and press

Alt + D

With a scene scale of 0.01 you'll have to wait much longer for the simulation to be finished. The reason for this is a parameter that influences the interaction between objects and particles. When the particles come into contact with the tank, RealFlow uses a value called “Collision distance” to determine the quality of this interaction. A very low setting directly influences simulation time. On the other hand small values produce more accurate results. RealFlow automatically calculates “Collision distance”: for a standard cube at scale 1.0 it's 0.02. With a scale of 0.01 the value becomes 100 times smaller: 0.02 x 0.01 = 0.0002.



Introduction | 117

The effect is a significant increase in simulation time and therefore “Collision distance” should be raised to 0.02 again. Select the tank node and choose:

Tank > Node Params > Particle Interaction > Collision distance > 0.02

Now, hit the Simulation button again. What you can now see is that the splashes become much more pronounced, and the fluid behaviour appears more impressive. You can also see that the two fluids don't really mix, and after a while they're almost completely separated. The less dense fluid (“Oil”) floats on top of the water particles, just as you would have expected.

The fluid simulation with Resolution = 10 in top view.

Everything already looks pretty nice, but there are still some aspects to improve. First of all the scene would look much better with even more particles, but that's reserved for the final simulation. Another aspect is the appearance of the oil particles. They still look a little watery. Real oil shows a tendency to form adhesive drops with a more organic look. The parameters responsible for this behaviour are “Viscosity” and “Surface tension”. “Viscosity” is an internal drag force which slows down the particles, while “Surface tension” can be seen as a property that enhances a fluid's tendency to form drops. By raising both parameters we can achieve a oilier look. “Viscosity” values between 10 and 20, and moderate “Surface tension”, ranging between 5 and 15, are good choices for our scene. If you observe some highly accelerated particles, please increase “MIN substeps” to values between 5 and 10.

Another value that can be used to enhance a scene is “Int Pressure”. It describes the fluid's attempts to expand. “Ext Pressure” counteracts this behaviour like high or low (air) pressure. Very exaggerated splashes can be reduced effectively by either lowering “Int Pressure” or increasing “Ext Pressure”. Finding the right balance is not only a matter

of environmental conditions, but also of personal taste. In this scene, “Int Pressure” will only be reduced for the “Oil” emitter to create a heavier look. Oily substances behave a little bit sluggishly and a decreased “Int Pressure”value is a good means to achieve such a property. To get a more distinctive effect you could also lower the oil's “Density” to a value between 500 and 750. Of course that's not a real value for olive oil, but sometimes it's necessary to “extend” reality a little bit or find compromises. As long as you get the desired result this shouldn't be a problem.

To avoid the slightly artificial look in the current simulation, there's another trick: “V random” and “H random”. These settings give you a much more realistic and less symmetric appearance. In this case both parameters should be set to 1.0:

Oil / Water > Node Params > Circle > V random / H random > 1.0

Finally, there might be some particles leaving the container node. Those particles slow down RealFlow's simulation speed significantly and should be destroyed, because they don't contribute to scene anymore. RealFlow provides a set of daemons and the best one for our current purpose is k Volume. Rescale it with the R button to make it roughly fit the outlines of the tank. Now each particle that leaves the tank will be destroyed, saving precious time.

The final result shows the typical behaviour of oil in water. Looking from below we can observe the forming of little drops which accumulate after a while and create layers. For the final simulation you can use much higher emitter resolutions of 50 or even 150.

The final fluid simulation with Resolution = 50 in top view.

If you still want to experiment with fluid densities, then create a scene with three emitters and different volumes at different heights. You can see images on the following page.



Introduction | 118

Simulation of 3 fluids with different densities (water, oil and alcohol).

c. RenderKit Meshes

RealFlow uses particles to represent the expansion and behaviour of fluids. For pure visualization this is certainly enough, but for rendering it's often better to have real 3D object, or even a combination of particles and polygons, for example if you want to render out spray together with water. To translate the individual particles into a solid object, RealFlow provides three different mesh engines. All types have one thing in common: they evaluate the outer surface of the particle cloud and represent it as a polygon hull.

If you're familiar with RealFlow's standard meshing tool, you'll detect many completely different settings, but also a few similarities, for example the split workflow for mesh and field settings. One of the most interesting features of the RFRK engine is its ability to store selected attributes with the mesh, for example pressure, velocity or density. These characteristics can be used within your 3D application to calculate motion blur based on these settings, or dye the fluid to show zones of varying density.

Please keep in mind that visualizing these attributes requires a compliant render engine; they're not visible by default. There are also some analogies, like filtering or the ability to use a metaball algorithm. The “post processing” features (clipping, texturing etc.) are identical to RealFlow's standard mesh. One of the strongest features is that you can use all available mesh types within a single scene.

Applying a mesh is as easy as adding any other node. If there's just a single emitter in your scene, it'll be automatically attached to the mesh container. With more emitters you have to select which one you want to bind to the mesh. The previously discussed scene consists of at least two emitters and they should be meshed separately, because in a 3D program the different fluids will all have different attributes. So, you'll need two mesh containers. Each one will receive an emitter:

RK_Mesh node > Right-click > Insert emitter > choose appropriate emitter

The order plays absolutely no role and both meshes will share exactly the same settings. For a very first impression just leave the default settings and create the mesh by right-clicking on the mesh node and choosing “Build”. With this method it's possible to create a mesh for the current frame. The result could look like this example:

At the moment the mesh looks like an accumulation of spheres and appears rather coarse. That's not really surprising, because the standard mesh engine shows an output of similar quality to the default settings. The first action is to reduce the size of the clearly visible



Introduction | 119

spheres; this can be done with the emitter-related “Radius” parameter. By default, it's relatively high and it should be decreased to values between 0.05 and 0.02. The next adjustment affects the field settings. These values determine how the individual particles influence each other to create the impression of drops. Click on the attached emitter alias and choose:

Node Params > Field > 0.03

Now, build the mesh again. You can observe some huge differences: the mesh fits much better to the particle cloud, shows much more detail and renders very fast. Despite of all these benefits it somehow lacks detail - this can be changed with “Polygon size”, which is a mesh-related setting. For the image below, a value of 0.02 has been used.

Decreased "Field" and "Radius" settings show much more details.

The mesh shows much more details with this adjustment, but the fluid borders look unnaturally thick. The most effective method to decrease this effect is filtering. Though the settings are completely the same as with RealFlow's standard meshes, the impact may be different, because the RFRK mesh engine uses other algorithms. A good idea is to start with a rather low "Steps" value of “32” and see what happens.

Even thinner splashes can be achieved with lower “Radius” settings or another mesh-related parameter, called “Smooth”. It blends the individual spheres together to give for a thinner and less round look. Depending on the scene's particle number, amount of details

and scale, “Smooth” can be a very sensitive value, so we recommend that you experiment with carious settings. Here's a mesh with a setting of 20:

Filtering helps to avoid thick edges and creates a more fluid-like look.

One thing you'll also notice is speed: RenderKit meshes are calculated much faster than standard types and they normally consist of fewer polygons. Quality is absolutely comparable to RealFlow's “classic” approach and with additional functions, like particle filters or smoothing you have even more possibilities to create the desired details.



Introduction | 120

d. standard Meshes

The workflow for a standard mesh is actually the same as with RenderKit meshes. You can also see a mesh container where you can attach one or more emitters. Again, the settings are subdivided into two sections: mesh and particle-related field settings.

A good mesh uses as few polygons as possible and shows as many details as possible. It's not always easy to find a perfect balance between file size, quality and realism. In other words: testing is an essential part of mesh generation. A very common issue is scale, because it's important to make sure that the mesh matches your scene. Meshes which are too small or too big can destroy the entire impression of a scene and are a very common source of errors. Therefore you always have to find settings which are appropriate to the scene, and this actually starts with the particle simulation.

From the descriptions about standard mesh settings (page 194) you know that the emitter-related settings control how the particles blend together to create the mesh. There are two main parameters which define the size of the drops: “Radius” and “Blend factor”. Higher settings lead to rounded meshes with thick borders, but they can also iron out unwanted ripples or inconsistencies.

It's not possible to define presets which are valid for any fluid simulation, because your demands will most likely change with each new scene. This takes a little practice, but after a short while you'll be able to directly evaluate suitable initial settings. The clear arrangement of the parameters will also help you to become familiar with this mesh type quickly. Normally, the default “Blend factor” of 95 is already a very good start. For “Radius” settings between 0.05 and 0.01 are fine, but of course you can try other settings.

The next adjustment concerns the number of polygons, managed by “Polygon size”. This setting directly influences meshing time, display time and file size. Lower values produce larger files. For the first attempts you should start with moderate values, for example 0.02. To create a mesh, simply jump to a frame where you can see a lot of details and splashes and click on:

ST_Mesh_Node > Right-click > Build

Now it's time to optimize the mesh. The reason for rounded meshes is the metaball algorithm. As the name suggests, the particles are represented as spheres with a certain radius. The results somewhat thicker borders.

Thick borders are an often observed issue with standard settings.

Round borders are simply a matter of physical principle – just have a look at your 3D program's metaball engine! The good news is that mesh quality can be enhanced with an appropriate settings. In the next step, "Blend radius" has been decreased to 70, "Radius" to 0.1. A filter can also effectively smooth the borders and create a more a fluid-like impression. High values can be used to simulate substances like liquid metals.

Decreased "Blend radius" and moderate filtering will create a mesh with rich details.



Introduction | 121

From the descriptions on page 180 you can see that “Steps” is the most important parameter. It's recommended to alter “Steps” instead of “Relaxation”. Normally the default settings are sufficient. To avoid very sharp edges, you can reduce “Steps” to values between 15 and 30 here. “Relaxation” is a rather sensitive parameter and can strongly influence a mesh, because it has a shrinking effect. Nevertheless filtering should be considered with (almost) any mesh, as you really can get rid of the most common problems with edges and unnatural-looking fluids. The “Tension” option is rarely used and only plays a role with unwanted high-frequency patterns.

To give you a better impression of the rendered fluid mesh you can apply various OpenGL shaders with real-time performance. With more than one mesh it's of course possible to apply different shaders with various environments. Another advantage is that the shaders also consider already adjusted colours. To get a better perspective you can disable the emitters' display option and turn to a shaded mode.

e. Building a Range of Meshes

The last step is to build the entire mesh range from the stored particle files. This procedure is exactly the same for both mesh types and can therefore be discussed together.

In most cases it's not enough to evaluate a mesh from a single frame or BIN file. It's often necessary to build several test meshes from various frames to find a good compromise regarding the settings. Under some circumstances it could also be possible that you have

to animate the mesh parameters, but that's fortunately an exception. Once you've found working settings it's time to start the mesh script. For this purpose, set the timeline indicator to frame 0 and click on the appropriate icon under RealFlow's system scripts bar. Depending on the complexity of a mesh, it can take a little while for the mesh to be displayed.

8.04 Retiming a simulation With a Binary loader (Tutorial)RealFlow offers a unique feature to retime a simulation without having to calculate the entire sequence again. This is often necessary when you have to playback simulations at higher frame rates or extend it to a certain length. Especially in production environments or within tight deadlines, retiming can be a valuable time saver. Retiming in RealFlow is easy to create and very fast. The idea is to interpolate all properties, like velocity or position between two frames for each particle and create one or more intermediate files. Of course this method has its limits and there’ll be a moment when you can observe artefacts or a unnatural behaviour of the fluid, but for extensions up to 3 or 4 times, retiming should work without problems. It’s certainly useable for presentations or previews.

You’ll need a previously calculated and stored particle sequence. Let’s assume the existing simulation has 100 frames and you want to extend it to 200 frames. The sequence from the circle emitter is opened and loaded using a binary loader within a new scene:

1. RealFlow menu > File > New project...

2. RealFlow menu > Edit > Add > Emitters > Binary Loader

3. Node params > Binary loader > BIN sequence Browse to the directory with the circle emitter’s BIN files and choose the first frame of the sequence.

4. Node params > Binary loader > Subdivisions > 2 This number can be seen as a multiplier. A value of 0 doesn’t create any intermediate frames at all, while 1 would exactly represent the existing sequence. The given value of 2 writes out 1 file between each frame.

5. Node params > Binary loader > @ Output sequence > Browse to the appropriate



Introduction | 122

directory and enter “Circle_retimed_” You can choose any name here, except the name of the already existing circle emitter. This could lead to problems, because the interpolated sequences might be written into the same directory!

6. Time line buttons > Play

It’s important that you do not click on the “Simulate” button, but on “Play”. During playback, RealFlow creates the intermediate files using the prefix entered under “@ Output sequence”. Once playback has finished you can open the “particles” directory of the circle emitter. There you’ll find a total of 200 files ranging from 0 to 199, e.g. “Circle_retimed_00176.bin” etc.

This sequence can be loaded with a new binary loader again. Now you have to either change simulation length or double frame rate:

• Time line > Last simulation frame > 200

• Simulation options > FPS output > 50

• Optional: Simulation options > MAX substeps > 200 or less

Click on the “Play” button and watch your freshly retimed sequence.



Introduction | 123

9 RealFloW DaeMoNs

Without daemons, all fluids are only affected by internal forces between the particles. These forces determine the look of the fluid without any external influence. The motion that can be observed with fluids is the result of an emitter’s parameters and properties, such as speed, internal and external pressure or viscosity. Rigid bodies don’t show any behaviour at all, as long as there’s no force acting on them. The question is where do external forces come from? External forces can either be originated in daemons or the kinetic energy of particles, or other bodies. Even RealWave meshes can be affected by forces, for example by impacting objects or particles. The objects can create waves on a RealWave mesh as a consequence of the appearing hit forces, but waves cannot be influenced by daemons.

The image sequence on the left shows a complex interplay of different daemons to create a nice droplet. The forces are used to contract the particles and form the typical shape So, many daemons are used to introduce forces, but what’s the nature of a force? Briefly put, a force can accelerate other objects. Introducing external forces may be the most important feature of daemons, though there are more types to explore. As you can see from the list of daemons there’s also a group of 6 nodes with a “k” prefix. This prefix stands for “kill”. With this kind of daemon you can determine certain conditions for where or when particles are deleted and removed from the scene.

k Volume daemons in action.

The third and final group neither introduces forces nor deletes particles. The two available daemons are called “Texture gizmo” and “Color plane”. “Texture gizmo” is used to map a texture on top of a fluid surface reading the UVW coordinates of each particle. “Color plane” provides access to a powerful visualization tool within RealFlow. This daemon is capable of showing the local physical fields (velocity, pressure, density etc.) of a fluid on a rectangular plane.

RealFlow offers a total of 27 daemons for every imaginable purpose and even if you’re working on a project, where all the existing daemons aren’t enough, you can still use



Introduction | 124

scripted daemons. This type provides predefined functions which can be extended with Python code to write your very own source of forces. Of course, it requires Python (or C++) and scripting knowledge, but there’s an example of a scripted daemon in RealFlow’s scripting guide on page 268, making it easier to get grips with to this topic.

The number of daemons is not limited and you can introduce as many as necessary, combine them with k-daemons and make them exclusive to selected nodes. This flexibility gives you the freedom to establish any global or exclusive connection between daemons and affected objects. With simple drag and drop actions you can add new daemons to your project or control exclusive links. As with other RealFlow nodes, daemons can be activated or deactivated temporarily to examine the influence of a particular force or function. Except from “Color Plane” it’s not possible to export a daemon’s features or animation data: during rendering in a 3D application, daemons have no influence on imported objects, and therefore there’s no need to export them.

9.01 Daemons and scaleA completely new feature in RealFlow 5 is the possibility to adjust daemon forces separately for particle fluids, grid fluids and objects – independent from the current geometry scale. This workflow has a range of benefits, especially when you have to work with more daemons. By setting the force scales you can change the strength and influence of all daemons simultaneously without having to adjust each node individually. Also when your scene contains very large or very small objects you can compensate forces by simply altering force scales. Force scales can be accessed from the Preferences panel (see page 45) to adjust them globally. A local setting for each scene can be found under:

Simulation Tools > Scale options

9.02 common settingsLike any other RealFlow node, daemons also have a couple of common settings. These parameters are responsible for daemon orientation in space and visibility. Of course, it’s possible to adjust everything individually for each node. By selecting more than one daemon, you can also change settings for the currently active nodes simultaneously.

a. The Node panel

The Node window is used to determine “Position”, Rotation” and “Scale”. All position or geometry-related parameters expect three values for each axis in space. The order is X, Y, Z. Some daemons cannot be scaled and position effects have no influence, because they are acting like global forces, introducing exactly the same magnitude at any point in RealFlow’s 3D space, unless they’re bounded.

Additionally there are:

SimulationWith this parameter it’s possible to temporarily deactivate/activate a certain daemon. The third option is cached, which doesn’t play such an important role with daemons, and is therefore rarely used here.

PivotThis special point can also be called centre of rotation. By displacing pivot, the node’s rotation becomes eccentric. In combination with daemons, this parameter is of secondary importance.

ShearYou can deform RealFlow nodes with this tool, but it only influences a (bounded) daemon’s viewport representation and has no influence on its functionality.

Parent toYou can parent a daemon to any other node in the current scene – no matter if it’s animated with keys or dynamically driven. To establish this connection simply select the



Introduction | 125

desired parent node. The daemon will then execute any motion of the higher-ranking object.

ColorEach daemon is represented by a certain symbol. If a node is selected it’s shown in green, otherwise in the currently specified colour.

b. The Display panel

With this window it’s possible to control visibility and the daemon’s viewport representation.

Another interesting aspect that’s related to a daemon’s display abilities is the visualization of force fields. Though there’s no physical entry or parameter for this feature, it’s possible to make it visible with the help of a mist node from the grid fluid menu: simply add a mist node to your scene and activate the following option:

Mist node > Node Params > Display > Show velocity field > Yes

Now it’s possible to see the forces of a daemon as a vector field, represented by arrows. Depending on the force’s magnitude the arrows can be fairly small.

VisibleA daemon can be made invisible to see objects or particles behind the viewport representation. Visibility can be changed at any time, but it’s not possible to animate this feature.

Show iconBy default, a daemon is labelled with an icon for better identification, but with lots of daemons or small objects, the symbols might cover important details, and therefore it’s possible to deactivate the icon.

9.03 RealFlow Daemon TypesAs mentioned earlier, daemons can be grouped into three different types:

1. “Killer” daemons2. Force/Velocity daemons3. Miscellaneous daemons

Daemons can affect any particle type, regardless of whether they originate from standard or grid fluids, and mist nodes. With mist, a daemon just defines the velocity field that is used for the advection of the density field. Many daemons can also act on rigid and soft bodies. The only premise is that the dynamics feature is activated for each item. Unless the dynamics option is inactive, daemons won’t have any influence:

Selected object > Node Params > Node > Dynamics > Rigid body / Soft body

a. k Volume Daemon

This is the first of six “killer” daemons to eliminate unwanted particles. There are many cases where particles become invisible in the final camera view or leave a certain area. In most cases these particles only increase simulation time without any additional benefit for the project – especially grid fluid splash or foam particles profit from k Volume daemons. Sometimes there are also some particles escaping from a scene, slowing down the fluid engine significantly. It’s a real necessity to remove all these kinds of unwanted particles and a k Volume daemon should be added to (almost) any scene. The k Volume daemon



Introduction | 126

is easy to handle and it can be treated just like a cube object: dimensions, position and rotation are simply specified under the daemon’s Node window.

Fit to objectThis button fits the daemons bounding box to the dimensions of a certain object. By clicking on this button, the well-known node picker appears giving you the opportunity to select one item from the list. Please note that automatically adjusted daemons do not fit the selected object exactly and there’s also a cache between the outlines of the object and k Volume.

Fit to sceneFor the calculation of the daemon’s bounding box, RealFlow takes all scene elements into consideration and you don’t have to choose an individual object.

InverseWith this option it’s possible to decide whether the particles should be deleted inside or outside of the volume. By default “Inverse” is set to “No”.

b. k age Daemon

With this daemon it’s possible to define a life-span for the particles and remove them when this limit is reached. Another possibility is to create more particles based on a particle’s lifetime. In the latter case it’s possible to spawn huge amounts of particles which can also be important for foam or spray effects with standard emitters and scripted solutions. The k Age daemon can only affect regular particles and has no effect on grid fluid particles.

Life This parameter sets the life-span for all particles given in frames.

VariationTo avoid an abrupt disappearance of particles it’s recommended to alter the life span and create a more random behaviour. The variation or tolerance is also quoted in frames and accepts both negative and positive values. Please be careful with very high variation settings, because they can create an unwanted flickering which is noticeable especially with fluid meshes.

SplitInstead of deleting the particles you can also force the daemon to create more particles at a certain life value. In this case, k Age splits up the particles and creates a certain number of new particles. This number is specified under “@ # child”.

@ # childHere you can define the number of child particles to be created if “Split” is set to “Yes”.

c. k speed Daemon

This is a very versatile daemon and can be used to not only delete standard particles (though its usage is restricted to particles), but also to relax fluids, or keep certain states. Similar to k Age, there’s a function for splitting and spawning particles to simulate spray, for example. The Statistics panel is your source for speed information.

Min speedUse this field to define the minimum speed. Particles with velocities lower than this value will be deleted. If “Limit & Keep” is activated, a particle’s velocity will be limited to the adjusted speed value.



Introduction | 127

Max SpeedAll particles with velocities above this limit will be removed.

Limit & KeepYou can choose between “No” and “Yes”, and by default this action is deactivated. By switching to “Yes”, RealFlow will use “Max speed” to limit all particles with greater velocities to this particular value and keep this speed. This is helpful if you don’t want the particles to become faster and faster over time. Another field of application is the relaxation of fluids. With this technique it’s possible to sap energy from the particles over time, making the fluid rest and remove sloshing. From such a relaxed fluid it’s possible to make an initial state and continue with a fresh simulation.

SplitParticles won’t be deleted when they reach the defined speed limits, but new ones will be created. Depending on the number of children the amount of particles can grow dramatically. If you want to generate spray or foam, it’s recommended to use the dumb particle type (see page 100).

@ # childThis value determines how many particles are created if “Split” is set to “Yes” and the adjusted speed has been reached.

d. k Isolated Daemon

This daemon will delete any particle without neighbours after the specified time and is limited to standard particles. With grid fluid particles you won’t see any effect. It’s sometimes needed to keep fluids coherent, accelerate a simulation or create clean meshes. Isolated particles can slow down a simulation significantly!

Isolated timeThis field specifies the maximum isolation time in seconds, and after this time the particle is deleted. Unlike k Age, here the time unit is seconds, not frames. Therefore it will be adjusted automatically if “FPS output” changes.

e. k collision Daemon

With a k Collision daemon in your scene, standard particles are destroyed when they collide with the objects. You can either choose all of the objects at once or attach selected items. Additionally the daemon can be used to spawn particles with the collision, instead of deleting them. k Collision does not work with grid fluid particles.

All objectsBy switching this feature to “Yes”, RealFlow automatically takes any suitable object into consideration. Simultaneously the “Select objects” option is greyed out. The default adjustment is “No”.

Select objectsThis feature opens a node picker containing a list of object nodes in the scene. Multiple selection is allowed and the chosen nodes appear as a list.

SplitAs always this function creates more particles. Here the new particles are spawned when the selected object(s) are hit.

@ # childThe number of child particles created in collision is controlled here. Please note that the amount of particles can strongly increase with high settings within a very short period of time. Therefore it’s often recommended to add a k Age daemon, for example.

f. k sphere Daemon

This daemon works very similarly to the k Volume daemon, but here a spherical volume is used. The only difference is that the sphere’s dimension is not controlled with scale settings from the Node panel, but with a separate radius value.



Introduction | 128

Fit to objectThis button fits the daemons bounding box to the dimensions of a certain object. By clicking on this button, the well-known node picker appears, giving you the opportunity to select one item from the list.

Fit to sceneFor the calculation of the daemon’s bounding box, RealFlow takes all scene elements into consideration and you don’t have to choose an individual object. Please note that the automatically adjusted daemon does not fit exactly and there’s also a little cache between the outlines of the object and k Sphere.

RadiusThis value is used to set the radius of the sphere.

g. Gravity

Gravity is surely the most often used daemon in RealFlow and necessary for almost any scene. Gravity is a global daemon, acting with equal strength at any point of the 3D domain. Since gravity is commonly used, it’s important to know a few things about it:

1. Gravity is mass-independent. This means that higher masses won’t lead to stronger acceleration or higher velocities. If you want to achieve stronger acceleration, it’s necessary to raise the daemon’s strength value.

2. Gravity strength depends on the particular location. Here on Earth, gravitational acceleration has an average value of 9.8 m/s2, on Mars it’s just around 3.7 m/s2, for example.

3. Mass and weight are not the same. Weight is a force and depends on the particular gravitational acceleration of a location, but mass is determined by the amount of atoms.

4. Each body produces a certain amount of gravitational acceleration, but it can be neglected for very small bodies.

It’s sometimes a very good idea to experiment with different strength values. Since gravity is an accelerating force, it strongly affects the behaviour of fluids. You can create “denser” fluids with higher values or avoid exaggerated splashes.

AffectParticles can be affected in two ways: either by “Force” or “Velocity”. The first option applies an external force, resulting in an acceleration, while the second one only modifies the velocities of the particles without introducing an additional acceleration. Forces take a little time to display their full influence. This means that they accelerate the particles over a certain time span depending on their strength. High forces exert stronger accelerations and the particles or bodies become faster and faster as long as the force acts on them. The result is a curved stream of particles.

“Velocity” directly affects the particles from the very beginning without any delay or deceleration. The result is an apparently stronger influence, because the deflection of the particles starts with the very first moment. The result in this case is a linear particle stream. “Velocity” is not available for rigid bodies. To get an imagination of “Affect” and “Velocity, please also have a look at the images on the right.

Affect = Force Affect = Velocity



Introduction | 129

StrengthThis is the dimension of the gravitational acceleration and it depends on your current location. A table for the most common places can be found on page 327. Please read the annotations above to get a better understanding of RealFlow’s gravity daemon. “Strength” does not accept negative values. If you want to change direction of the force, you have to rotate the daemon.

BoundedIf this option was available in real life, it’d be fantastic, but unfortunately it isn’t and so the only way to restrict the scope of gravity is inside RealFlow. You can choose from four options: “No”, “Box”, “Plane” and “Push”. “No”, of course, turns on the global force. “Box” restricts gravity to the inside of a box that can be scaled like any other object. “Plane” restricts the effect to every particle at one side of the plane that becomes visible in the viewport. “Push” applies the force to an object acting, in a way similar to an engine. This option is not meant to be used with particles.

UnderwaterThis parameter is only available when the “Push” method has been chosen and exclusively works with objects in combination with a RealWave surface. It applies the force to the connected object when the point of action is below the surface – for example, you want to simulate a ship pushed by its propeller, but you don’t want it to move when the propeller is above the surface.

h. attractor Daemon

The attractor is also one of most commonly used daemons and perfectly suited to sculpt and shape fluids, enhance splashes, or create the famous “liquid dance” simulations, where particles are attracted and repulsed to create a dynamic and balanced movement. This daemon attracts particles towards its centre – negative values create a repulsion. Near the centre attraction forces become stronger and particles – or objects – experience greater acceleration. But not only fluids are affected by attactors, because this type can also affect rigid and soft bodies. Bodies with higher masses require higher “Internal force” settings.

Another feature is that the attractor daemon can adopt different shapes and its influence can be restricted with a bounding option. Animated attractors are useable for many creative fluid sculpting approaches.

AffectParticles can be affected in two ways: either by “Force” or “Velocity”. The first option applies an external force, resulting in an acceleration, while the second one only modifies the velocities of the particles without introducing an additional acceleration.

Internal forceThis value determines the strength of the attraction force. Rigid bodies with very high masses normally need strong internal forces to start moving. Please note that this field also accepts negative values to create a repulsion effect.

Internal radiusIf “Attenuated” is set to “Yes”, this option becomes editable. It’s the radius where the attraction/repulsion force begins to attenuate.

External forceAgain an option which is only accessible with “Attenuated” set to “Yes”. It’s the attractor’s strength in the outer area, defined by “External radius”.

External radiusThe third value that’s dependent on “Attenuated”. The setting determines the radius where the attenuation of the attraction/repulsion force ends. This radius is represented by a dark blue ring around the attractor.

AttenuatedYou have the choice between “Yes” and “No”. “Yes” unlocks the previous three fields to specify the details for the force’s attenuation. “Yes” also tells the daemon that its attraction force declines with growing distance from the centre.



Introduction | 130

Attenuated attractor daemon in perspective and top view.

Attractor typeThe daemon provides a total of three different attraction types: “Spherical”, “Axial”, and “Planetary”. “Spherical” is the default type and is represented by a point in the centre of the daemon. “Axial” produces a force field along a line from up to down – this line is also shown in the viewport. If you want to change the direction of the axis you have to rotate the daemon, using the appropriate Node settings. “Planetary” is represented by a sphere around the daemon’s centre. Within this sphere there’s a linear force field. It simulates a planet’s force of attraction which extends from the planet’s centre to outer space. The planet’s radius is controlled with the following parameter.

Planet radiusControl the radius of the virtual planet here. This option is only available with “Attractor” type set to “Planetary”. The daemon’s viewport symbol will be updated automatically to indicate the new radius.

Axial strengthThis is the vortex strength in the axial direction. It can only be used with the “Axial” attractor type.

BoundedHere you can determine whether the attractor’s forces are bounded or not, and the two possible settings are “Yes” and “No”. To change the dimensions of the boundary, it’s necessary to enter new scale values in the Node panel. The values for X, Y and Z can be controlled independently, and it’s also possible to create elliptical boundaries. The bounding sphere is displayed in the viewport as three circles.

i, Dspline Daemon

DSpline is a complex daemon with versatile settings and fields of application. Its parameters and control options are very similar to RealFlow’s Spline emitter (see page 105). DSpline’s unique ability to combine forces from different directions gives you the freedom to create all kinds of swirling effects, for example. Control points (CP) provide the ability to define the strength of the forces for each zone individually and you can even add new control points. Of course, the control points can be animated, but it’s better to control them with parented Null objects, instead of animating them directly.

To edit the control points it’s necessary to switch to RealFlow’s “Move” mode by pressing the W key or select the appropriate icon. It’s only possible to edit the points with this mode, rotation and scale have no effect. The standard spline emitter shows three control points, surrounded by yellow circles. These circles represent the zones of influence of the various forces. Each of these zones can be adjusted individually and it’s also possible to add or remove control points, but it’s not possible to delete the three default control points.

u The daemon’s height (up-down direction) can be adjusted with Node > Scale, while scale changes in horizontal direction have no effect. Height changes always depend on your preferences – some programs use the Y axis, others Z.

Changing and adjusting a spline emitter’s shape needs a little practice and experience, but if you’re familiar with splines from illustration or 3D programs it shouldn’t take very long to achieve full control. Please note that moving one control point affects the shape of the



Introduction | 131

entire spline. To give you a better understanding of the DSpline daemon, it’s necessary to know its parts and elements.

1. The small yellow dots are the spline’s control points.2. Each yellow circle shows a control point’s radius. This radius can be seen as a zone of

influence of the control point’s settings and parameters. Particles can also be deleted when leaving the yellow circle.

3. The straight line from up to down represents the spline’s curvature or path. It will be adjusted dynamically while moving the control points.

4. The dots at the beginning and the end of the spline are tangent control points.

AffectParticles can be affected in two ways: either by “Force” or “Velocity”. The first option applies an external force, resulting in an acceleration, while the second one only modifies the velocities of the particles without introducing an additional acceleration. “Velocity” is not available for rigid bodies.

Vortex strength The “@ CP vortex” settings for all control points are multiplied with this value.

Axial strengthThe “@ CP axial” settings for all control points are multiplied with this value.

Radial strengthThe “@ CP” radial settings for all control points are multiplied with this value.

EDIT CPWhen you click on this button, RealFlow enables the edit mode for the daemon’s control points. Once hit, it turns yellow and the following settings become accessible.

Insert CPThis button requires a control point selection. Activate one of the existing points, click on the button, and the new control point is created above the currently chosen one.

Delete CPWith this button it’s possible to remove the currently selected control point.

@ CP indexEach control point has its own index number. You can quickly browse to the desired point by simply entering its index.

@ CP axialThis value represents the control point’s force along its vertical axis.

@ CP radialThis is the strength of the force that attracts or repels particles to the spline.

@ CP vortexHere it’s possible to set the strength of a vortex force around the spline’s path. It forces the particles (or objects) to orbit the spline.

@ CP radiusThe yellow circles around each control point indicate the zone of influence. The radius of these circles can be increased or reduced with this parameter. The new radius will be automatically updated and displayed in the viewport.

@ CP linkAs mentioned earlier, it’s not advised to animate the control points directly. You can achieve



Introduction | 132

much better control over the movement by linking a point to the motion of a helper object, e.g. a Null. You can link each point individually to another Null. This function opens a node picker where you can choose the desired object to be linked.

j. Wind Daemon

Particle effects in particular can profit from a wind daemon. Imagine foam and spray on an ocean, or the crests of waves. Wind is perfectly suited for the new grid-based secondary particle emitters (splash, foam, mist). With wind you can create particles trails to achieve highly realistic simulations. In addition with a k Age or k Velocity it’s possible to add some extra realism and make the particles vanish. The integrated noise function randomly disturbs the wind just as in nature.

Wind can also affect rigid and soft bodies, e.g. falling leaves or objects being pushed in heavy storms. Like many other daemons, wind forces can be bounded to limit them. The hollow arrowhead of the viewport representation indicates the wind direction. An activated bounded option allows you scale the daemon using the node’s scale settings for X, Y and Z. If you want to change wind direction, just rotate the node.

AffectParticles can be affected in two ways: either by “Force” or “Velocity”. The first option applies an external force, resulting in an acceleration, while the second one only modifies the velocities of the particles without introducing an additional acceleration. “Velocity” is not available for rigid bodies.

StrengthThis value is used to adjust the wind force. Higher values will also create higher accelerations.

Noise strengthThere’s a noise field applied to the wind daemon. To control the influence and power of this noise field you can use this parameter. Higher strength settings lead to more perturbation.

Noise scaleThis value controls the overall size or frequency of the noise. Be aware that high scale values lead to more noise.

BoundedThis option lets you choose between “Yes” and “No”. “Yes” creates a conical shape that can be controlled via 3 different settings. The bounding geometry and its dimensions are displayed in the viewport. This option also unlocks the related settings below. Alternatively you can also change the shape’s size via Node > Scale.

@ radius 1This field controls the radius of the bounding cone at the daemon’s pivot point. By default this is the upper, smaller circle.

@ radius 2Here you can specify the second radius of the bounding cone.

@ heightChange the bounded daemon’s height with this setting.

k. Vortex Daemon

With a vortex daemon you’re able to create a centre of rotation around a certain point in space. The daemon creates a force field around the centre and along a vertical axis. Both forces can be adjusted independently. The daemon provides two different methods: “Classic” and “Complex”. “Complex” vortices are closer to reality and they’re suited for tornado-like structures. Of course, the vortex daemon can be bounded, too. A bounded daemon cannot be scaled with Node > Scale. Please keep in mind that it’s necessary to perform all settings under the vortex panel.

Vortex daemons can be used with soft/rigid bodies as well. With bounded versions you can add local forces and create interesting effects, such as “mini-twisters” in combination with a wind daemon. This phenomenon can often be observed with leaves in autumn.



Introduction | 133

AffectParticles can be affected in two ways: either by “Force” or “Velocity.” The first option applies an external force, resulting in an acceleration, while the second only modifies the velocities of the particles without introducing an additional acceleration. “Velocity” is not available for rigid or soft bodies.

Rot strengthThis parameter controls the strength of the rotational force around the daemon’s centre axis. “Rot strength” accepts both positive and negative values. The algebraic signs determine the direction of rotation: positive values create a clockwise rotation, negative values lead to counter-clockwise movements.

Central strengthThe centre axis can create an attraction or repulsion force which is adjusted here.

AttenuationWith this parameter you can define the desired fall-off type. You can choose between “Linear”, “Squared” and “Cubic”. “Attenuation’s” mode of operation is comparable to light sources in 3D programs: There you also have different options how the light’s intensity should decline – the fastest attenuation is achieved with “Cubic”.

u Falls-offs can also be created for other parameters and different node types with expressions. Please go to page 256 for an introduction to this versatile field of application.

BoundedLike many others, this daemon can be bounded. To activate this option choose “Yes”. The

vortex daemon will then be displayed with a stack of 3 rings around the axis. The radius of these rings determines the zone of influence.

BoundaryHere the radius of the zone of influence is adjusted. By changing this value the size of the surrounding rings is updated in the viewport to give you a visual representation.

Vortex typeThe default type is “Classic” – a simple representation of vortex forces with a homogeneous force field obeying the given attenuation mode. “Complex” is also known as “Rankine” vortex. There, the forces reach their peak strength at a given distance from the centre. This distance is displayed as a dashed circle line around the centre.

RadiusTo use this setting, “Complex” must be chosen. “Radius” determines the distance from the vortex centre where the forces reach their maximum.

Bound SupThis setting defines the upper limit of the vortex forces and is not related to or dependent on the daemon’s boundary setting. “Sup” is the abbrevation for “superior”.

Bound InfIn the same way as “Bound Sup”, the lower force limit is adjusted here. “Inf” stands for “Inferior”.

l. layered Vortex Daemon

This daemon acts on several layers. Each layer contains independent vortex parameters, and represents a zone where the particles can rotate with different velocities and directions. It’s comparable to gas bands appearing on planets like Jupiter. There you have the same effect, when areas near the poles rotate significantly faster than equatorial zones, leading to a visible flattening and a so-called prolate spheroid.

It’s possible to control the daemon’s dimensions with Node > Scale, but this isn’t recommended. All parameters should be adjusted with the settings under “Layered Vortex”, because they directly affect the forces. This daemon appears as a line of points. Each time you select a layer, a different segment is displayed, indicating its zone of influence.



Introduction | 134

AffectParticles can be affected in two ways: either by “Force” or “Velocity”. The first option applies an external force, resulting in an acceleration, while the second one modifies the velocities of the particles without introducing an additional acceleration. “Velocity” is not available for rigid bodies.

Num layersBy default the daemon has two layers, represented by three points. You can add new layers by entering the desired number. Each layer will add a new point. It’s also possible to create a single layer by entering “1”.

OffsetThis value describes the offset of the lowest layer from the daemon’s pivot point.

Current layerTo make settings for a specific layer it’s necessary to make it active. By directly entering the appropriate layer number you can jump to the particular zone. The vertical line indicating the active zone is updated in the viewport automatically.

@ Vortex typeThe default type is “Classic” – a simple representation of vortex forces with a homogeneous force field obeying the given attenuation mode. “Complex” is also known as “Rankine” vortex. There, the forces reach their peak strength at a given distance from the centre. This distance is displayed as a dashed circle-line around the centre.

@ StrengthThis is just the intensity of the effect.

@ RadiusTo use this setting, “Complex” has to be chosen. “Radius” determines the distance from the vortex centre where the forces reach their maximum.

@ WidthHere you can define the current layer’s height represented by two points.

@ BoundedTo activate this option choose “Yes” and the daemon will be displayed with a stack of 3 rings around the axis. The radius of these rings determines the zone of influence.

@ BoundaryHere the radius of the zone of influence is adjusted. By changing this value the size of the surrounding rings is updated in the viewport to give you a visual representation.

m. limbo Daemon

This daemon introduces two (virtual) parallel planes. Particles outside and near the planes are attracted to them. You can also change the sign of the attraction to achieve repulsion, similar to changing electric charges between conductors. Between the planes the forces are zero, so the daemon has absolutely no effect on particles or bodies crossing the gap. It’s recommended to perform scale changes with the daemon’s own parameters.


Width“Width” defines the distance between the planes and also affects their horizontal expansion.



Introduction | 135

Strength 1Here you can define the force for the lower plane.

Attenuate 1You can decide whether you want to have a fall-off with the lower plane’s force or not. By default this option is set to “No”.

Strength 2Adjust the force’s strength for the upper plane with this function.

Attenuate 2“Attenuate 2” works analogue to “Attenuate 1”, but affects the upper plane.

n. Tractor Daemon

A tractor daemon consists of a plane with four vertices representing the planes forces. The differences between the individual forces are interpolated to create the force field. Only particles or objects within this field are affected. The daemon’s size is controlled with Node > Scale, though height should not be altered. For this purpose F1 - F4 are provided.

AffectParticles can be affected in two ways: either by “Force” or “Velocity”. The first option applies an external force, resulting in an acceleration, while the second one only modifies the velocities of the particles without introducing an additional acceleration. “Velocity” is not available for rigid and soft bodies.

F1 - F4 These values are used to adjust the strength values for each vertex separately. The arrows’ length is updated in the viewport according to your values and also indicate the direction of the forces.

o. coriolis Daemon

The Coriolis effect is a real global force, so scale changes won’t affect the daemon’s strength and there’s also no boundary option. The force is always related to RealFlow’s world coordinate system and its vector represents the rotation of the planet where the simulation takes place. This daemon is useful for simulating the well-known rotational motion of liquids when they disappear in a plug hole. However, in real life this effect has nothing to do with Coriolis force and it’s just a residual inertia in the fluid causing faster and faster rotation, because the outflowing fluid layer becomes thinner and thinner.


StrengthThis is the dimension of the daemon’s force.

p. ellipsoid Force Daemon

This daemon can accelerate or decelerate particles/bodies based on their speed. It’s mostly used to simulate pressurized fluids or gases. Very high gain values should be avoided.

Min velocityParticles with speed values lower than “Min velocity” will use the “Min gain” setting.



Introduction | 136

Min gainThis is an acceleration multiplier for particles in the “Min velocity” threshold.

Max velocityParticles with speed values over “Max velocity” will use the “Max gain” setting.

Max gain Like “Min gain”, this is also an acceleration multiplier for particles in the “Max velocity” threshold.

ClampIf this option is set to “Yes” it normalizes the fluid’s or body’s speed to match the values set under “Max and Min speed”.

q. Drag Force Daemon

This daemon simulates external air drag forces that slow down faster particles or bodies. A common application would be explosion effects. Without a drag force daemon the explosion would continue expanding forever. Drag force strength normal values range from 0.0 to 1.0 – however this value is often increased for creating more complex effects, such as melting particles. Values greater than 1.0 will slow down the particles/bodies quickly, even if they are exposed to strong external forces.

The shield effect influences the leading particles of the trail slowing down them down, creating the typical shield deformation as shown below. Very high drag strength values can even stop particles or bodies completely. This can cause instabilities in areas where the particles are created. With high values (> 1.0) it’s therefore recommended to use a bounded daemon to increase stability.

Drag strengthThis values typically ranges between 0 and 1, but can also accept higher settings. Settings greater than 1.0 may cause instabilities, and force particles and bodies to stop completely.

Shield effectTo activate this option it has to be switched to “Yes”. “No” disables the effect. “Yes” also unlocks the “@ shield inverse” function.

@ shield inverseInstead of slowing down the leading particles, they are accelerated. Groups of particles can be constricted from the main stream, forming groups.

Force limitWith this parameter it’s possible to restrict the daemon’s maximum strength. This setting accepts any positive or negative value.

Bounded typeYou can choose from three options: “None”, “Square” and “Sphere”. “None” does not restrict the forces to a certain area, while “Square” creates a box. “Sphere” applies a spherical domain around the centre. The size of the bounding volume can be adjusted with the daemon’s scale settings under Node. All three values can be changed independently. “Square” and “Sphere” also unlock the daemon’s ability to create an attenuated force field.

AttenuationIt’s often necessary to create a fall-off to enhance realism, because in nature, forces always show some kind of attenuation – depending on the distance to the force’s origin. You can choose from “Linear”, “Square” and “Cubic”. “Cubic” creates the fastest fall-off.

Affect vertexThis function can only be used with rigid bodies and does not influence particles. If set to “Yes” the daemon affects the vertices of rigid bodies, while “No” only affects the centre of mass.

r. surface Tension Daemon

Surface tension can only be applied to particle-based fluids. It’s a cohesive force acting on the fluid’s skin. You might have noticed that standard emitters also have a setting for



Introduction | 137

surface tension (see page 98) and basically there’s no difference between the property and the daemon. The daemon can be used in conjunction with the emitter value and acts globally on all fluid particles, regardless from their origin. Additionally the daemon has another option that prevents a fluid from breaking apart into smaller drops. This function is called “Balanced”.

Surface tension enhances a fluid’s tendency to accumulate, very similar to viscosity (see page 98). It can be used to create spherical drops or the typical dripping effect you can observe with faucets. This daemon is also suited for obtaining mercury-like effects. In the viewport the surface tension daemon is represented by two discs with different sizes. Since it’s a global force, scale changes won’t have any effect on the daemon.

StrengthThis value defines the overall strength of the daemon’s force. All negative and positive settings are valid.

BalancedYou can choose between “Yes” and “No”. With “Yes” the daemon’s force field is more homogenous and better spread over the entire fluid. It prevents fluids from breaking apart into smaller drops too fast.

s. Noise Field Daemon

Noise has already been introduced with the wind daemon (see page 132). There, the noise function gives you extra realism by adding a random force field. This daemon can be used to randomly disturb particles or objects, which is particularly useful for nebula-like effects and simulating air turbulences. Noise field can be bounded and the bounding volume is a sphere.

AffectParticles can be affected in two ways: either by “Force” or “Velocity”. The first option applies an external force, resulting in an acceleration, while the second only modifies the

velocities of the particles without introducing an additional acceleration. “Affect” has no influence on rigid or soft bodies.

StrengthHere you can adjust the intensity of the noise field

Scale factorYou can also control the overall size or frequency of the noise – higher values increase the noise’s frequency and lead to more turbulence.

BoundedThe daemon’s influence can be limited with this function. A bounded noise field is restricted to a sphere, which is displayed in the viewport around the node’s centre.

RadiusThis is the bounding sphere’s radius and is only activated when “Bounded” is set to “Yes”.

t. Heater Daemon

This is a source of heat. It can only be used with gas particles and has no effect on watery fluids, dumb or elastic particles. Hot gas particles become faster and have an increased tendency to expand – on the other hand the daemon can also cool down hot particles. The desired value is entered in Kelvin: 0°K is also known as absolute zero (-273.15°C).



Introduction | 138

AffectThe heater daemon can either have the shape of a sphere or a box and with this function you can choose between them. This also implies that the heater is always bounded.

TemperatureChoose the desired temperature and enter it here. Please remember that you’re working in Kelvin, so 0°C are 273.15 K, for 100°C you have to write 373.15 K and so on. Values smaller than 273.15 represent negative Celsius temperatures. The formula for calculating with Kelvin is roughly:

Temperature in °C (Celsius) = Entered temperature value – 273

If you use the Fahrenheit scale, it’s also necessary to perform a conversion from °F to °C:

Temperature in °C (Celsius) = ( Temperature in °F (Fahrenheit) - 32 ) · 5 / 9

SpeedYou can also add some variation to the particles to add more randomness and a more realistic behaviour.

RadiusThis value is only available with “Affect = Sphere” and defines the daemon’s dimensions. With “Affect = Box” the settings are made under Node > Scale.

NoiseBy activating the noise function it’s possible to create a more random behaviour of the gas particles. Setting “Noise” to “Yes” also activates the parameters below.

Noise StrengthHere the overall intensity of the noise function is adjusted.

Noise ScaleIt is used to determine the frequency (or “randomness”) of the noise function. Higher values create more turbulence.

u. Texture Gizmo Daemon

Every particle in a simulation can carry UVW mapping values. When the mesh is generated, its UVW grid will be created from the values in the surrounding particles. Therefore, the core UVW mapping information resides in the particles. The initial UVW values are, by default, the XYZ position, which is set when the particle is created and remains unchanged throughout the simulation.

Texture Gizmo will change the UVW mapping according to the position, rotation and scale of the daemon. The new UVW coordinates will be calculated as a flat projection with the UV values running along the flat square, and the W values increasing in the perpendicular direction. Texture Gizmo will create the new UVW values using the particles in the selected frame or when the “Texture now” button is pressed.

This daemon is useful to map a texture on top of a fluid surface. Usually the particles need to be deployed in some way before performing the desired effect. When this condition is reached, you can apply the texture gizmo to the selected frame to get fresh UVW values. These values will be then maintained throughout the simulation (unless you set “Remap in Play mode” to “Yes”).

Texture at frameYou can specify a certain point in time when the fluid becomes textured. From this moment the UVW data are generated and applied. By default this process starts at frame 0.



Introduction | 139

Texture from objTo make use of this feature it’s necessary to choose an object. Once a selection was made, the daemon grabs the UV data and applies them to the fluid.

Remap in Play modeBy activating this feature, the daemon can also be used with cached (=previously simulated and stored) particles.

Texture nowThis button has actually the same function as “Texture at frame”, but you can choose any specific point in time independently from an earlier defined frame.

v. Magic Daemon

“Magic” is one of the most powerful daemons in RealFlow and works like a “morphing engine”. This means that the daemon turns the attached object into an attractor pulling the particles towards its faces. During this process you can apply other daemons to introduce supporting or disturbing forces. They will, of course, fully interact with the Magic daemon and help you to create a more vivid and interesting simulation. This daemon is only available for use with particles.

Another idea would be to animate magic’s strength for achieving repulsion and attraction effects. Especially in combination with Python scripts, this daemon can create astonishing results. A useful trick is to use a drag force daemon combined with the Magic daemon to obtain faster convergence of the particles around the object and avoid orbiting effects. This daemon introduces a global force and cannot be scaled or bounded. Please note that the Magic daemon offers a new feature: for “Approach strength” and “Escape strength” it’s possible to use (even animated!) bitmaps instead of fixed values.


ObjectAs with other daemons, this option opens a node picker. You can select any available object from the list and the particles will finally adopt the shape of the chosen item. Please note that multi-selections are not supported. The Magic daemon works with particles only, hence it’s not possible to attract rigid bodies forming a certain shape with this type.

Approach strengthTo control the force at which the particles are attracted to the target object, this value is needed. Higher settings create a clearly visible overshoot, where the particles can partially leave the object of interest and become attracted again. This results in a more or less dynamic wobbling, depending on “Approach strength”. Instead of a fixed value, that’s valid for the entire object, it’s also possible to apply a map, defining stronger and weaker zones of attraction.

Escape strengthIt’s often necessary to use a higher “Approach strength” to make the particles quickly approach the target object, but this might lead to unwanted overshooting. With “Escape strength” this effect can be drastically reduced, because it counteracts the attracting forces. The fluid calms down faster and the target shape is reached in less time. With high settings you can probably observe orbiting particles. Like its counterpart, “Escape strength” also offers the usage of bitmaps. To apply a map, right-click on the parameter and choose “Load texture” from the context menu.

Overshooting particles and the damped version with a high counteracting “Escape strength” value.



Introduction | 140

Magic strengthThis parameter determines the strength of the attraction force introduced by the object. Larger values accelerate the shaping process and the particles will better match the underlying 3D model.

Magic ModeThe daemon provides two options. “Nearest Face” is the most commonly used mode and causes the particles to travel to their nearest polygon. With “Random Face” you can introduce a turbulent distribution of the particles.

Random within FaceYou can choose between “Yes” and “No”. When this option is activated the particles will constantly change their position over the object’s surface. This mode is also called “dancing mode”.

w. object Field Daemon

This type is very similar to the magic daemon, but there are two fundamental differences:

1. Object field uses vertices for the attractor forces instead of faces.2. You can specify a certain limit within the particles to be affected.

The object field daemon does not achieve the high quality of the magic type, but you can also get some very interesting effects, for example with a negative strength, representing a repulsion force, and high surface tension (around 50.0) for the fluid.

AffectParticles can be affected in two ways: Either by “Force” or” Velocity”. The first option applies an external force, resulting in an acceleration, while the second one only modifies the velocities of the particles without introducing an additional acceleration. “Velocity” is not available for rigid bodies.

ObjectOpen a node picker to choose the desired object for creating a force field.

StrengthThis parameter controls the amount of force that will be applied to the object. You can either enter positive values for attraction or negative ones for repulsion effects.

DistanceHere you can define the daemons scope or action limit. Particles are affected within the given distance. “Distance” is measured in RealFlow grid units (meters).

x. color plane Daemon

Color plane is a versatile and powerful tool for visualizing various properties of a particle-based fluid. It provides an extensive list of features and settings to make attributes like pressure, density, velocity and temperature visible. It’s also the only daemon that has an export option under Export Central. You can decide whether you want to store the numerical data or an image sequence.

The field can either be represented as a coloured grid, a textured plane or as a set of isolines. Color plane has a fixed sampling resolution, which can be adjusted by the user.



Introduction | 141

The “Grid” option is selected as default, while other modes can be accessed using the “Color plane” panel or the View menu. A textured view can be activated via

View >Scene >Textured

If you want to switch back to the “Grid/Isoline” mode, simply choose the wireframe view again. The background can be changed using the “Color” property in the Node panel.

FieldYou can choose from these attributes: “Pressure”, “Density”, “Velocity”, “Velocity x, y, z” and “Temperature”. “Temperature”, of course, is only available with gases.

Viz. MethodThe first option is “Projection”. It draws the field values from particles vertically onto the plane, similar to plain or flat projection methods in 3D programs. Only particles within a fixed vertical distance of the plane contribute to the final plane colours. “Interpolation” performs a weighted interpolation of the surrounding field values for each of the plane’s sample locations. This provides a more physically accurate representation of the field.

Projection methodThis setting is only visible with Viz. method’s “Projection” mode. “Exhaustive” examines

all emitter particles to determine those which can contribute to the plane colour values. “Local” searches locally for the particles that will be considered for the final colour values. Under some circumstances – typically with small particle counts – ”Exhaustive” may be faster than “Local”. The “Local” mode is recommended for large particle counts. Please note: When choosing “Local” the maximum and minimum values are local maxima and minima.

Projection rangeAgain, this parameter is only visible in “Projection” mode. Particles with a vertical distance smaller than this value are used for printing marks on the plane, others are ignored.

Sampling res.This determines the resolution of samples to write out the colours. A higher resolution produces more details on the plane, but needs longer to calculate. The default of 0.02 is equivalent to a 64 x 64 sampling of the plane.

Auto RangesBy default this option is set to “No” and all values are automatically calculated. When set to “Yes”, the following two fields are accessible to enter custom values. This setting can be used to clip certain values and works very similarly to an emitter’s “Automatic range” function under “Display”.

Minimum The minimum value of the visualized field. It’s only editable when “Auto Ranges” is switched off.

MaximumThe maximum value of the visualized field. It’s only editable when “Auto Ranges” is switched off.

Color MapYou can select from “RGB”, “Grayscale” and “B&W”, which is black and white.

TransparencyThis value can range between 1.0 (opaque) and 0.0 (completely transparent).

Gamma It’s possible to raise the normalized “Field” values to enhance the plane’s gamma value.



Introduction | 142

Height FieldThe normalized values can displayed as 3-dimensional peaks. These spikes are also coloured to show areas of higher and lower field values. You can choose between Yes and No to turn this feature on or off.

SmoothingThe field values are interpolated to achieve a more continuous distribution of colours.

Iso-lines?Areas with identical field values (pressure, velocity, density etc.) are drawn as lines of equal colour. This function is similar to a weather map, where you can see lines around high or low-pressure areas, indicating areas of equal air pressure. You turn this function on with “Yes”.

No. Iso-linesThe default number of “Iso-lines” is 10. You can alter this value to your needs.

Image widthHere you can define the width of the colour plane in pixel. This also represents the size of the exported images.

Image heightHere you can define the height of the colour plane in pixel. This also represents the size of the exported images.

y. scripted

Scripted daemons are fully customizable, because they can be programmed to your individual needs. By default, they don’t add forces or delete particles and their entire functionality is based on custom Python scripts. To use a scripted daemon you first need to apply it as usual and then edit it. As already mentioned, the use of scripted daemons requires Python knowledge. The scripting compendium for RealFlow 5 contains a comprehensive introduction to Python.

EditWhen you click on this button RealFlow opens a new scripting window with predefined functions. This window contains a set of basic functions that can be used to influence emitters, particles or rigid bodies.

z. Filter Daemon

This new daemon is a very convenient way to swap particles from one emitter to another. Before this daemon was introduced this was a pure scripting task (see page 268). Now you can do this much faster with built-in functions, though there might be moments where you have to use the scripted approach. The filter daemon requires two emitters: a source emitter and a target. You can choose any emitter as a target. Unlike the scripting technique, the target’s emitter speed doesn’t have to be 0.0 here. Even though you’re adding more particles to the target emitter, the fluid remains stable. Even other physical properties, like “Density” or “Int Pressure”, can be different.

For an easy workflow, it’s best to use the new container emitter. This is nothing but an empty bin which gathers the swapped particles from the source.

Source EmitterDefine the particle source by choosing an existing emitter from a list.

Target Emitter (True)Ideally this would be a Container emitter, but you can use any other available type as well.



Introduction | 143

“Target Emitter (True)” is the emitter where the particles will be moved to when the adjusted condition is true. This field doesn’t necessarily need an entry and can be left blank to delete the particles.

Target Emitter (False)In contrast to the previous emitter, this one’s used when the condition is not fulfilled (=false). The default workflow is to use the same emitter for “Source Emitter” and “Target Emitter (False)”. Please keep in mind that every source particle will be evaluated and finally be assigned to one of the target emitters. The usage of three different emitters for source and targets is the most common source of errors and should be avoided. This field doesn’t necessarily need an entry and can be left blank.

ConditionYou can select the desired condition by simply choosing one of the predefined options. The daemon provides a total of 8 conditions. These conditions tell RealFlow when a particle has to be transferred – once the selected condition is fulfilled, the particle will be attached to the target emitter and removed from the source. It’s even possible to define an expression to define your own condition.

A very special case is called “In Range” or “Out of Range”. By activating these options, the fields “@ Min Value” and “@ Max Value” are unlocked. You can then define a range with a minimum and a maximum value which will be used for this condition.

@ AttributeWhen you’re shifting particles you also need an attribute to be compared. If the condition of the comparison is fulfilled, the particle is swapped. The attribute, of course, needs a certain value for the comparison, e.g. “If Speed is greater than 2.0 then shift the particle from the source to the target emitter”. In this case, “@Attribute” is “Speed”, the value is 2.0 and the condition is “greater than”. You can choose from many different attributes like position, velocity, pressure, age, density and much more.

@ ValueThis is the trigger value for the condition. Simply enter the desired value. Please note that this field is inactive with “Condition” set to “In Range”, “Out of Range” and “Expression”.

@ Min/Max ValueWith “Condition” set to “In Range” or “Out of Range”, these fields become unlocked, giving you the possibility to define a range between these two settings.

@ Expression You can enter any valid expression here that serves as a given condition. This tool is surely the most complex filter, but also offers a wide variety of possibilities. Please read more about expressions on page 252 and the following. The explanations there are also valid for the Filter daemon.

“@ Expression” offers a long list of available keywords. These are used to address certain features of a particle. RealFlow constantly checks against these attributes during a simulation and decides whether the condition is fulfilled or not. This is a very effective and fast way to create flexible conditions and is suited to many applications.

Attribute Expression keyword

Velocity particle.speed, particle.velocity.x, particle.velocity.y, particle.velocity.z, particle.vel.x, particle.vel.y, particle.vel.z

Position particle.pos.x, particle.vel.y, particle.vel.z, particle.position.x, particle.position.y, particle.position.z

Vorticity particle.vorticity.mod, particle.vorticity.x, particle.vorticity.y, particle.vorticity.z

Normal particle.normal.x, particle.normal.y, particle.normal.z

Neighbors particle.nv, particle.neighbors, particle.neighbours

Texture particle.texture.u, particle.texture.v, particle.texture.w

Age particle.age, particle.isolation

Viscosity particle.viscosity

Density particle.density

Pressure particle.pressure

Temperature particle.temperature

Mass particle.mass

Collision particle.collision

ID particle.id



Introduction | 144

Attribute Expression keyword

Velocity particle.speed, particle.velocity.x, particle.velocity.y, particle.velocity.z, particle.vel.x, particle.vel.y, particle.vel.z

Force particle.force.mod, particle.force.x, particle.force.y, particle.force.z, particle.f.mod, particle.f.x, particle.f.y, particle.f.z

SplitThis feature should already be known from other RealFlow daemons, for example k Collision. When set to “Yes”, RealFlow will create more particles based on the number of childred, given in the following parameter. This feature is perfect for spawning foam particles.

@ # childThis settings is only available with “Split = “Yes” and you can specify the number of child particles here when a certain condition is fulfilled. You should start with moderate “@ # child” values first, because the amount of generated particles can become really huge within a short time.

Override Target (True/False)By default, both options are set to “No”. This feature is needed when you have to work with emitters in cache mode, Binary Loaders or NBinary Loaders. These emitters are cleared with each frame and load new particles from already saved BIN files. So, using them as source emitters would lead to instabilities, because the particles won’t be moved, but simply copied. If you also clear the target emitters with each step, you can avoid these problems. Please note that the result with this mode might slightly differ from the original simulation of the source emitter.

aa. sheeter Daemon

No doubt you will have noticed the problem of getting unwanted holes in thin or highly accelerated fluids, creating a torn look. There are ways to reduce these gaps, for example by increasing “Surface tension” or “Viscosity”. Other methods are based on RealFlow’s drag force daemon or high “Friction” settings, when there’s particle-object interaction.

However, these approaches all share one major disadvantage: they all strongly influence the behaviour and look of a fluid. Moreover, if particle velocities become too high, even strong decelerating forces won’t help anymore.

Higher velocities create more holes and the fluid looks torn.

To avoid these holes and create the impression of thin “sheets” of fluids, in RealFlow 5 we have added a new Sheeter daemon. This daemon is able to detect holes and fill them with particles, without increasing the emitter’s “Resolution” value. The result is a smooth stream of particles, perfectly suited for high-velocity and slow-motion simulations, or fluid-object collisions. The Sheeter daemon is fast, accurate, keeps the fluid stable and is very easy to use. You can control the entire process with just a few settings.

Max cavity sizeHoles with sizes larger than this threshold value will be filled with particles. The gap



Introduction | 145

between a new particle and its nearest neighbour won’t be filled if the gap’s size is greater than “Max cavity size”. This parameter has no dimensions. The reason is that it has to be independent from an emitter’s “Resolution” and to avoid very small gaps which can’t be handled by the fluid solver anymore. "Max cavity size" is a sensitive parameter and the lowest possible value is 1.0.

Max cavity size = 1.0 Max cavity size = 2.0

The images above show RFRK meshes with the "Velocity" magnitude activated. The smooth velocity distribution indicates that the new particles are seamlessly integrated into the existing particle cloud. The new particles aren't just added at certain areas, they completely obey the equations of fluid dynamics. You can also see that the process of filling holes dynamically yields completely different results.

u Please note that particles might be created inside objects during the filling process. This behavior can be diminished by setting the "Max cavity size" parameter to a lower value. Another method is to place one or more k Volume daemons inside the object. In future versions this limitation will be removed and RealFlow will automatically remove particles from the inside of objects.

Use relative speedHere you can choose whether you want to take the particles’ relative speed into consideration or not. The activation of this parameter (“Yes”) unlocks the following two settings.

@ Min relative speedVery high velocities are often responsible for unwanted holes. Gaps will only be filled if the particles’ relative speed is greater than this value.

@ Max relative speedThis parameter checks for particle velocities which are below the given value. If the measured velocity has gone below “@ Max relative speed”, the gap will be filled.

Use ageIf you want to consider the particles’ age, this parameter must be set to “Yes”. Then you will also have access to the associated “@ Max age” parameter.

@ Max ageIf the age of the particles around a hole is smaller than the entered value, the gap will be filled. The unit for this parameter is seconds.

Cavities detection ratioThere are cases where it’s not wanted to fill all holes, for example to keep a fluid more vivid and diversified. This parameter is an easy means to adjust the amount of holes which will be filled: a value of 1.0 means that all gaps will be filled with particles (= 100%). With 0.5 only 50% (approx.) of the holes will be closed and 0.0 completely disables the process.

Cavities detection ratio = 0.25 Cavities detection ratio = 0.75



Introduction | 146

9.04 pluginsPlug-ins are external modules to enhance the functional spectrum of a software. RealFlow now gives you the possibility to either create your own plug-ins or purchase them from 3rd party companies or vendors – if available. When you intend to write your own plug-ins, you have to be proficient in a programming language – preferably C/C++. Then you’ll be able to read the Software Development Kit (SDK), which provides the interfaces and data structures for most of RealFlow’s functions. They help you to directly access certain parts of the software and modify them to your needs. If you already have experience with RealFlow’s Python scripting interface, then you should become familiar with the C/C++ SDK quickly.

Once you have installed a plug-in it appears in a list and you can select it like any other daemon. For this purpose, either go to the Icon Bar choosing the daemon’s symbol or visit

Menu Bar > Edit > Add > Daemon > Plugins

RealFlow 5 comes with several daemons, for example Morph and CrowdFlow, and there are also some complete examples available under RealFlow's SDK folder. There you can go through some C++ programs, which give you detailed instructions on how to create your own plug-ins.

u There's more information about plug-ins on page 260.



Introduction | 147

10 RealFloW oBJecTs

RealFlow provides a couple of predefined objects, ready to use with your simulations. They actually have the same function as the standard objects in your 3D software, and they’re fully scalable. Additionally, they carry UV grid data for texturing effects. Another advantage is that they can be easily addressed with RealFlow’s Python scripting. Of course you can enable rigid body and soft body dynamics features, including all the specific parameters for interactions with fluids, waves or other dynamic objects.

Native objects are easy to handle and they’re applied either via simple drag-and-drop from the Icon Bar or RealFlow’s other methods for adding nodes:

Menu Bar > Edit > Add > Object > [ choose object type ]

Right mouse menu > Add > Object > [ choose object type ]

RealFlow offers a total of 12 native objects that can be added and there’s (virtually) no limit for the number of individual objects within a scene. If you have large amounts of similar objects, it’s recommended to group them, because this allows a fast change of common Node Params, such as mass or scale.

A selection of RealFlow’s native objects.

Though RealFlow objects are really straightforward, there are a few recommendations:

• Never use identical names for objects. Each object must have an individual name to separate it from the other items of the same. Doubling names only lead to problems during simulation and exporting to your 3D software.

• Avoid special characters or dots in your objects’ names. Only use A-Z, a-z, 0-9, the hyphen and the underscore.

• Objects cannot be modified in terms of polygon or vertex number by RealFlow’s GUI. With Python scripting you have access to these settings and you can change or modify them. It’s even possible to create your own custom objects with scripting by using the Vertex.new() and Face.new() functions.

Imported objects behave in exactly the same way as RealFlow’s native and built-in bodies and even multiple formats are supported. They can also be exported as physical objects (OBJ format). Additionally all position and rotation changes during the simulation are recorded and written to SD files.

One of the most exciting features with RealFlow’s objects is their ability to carry wetmaps, based on a UV grid. You can easily activate and control this process with a few clicks from the Texture panel. The result is a series of grey scale images, used as a mask for texturing. Inverted maps are also suited for simulating erosion effects! It’s also possible to “drench” imported objects with UV coordinates. Please keep in mind that UVs have to be arranged properly to get correct results. Since RealFlow doesn’t provide tools for UV manipulation, this has to be done within your 3D program.

The generation of wetmaps can also be watched in the viewport during simulation.

10.01 common settingsAll of RealFlow’s objects share exactly the same settings, so the following descriptions are valid for all nodes – even for the new MultiBody object and imported geometry from SD or other files. Aside from orientation and visibility settings, RealFlow provides different panels for all relevant solvers, including a separate panel for interactions with RealWave surfaces.



Introduction | 148

a. The Node panel

The Node panel works exactly like the panel from other RealFlow node types, e.g. emitters. Scale, rotation and position changes can be changed exactly with these parameters. You can also animate most of the settings (except “Pivot”, “Parent to” and “Shear”).

SimulationMakes the selected node active or inactive. Inactive objects are still visible, but not taken into consideration for the simulation: they’re invisible to RealFlow’s solvers. Inactive objects can be made active at any time and they’re displayed in a dark-reddish colour; in the Node window they’re greyed out.

A very interesting option is “Cache”, because it allows you to use previously calculated movements within a new simulation. This feature is mostly used with particle-object simulations and RealWaves. “Cache” mode only works with individual Animation (.sd) files. The global ANIMATION (.sd) and CACHE (.bdc) formats don’t support caching. For more information about these file types, please visit page 61, “Exporting Objects”.

DynamicsYou can choose between “No”, “Rigid body”, and “Soft body”. The last two options append extra panels to the Node Params window. The appropriate settings are discussed separately on page 154 (Rigid body) and 156 (Soft body). Once the dynamics option has been applied, the node changes its behaviour. Objects without dynamics can still interact with fluids, e.g. as steady objects, but they’re not seen by other (rigid/soft) bodies.

Position Here you can define the position in 3D space. Each value stands for one coordinate: X, Y and Z. Please remember that the height axis depends on your 3D software and the adjusted preferences. With a wrong setup, imported objects appear flipped – that’s of special importance with imported nodes and scripting.

RotationThe mode of operation is equal to “Position”.

ScalePlease have a look at “Position”, because it works exactly the same way.

ShearWith this tool you can add distorsion to your objects to modify their geometry.

PivotThis is the centre of rotation. By default it’s located in the geometrical centre of an object, but can be displaced to achieve other interesting motions. Again, there are three values for each axis.

Parent toYou can choose any item that’s listed under the Nodes panel and parent the currently active object to it. If the higher-ranking object (= parent object) is moving, the linked item (= child) will follow these motions. Truly a great feature for aligning movements!

ColorThis option determines the colour of the unselected object in the viewport. You can choose any predefined or custom RGB value available in your OS.

SD <-> CurveThis little helper is only available with imported objects. By default, imported nodes from SD files are locked to protect their initial settings, but with this button they can be made editable. It can be applied individually to all objects from the currently used file. A very nice feature of “SD <-> Curve” is that you can perform different position, rotation or scale changes, and when you click on this button again, all transformations are reset – even animation data. As the name indicates, this option is only available for objects from SD files and has no influence on imported OBJ or LWO nodes.



Introduction | 149


Yes, even objects can have an initial state and the workflow is exactly the same as for other nodes, but in this case the position information is, of course, not stored within a BIN file, but a SD. It makes no difference whether you’ve activated the node-specific animation (.sd) file or the global ANIMATION (.sd) type under Export Central.

Use Initial State Choose “Yes”, if you want to work with an initial state, otherwise leave it to “No”.

Make Initial StateThis button exports the current settings, conditions and states of the selected object and stores the necessary information to a SD file. This file is read and used if “Reset To Initial State” is activated. The simulation will start again from the initial state. On page 96 you can find a short workflow on how to create an initial state.

Tc. he Grid Fluid Interaction panel

Objects also have the possibility to interact with grid fluids, but the number of settings is limited. The reason is that grid fluids are used as the core of fluid, while detailed interactions are created with standard emitters. In many cases, objects are used to push the fluid along a certain direction to create breaking waves. For all these applications a large set of parameters is not required.

Grid frictionThis parameter can be mapped: it’s possible to load a texture map with different grey scales, representing different zones of friction. You can even use an image sequence for this purpose. To load an image map, right click on the parameter:

Node Params > Grid friction > Right click > Load texture

A new window is opened, showing various settings for importing the desired images(s). You can read more about settings and functions on page 152. Another method is to enter a global “Grid friction” value, which is constant and valid for the entire object.

Raster modeYou can choose between “Dynamic” and “Static”. “Dynamic” is the default setting and should be used for moving objects, for example ships or floating items. “Static” is the setting for all resting, immobile bodies, such as walls.

u Selecting the correct “Raster mode” is essential to speed up simulations with grid fluids and objects, because dynamically rasterized nodes will waste a lot of CPU time you’d better use for your simulation!

d. The particle Fluid Interaction panel

This panel is only visible with an emitter present in the currently opened scene. It governs and controls the interaction between particles and the object, and each object has its own Particle Fluid Interaction settings. These parameters are also responsible for surface properties, like friction.

One of the most common errors with particle-object interaction is interpenetration. In this case, particles can pass through a solid object and become isolated from the rest of the fluid. Such a behaviour is often related to “Collision distance”, substeps, scale and your object’s geometry. The following explanations do not only explain basic functionality, but also give you valuable tips on how to avoid these problems. Please keep in mind that RealFlow automatically adjusts “Collision distance” when scene scale becomes changed.



Introduction | 150

You can see five parameters with little chessboard icons. These symbols indicate that you’re able to load a RGB image map, representing different zones of friction or roughness, for example. RealFlow interprets the picture’s grey shades and translates them into values. This feature also makes use of UV coordinates, so please don’t forget to relax the object’s UV before export. To load a map please right-click on the appropriate parameter and choose “Load texture”.

Collision distanceThis is probably the most important and most critical parameter. You can adjust the distance between the particles and the polygons of the object, and create gaps or perfect representations of the item’s shape. Lower values increase simulation time, but are also more accurate. Larger objects require greater values, but small bodies should have lower settings – something that’s especially important for scale changes, too. If particles are still penetrating the polygons, higher “MIN” and/or “MAX substeps” (see page 40) should be considered. You can find an illustration of “Collision distance’s” effect in the images on the right.

u RealFlow automatically adjusts “Collision distance” by default, but after scene scale changes, it normally has to be corrected. Good values are around 1% of the object’s largest “Scale” value found under Node.

Collision distance = 0.01 Collision distance = 0.1

Distance toleranceBy increasing this value, RealFlow randomly spreads the particles to avoid perfect boundary layers. However the SPH specific layers cannot be removed completely with this parameter. If you want to get rid of these layers, you should consider a scale change, too. “Distance tolerance” ranges between 0.0 and 0.95.

Collision normal This parameter provides three settings: “Both”, “Inward” and “Outward”. It controls which side of the object’s surface will interact with the particles and is great for filling containers from outside particle sources, for example.

“Collision normal” set to “Inward” allows the filling of closed objects.



Introduction | 151

zones of roughness, leading to variable flow rates. The black parts are the areas with the lowest roughness, increasing from dark to light. The underlying map is visible in RealFlow’s “Flat Shaded” mode. When you have a look at the Node Params settings for “Roughness”, you’ll also see that the parameter now has a purple colour, telling you that a map is used.

RealFlow’s mapped parameters allow the creation of zones with different properties.

TemperatureThis value only affects gas particles. Gas particles strongly react to temperature changes. Higher temperatures make them rise due to higher (internal) pressure, while low settings are responsible for cooling effects, causing the particles to sink. “Temperature” is measured in Kelvin and therefore no negative values are allowed. 0° K represent -273.15° C or -459.67° F.

ConductivityAgain a value that’s only valid for gas particles. Here you can control the transfer of heat between the particles and the object. A value of 0.0 means that there’s no heat transfer at all. “Conductivity” accepts very high values and is directly related to “Temperature”, which is a measure for the object’s heat energy.

Thin face testYou can choose between “No” and “Yes”. Normally, this parameter isn’t needed, but there might be cases when the particles are separated by a thin wall. Under such a circumstance the particles would interact with each other, though they should not do so. To avoid these interactions, “Thin face” test must be enabled.

Collision toleranceIf you have to create porous or leaky objects, this value is the perfect choice. With 0.0 you can completely prevent particles from passing through the object. A setting of 0.5 will cause 50% of all particles to go through the object’s surface. 1.0 completely suppresses interaction. “Collision tolerance” supports image-based parameters.

Particle FrictionHere the resistance of a surface is specified. A value of 0.0 creates absolutely no friction and a perfect surface. In nature, objects always have a certain amount of friction, because there are no perfectly even surfaces. Higher values can even completely stop particles from moving. With very high settings above 2.0 you may see exploding or escaping particles. Friction is very sensitive and should be changed carefully. Please also consider using an image map instead of a global value.

Bounce Bounce represents an surface’s elasticity in terms of object-particle interaction. It does not affect rigid body object-object interaction and elasticity. A value of 0.0 creates perfect elasticity; higher settings make the particles lose appropriate amounts of their energy. Extreme values should be avoided. The best working range is between 0.1 and 0.8. Instead of entering a global value, you can also use an image map.

StickyIt can be seen as a “glue factor” to make particles stick on the object’s surface. This parameter accepts very high values and can also be adjusted to negative settings for repelling effects. Completely exaggerated values may add high accelerations to the particles and lead to unwanted results. Use a value similar to gravity as a reference and then adjust it until you get the desired effect. Please note that sticky only works with static objects. By right-clicking on the little black and white icon, you can load a bitmap to replace the given setting.

RoughnessSimilar to friction, each surface contains a certain amount of roughness. In RealFlow, this value adds some randomness to the object’s polygon normals to produce a slightly different collision direction. This leads to a much more realistic behaviour. High values can cause the same problems as friction, and it’s also a very sensitive parameter, ranging between 0.0 and 1.0. This setting also supports image maps.

The example on the right shows an image attached to plane. The stripes indicate different



Introduction | 152

From “Channel” you can choose one of the picture’s RGB channel. The currently active channel is shown in the canvas and updated according to your selection. “Min. value” and “Max. value” are, by default, the pixels’ intensities. They’re spread over the available minimum and maximum range of a parameter but, in case of need, this range can be clipped by entering new values. The shades of the image channel are then spread over the given settings.

“Min. frame” and “Max. frame” are important for image sequences. You’re able to specify a certain frame range that is used for parameter mapping. Simply enter the desired start and/or stop value and the frames outside of this range will be ignored.

With “FPS Ratio” set to 1 the image sequence is played at its original speed, e.g. 30 FPS. If you want to achieve faster or slower playback then you have to change FPS Ratio accordingly. Values above 1 will increase playback speed; smaller values are used to slow it down. If you don’t want to start with the first frame of your sequence, you can determine an “Offset” from which the series will start playing.

Particle forceEach particle carries a certain amount of motion energy related to its velocity. With activated rigid body dynamics, this energy can be transferred to the object making it move. By altering “Particle force” you can decide how strong the object will be moved by the fluid.

Impulse This setting works like a repulsion force, similar to a jet or a rocket engine. It can only be set to “Yes” or “No”, without options to control the strength of the impulse.

Mapped parameters

You’ve already read that several attributes can be represented with image maps – here is some additional information. Image maps create areas of different influence, based on the colours of a picture. The adjustments are made from a separate window, providing all relevant parameters and switches to make use of this new feature. An additional function is that you’re even able to load image sequences for animated parameters.

Especially larger objects can strongly profit from this feature. You can, for example, create a river bed with low “Particle Friction”, while the outside areas have higher values. All this can now be painted to a map and then projected onto your object. This does not only work with RealFlow’s native items, but also with imported objects from SD files. It’s important that imported objects carry (correct) UV coordinates.

If you want to replace the fixed value with an image map, please do the following:

1. Right-click on one of the parameters with a chess board icon.2. Choose “Load Texture” from the context menu.3. RealFlow opens a new window called “Load Texture for Parameter”.4. Fill out the dialogue and confirm your settings with “OK”.

Under “File” you can load one or more image files with TGA, BMP, JPG, PNG or TIF format. The path to the image is shown under File. With the “…” it’s possible to open your OS’s file picker. The images must be coloured – either 8 bit, or if supported, also 16 bit. Image sequences are recognized automatically and you don’t have to select the first and the last frame. All files with an equal padding are loaded to the canvas.



Introduction | 153

The “Loop” option creates an infinite forth and back loop from the currently loaded image series.

Control buttons work exactly as in other video player. You can go to the first or last frame, to the previous or following frame, and start/stop playback. The slider allows you to scrub through the entire sequence and jump to a certain frame.

Finally, the “Skip” option is related to “FPS ratio”: while playing back an animated sequence, RealFlow cannot always achieve the given FPS rate. By checking “Skip”, RealFlow will play the image sequence with the adjusted FPS rate, but some images might be dropped. Without “Skip”, RealFlow shows all images, but there’s no guarantee that the desired frame rate can be maintained.

e. The Texture panel

With this feature it’s possible to either apply a texture map onto the object, or create wetmaps from interactions with particles. If you want to see the object textured, you have to switch RealFlow’s viewport to textured:

View > Scene > Textured

Another option is to choose Show texture > Yes under the node’s Display option. Please note that RealFlow uses an object’s UV coordinates and these coordinates are also used to generate the wetmaps. So if your UV coordinates are corrupted, overlapping or not relaxed, the results are most likely not what you would expect. To get rid of improper texture effects, it’s necessary to reprocess UV coordinates with an adequate software.

u If wetmaps are not displayed or created correctly it’s very likely that the UV grid of your (external) object is either not unwrapped or wrong. Some plug-ins also don’t allow the use of a texture tag while exporting the object(s). In other words textures have to be removed before the object is exported.

Load TextureIf you want to apply a texture map then you’re able to load an appropriate file with this dialogue.

WetDry textureThis feature only makes sense in combination with particles. Each interacting particle can leave a mark on the surface of the object. A variety of different filters are also unlocked to define parameters like strength or drying speed. WetDry textures are automatically created by RealFlow and do not need a previously applied textured! To store the textures it’s also necessary to choose an image format and the appropriate output function under Export Central (see page 62).

@ resolution WetDry maps are always square-shaped and therefore there’s only one value given. The default size of a map is 256 x 256. Of course you can create much bigger images, but they can slow down the simulation significantly. Resolution also strongly depends on the complexity of your objects and the desired camera view. Even cubes might require larger maps if you require a close-up shot. @ filter loops #To blur the generated image maps, it’s possible to activate a filter. Here you can determine how often the filter should be applied. Higher settings create more blur, but take longer. Despite the built-in filter, it’s recommended to use an image processor to enhance maps.

@ filter strengthHigher settings enhance the blur effect and can even tear apart the tone values. It’s better to use rather low values and perform further adjustments in image or video processing programs.

@ pixel strengthBy default, RealFlow uses 256 grey shades to calculate “WetDry” textures and the range goes from 0 (black) to 255 (white).



Introduction | 154

@ ageingSome materials can dry much faster than others and this behaviour can be simulated with RealFlow. Higher settings make the wet patterns disappear faster. A value of 0.0 makes them last forever.

Wetmaps from sphere emitters with @ filter strength = 0.5 and @ageing = 0.5

f. The Rigid Body panel

Similar to Particle Interaction, this panel is only available on demand. Rigid body dynamics is not limited to object-object interaction, but also possible with fluid-object interaction, soft bodies and RealWave surfaces. All the different solvers are coupled and for that reason it’s, for example, possible to move objects through the power of a fluid or a wave. As a rule of thumb we can say: If there’s an object meant to be moving or colliding, rigid body dynamics must be enabled. The only exception is the combination of solid obstacles with fluids – in that case it’s not necessary to activate this feature.

u RealFlow’s rigid body and soft body solver “Caronte” is no longer dependent on substeps. The only settings that can influence the quality of a simulation are the quality settings under “Simulation options”. There you can choose between “Low”, “Medium“and “High”.

To enable an object’s rigid body dynamics feature, please go to

Node Params > Node > Dynamics > Rigid body

PrimitiveEach rigid body needs a surrounding geometry for collision detection and that’s exactly what “Primitive” does. You can choose from various basic shapes or from exact representations of the active object. The less complex the selected shape, the faster the simulation will be calculated, but with simple approximations, accuracy is often not high enough and you might see interpenetration effects. For large amounts of objects or nodes with many polygons it will take a little time until the desired primitive type is applied.

You can choose from 4 different shapes: “Sphere”, “Box”, “Convex Hull” and “Mesh”. The first two options can be used for nodes with an equivalent shape, while “Convex Hull” and “Mesh” are suited for more complex bodies. “Convex Hull” approximates the given shape with a bounding grid; “Mesh” exactly represents the entire object.

Sphere Box Convex Hull Mesh



Introduction | 155

Collision sideThis entry is only available with “Primitive” set to “Mesh” and offers a very interesting feature. You can choose which side of the node’s polygons should be used for collision and interactions. With “Inside”, for example, you can quickly fill objects with rigid bodies, like filling candy into a jar. The other option is “Outside”.

Dyn motionYou can determine a rigid body as mobile or static. In some cases it’s necessary to let an object act as a rigid body for collisions, but it should remain static. A good example is a floor or ground object, where other bodies will fall onto.

@ massMass is one of the most important parameters with rigid bodies, because it strongly influences the object’s entire movement and behaviour, for example the strength of splashes with RealWave surfaces. To move an object, a force is needed. Inside RealFlow forces can be introduced with daemons or other objects (also particles) hitting the body. For each object, whether it’s native or imported from external sources, RealFlow automatically calculates its mass in kilograms.

@ air FrictionIn real life, the movement of an object is always decelerated because of various friction effects – a vehicle on a street, for example, doesn’t roll forever. Even a thin medium like air produces a certain amount of friction. Normally you don’t observe this force, but with higher velocity, you’ll start to experience a growing resistance – air friction. So, if your simulation happens on Earth or a planet with an atmosphere, it’s always recommended to add a certain amount of air friction. Very high values can even stop an object completely.

@ CG“CG” stands for centre of gravity, but is actually only an offset from this specific point and not the real centre of gravity in world space. Like any geometry-related parameter, “@ CG” consists of three values. It is especially useful for floating objects, because by shifting the centre of gravity downwards, you can prevent a body from tipping, for example.

@ VelocitySometimes you don’t want a simulation to start from zero, but the objects do need an initial velocity. This parameter assigns such a behaviour by simply entering positive or negative values. Keep in mind that “@ Velocity” directly determines the body’s trajectory and a value of [ 2,0,0 ], for example, creates a linear motion along the positive X axis.

@ Rotation WThis parameter actually works the same way as “@ Velocity”. Instead of an initial velocity, you can add an initial rotation mostly to avoid a uniform look. You also have three values and each one is measured in degrees. Negative angles are, of course, accepted.

Complex rigid body interactions with different parameter settings.

@ object frictionObject friction occurs when bodies with uneven surfaces interact. Since there are no perfectly even surfaces in the real word, a certain amount of friction is always recommended for believable simulations. “@ object friction” slows down the object and can even stop it completely. Nevertheless it’s totally up to you if you want to eliminate friction completely. The maximum value for “@ object” friction is 1.0. If you have many objects in your scene, it’s a good idea to apply different values for more realism. For this purpose, a script is surely the best solution...

@ elasticityEach object has a certain amount of elasticity, making it bounce. The highest possible value is 1.0, and with this setting (“@ air friction” and “@ object friction” must both be 0.0 in this case!) the body would bounce forever, because it doesn’t lose energy. This, of course, can only happen inside RealFlow, because in nature there are no perfectly elastic objects.



Introduction | 156

g. The soft Body panel

This panel is only visible when the object’s soft body dynamics properties are enabled from

Node Params > Node > Dynamics > Soft body

Soft bodies are deformable and elastic objects, for example cloth, rubber or jelly. With RealFlow 5, this solver has been completely reprogrammed to provide more features, more stability and better results. Users of previous versions will quickly discover that there are absolutely new parameters available. Another new feature is that soft bodies can now keep the deformation they experience (“Plasticity”). With this approach it’s possible to simulate bending metal, as can be observed after car crashes, for example. These sophisticated possibilities open up a whole new world of soft body dynamics and, of course, the new solver can interact with particles, rigid bodies and waves. Soft bodies also support Joints – RealFlow’s “invisible” connection between dynamic objects. Object dynamics are now ruled by a single solver and not split up anymore. Therefore, the well-known particle representation of soft bodies has disappeared.

MassA dynamic object always needs a certain amount of mass to become influenced by forces. In RealFlow, mass is always given in kilograms and the initial value is calculated automatically. Actually, the “Mass” parameter from the “Soft body” panel has exactly the same mode of operation and functionality as its counterpart in “Rigid body”.

ResolutionHigher settings create a more detailed simulation of the soft body, but also need longer calculation time. The idea behind this parameter is to make the body react much more accurately with more deformations. All in all, “Resolution” strongly enhances a simulation’s realism. The default value is 64, but can be raised to a (virtually) infinite level.

Reversible deformations of various squeezed soft body objects.

Length stiffnessFormally, this is the length recovery constant relative to the object. A high value means that soft body offers a high resistance against changes in its longitudinal magnitudes. This parameter accepts values between 0.0 and 1,000.0.

The principle behind stiffness parameters is not so easy to explain: through its mass and



Introduction | 157

gravitational acceleration, a body has a certain self-weight. This weight always causes deformation to a soft body and the amount is measured when it rests on a horizontal plane. Stiffness affects this kind of self-loaded deformation and a value of 1.0 means that a body nearly maintains its original corresponding magnitudes under these conditions. One could say that a soft body becomes more rigid with higher stiffness settings (length or volume) and, thus, higher settings lead to more stability.

Volume stiffnessThis is the volume recovery constant relative to the object. A high value means that the observed soft body offers a high resistance to changes of its original volume. Again, your input can be between 0.0 and 1,000.0.

ElasticityTo describe a soft body’s internal motion, “Elasticity” and “Internal Damping” are the critical factors. “Elasticity” can be seen as the amount of energy that’s kept by the body when it collides or experiences the previously mentioned internal motions. It appears as the magnitude of bounces when the body collides and also as a visible “wobbling”, decreasing after a certain time. You can apply any value between 0.0 and 1.0. With 0.0, the body quickly loses all its energy and stops shivering/bouncing. A value of 1.0 results in a much longer tremble and stronger bounces.

Friction“Friction” occurs between objects with rough surfaces. In nature, even the most even surfaces have a certain amount of roughness, causing friction. It decelerates moving objects and can even stop them completely. The value ranges between 0.0 and 1.0. When bodies collide, RealFlow takes the average friction of all involved nodes into account.

Air friction“Air friction” might appear rather weak in daily life, but it’s a very important parameter. It counteracts the soft body’s motion and high values can even stop it completely. The range goes from 0.0 to infinity. A slight amount of “Air friction” should always be added.

Internal DampingA ductile body always shows a certain amount of internal motion, controlled by “Elasticity” and “Internal Damping”. With higher values a body loses its internal motion rather fast and stops “wobbling” after a short time. It will also experience smaller bounces. “Internal Damping” accepts settings between 0.0 and infinity: a value of 0.5 will stop the entire internal movement after 2 seconds, a value of 1, after 1 second, for example.

AutocollisionSince soft bodies can show a very high level of deformation, it’s very likely that some of its parts collide among each other. Without this option enabled, these areas would interpenetrate and lead to more or less fuzzy results – “Autocollision” helps to avoid this behaviour. Please note that “Autocollision” can take much longer to simulate, especially with higher “Resolution” settings.

PlasticityBy default, this option is set to “No”, but when enabled it unlocks four related parameters to control the node’s ability to become permanently deformed. “Plasticity” means that the deformations of the body will not relax or recover, and the object remains in a distorted state.

A ductile torus object with activated “Plasticity” reacts with rigid bodies.

@ thresholdThis value depends on a body’s change of its initial length to produce a permanent deformation. The range goes from 0.0 to 1.0. So, a value of 0.5 means that permanent deformation will only happen when the body’s length change is at least 50% of its initial size.

@ acquiredLike “@ threshold”, this parameter is also between 0.0 and 1.0, representing a percentage value. A setting of 0.5 will keep 50% of the node’s deformation as permanent. The other



Introduction | 158

half is able to relax and turn back to its initial state. Please keep in mind that these values are only approximations.

@ compression limitTo prevent a soft body from very high permanent compression, it’s recommended to specify a certain limit. Permanent means that the body rests in this compressed state and the deformation is not reversible. Without such a limit, objects might become totally flat and that’s not always wanted. The range lies between 0.0 and 1.0. For example, a value of 0.5 means that permanent deformations in one direction can compress the body approximately until the half of its original length in this direction.

@ expansion limitThis value works similar to “@ compression limit”, but is related to a body’s permanent expansion after its deformation. To parameter avoids unnatural changes in size. The range goes from 1.0 to 100.0. For example, a value of 2 means that permanent deformations in one direction can expand the body approximately until it has reached twice its original length in this direction.

@ VelocitySometimes you don’t want a simulation to start from zero, but the objects should have some initial velocity. With this parameter you can assign such a behaviour by simply entering positive or negative values. Please keep in mind that “@ Velocity” directly determines the body’s trajectory. A value of [ 2,0,0 ], for example, creates a linear motion along the positive X axis.

@ Rotation WThis parameter actually works the same way as @ Velocity. Instead of an initial velocity, you can add an initial rotation and it’s mostly used to avoid a uniform look. You also have three values and each one is measured in degrees. Negative angles are also accepted.

Hires objectIf you performed a simulation with a low resolution mesh, you can keep the results and transfer them to a high resolution object with this feature. To establish such a “projection”, you simply specify the desired node and everything will be carried out automatically. Of course, both objects should share the same shape and size to get reasonable results.

@ Update at frameWhen set to “Yes”, this option updates the soft bodies with each frame in the viewport.

h. The Realwave panel

This panel is only visible with a RealWave object existing in your scene. The RealWave window contains all relevant parameters for the interaction with wave surfaces. Objects can create waves during interaction and influence the surface and you can, for example, define height and velocity of these waves. They can also be made to float or sink – objects are even coupled to wave surfaces once they are below the RealWave mesh. To make objects interact with RealWaves, the appropriate dynamics feature must be enabled (otherwise they behave just like static obstacles):

Node Params > Node > Dynamics > [ object dynamics method ]

Under RealWave’s menu entries you can also find two particle emitters for object and crest splashes. These emitters generate standard fluid particles and their settings are located under the Fluid Particle Interaction panel. From the RealWave node’s own parameter set it’s also possible to activate the creation of foam-maps, but the object’s panel holds a special parameter to control its influence on foam-maps.

RealWaves are – like rigid bodies, soft bodies or particles – a very complex field and thus explained separately in detail, starting on page 201. Nevertheless, the settings from RealWaves and objects are coupled in many respects.



Introduction | 159

“Outward” the static points are created around the object. This could be useful for simulating a custom non-rectangular water surface, for example a pond or a puddle.

“Static points” are directly connected to some of the RealWave node’s properties: “Autogen static” (see page 206) constantly updates the static points, which is useful for moving objects. “Damping factor” (see page 206) must be set to values greater than 0.0 if you want the waves become reflected from the static points.

Coast distanceThis setting creates a circle shaped area with a gradient around the object. The gradient acts similar to a shore, where the water becomes more and more shallow with decreasing distance. Waves can refract within these zones and generate realistic surface structures. “Coast distance” can only be seen with activated flat shaded mode.

Texture strengthObjects can also contribute to foam-maps. To activate this feature, the RealWave mesh’s “Calculate texture” option (see page 206) must be set to “Yes” and “Texture strength” to a value greater than 0.0.

RealWave’s realtime texture view (Texture strength = 1.0).

Balanced massBy pressing this button, RealFlow automatically adjusts the correct mass of an object to make it swim or float. In this case you don’t have to deal with mass, volume and density.

Body typeYou can choose between “Closed” (default) and open. Closed types are actually all 3D objects, such as boats, spheres or characters. Open types are thin 2-dimensional items, for example tree leaves or sheets of paper.

Strength V/HThis setting controls the displacement of the waves caused by the interacting object in vertical and horizontal direction. It’s a very sensitive value and should be adjusted in small steps.

Interaction WaveBy default, an object is always connected to RealWave’s “Object interaction global” modifier (see page 208), keeping the basic interaction settings, such as “Max height” or “Wave speed”. If there are further “Object interaction modifiers” attached, you can select one of them for individual adjustments.

Water frictionLike any other “object” in real world, even water has a certain amount of friction, but it’s different from friction that can be observed between solids. Between solids, friction can be big when they aren’t sliding and drop somewhat when they start to slide. In a liquid, the faster something moves through the fluid, the more friction there is.

Perturbation res Each object can create waves when interacting with a RealWave surface. Mostly the amount of details and waves is controlled via “Strength V/H” and “Max height”. In some cases the amount of waves might still not be enough, even though the appropriate settings are already rather high. To achieve more waves, “Perturbation res” must be lowered, to reduce the distance between the perturbation points.

@ Perturbation noThis value cannot be edited and is calculated automatically by RealFlow, depending on the “Perturbation res” settings. Higher values may slow down the simulation.

Static points“Static points” are displayed as red vertices and indicate zones without any motion. This parameter provides three different modes: “No”, “Inward” and “Outward”. “No” doesn’t use any static points with this object. “Inward” is mostly used for obstacles like rocks. All objects meant to reflect waves should have set “Static points” set to “Inward”. With



Introduction | 160

i. The Display panel

The Display panel is not just a handy method to switch an object’s visibility on and off, it also provides some features to repair and visualize normals. This can become very important if you have to check inside or outside collision methods or fix errors.

VisibleUse this function to turn the object’s visibility on or off.

Show normalsYou can decide whether you want to see the surface normals or not. This is important when fluid-object or object-object interactions appear to be wrong or for the detection of corrupted polygons.

Show velocityAnimated and dynamically driven objects always have a certain linear and angular velocity, which can be displayed here. If the node is in rigid or soft body mode, this field shows the appropriate velocities for the item’s vertices. Please note that the illustration of velocity vectors can be fairly large.

Show CGWhen set to “Yes” you can see the node’s centre of gravity. In most cases you have to switch to the Viewport’s wireframe mode to see the centre of gravity.

Show PathYou can also specify whether you want to see the node’s animation path or not.

Normal sizeHere, you can determine the length of the normals shown in the viewport.

Normal typeYou can choose from “Face”, “Vertex” and “VtxFace”. “Face” displays the normals of polygons, “Vertex” for each point, and “VtxFace” shows both types simultaneously.

Normal facingFrom time to time it happens that objects are exported with flipped normals. This influences the behaviour in fluid-object and object-object interactions. To fix this problem without having to export the object(s) again, simply press this button and all normals are reversed.

Correct normals Flipped normals Textured mode

TextureWith this feature it’s possible to attach different textures for each object individually. You can choose from a variety of pre-built types by simply selecting one from the menu.



Introduction | 161

10.02 Null objectsNulls are very interesting and important nodes. They have versatile fields of application, though they don’t contribute to a scene, nor to direct interactions. But they can be used to control other nodes by parenting them. Another idea is to bound Nulls to control points of spline emitters and daemons. They can also be used with scripting: it’s possible to read out velocity, position or rotation data from animated Nulls and transfer them to other items, but it’s not possible to activate dynamics features for Nulls.

10.03 MultiBody objectsThis node is completely new in RealFlow 5 and gives you the possibility to group objects by simply importing them. The entire structure is then imported as a single object, though it can consist of hundreds of individual elements. This is especially useful for bodies containing many identical items in terms of rigid or soft body dynamics. Good examples are chains, walls or similar structures. But you’re not limited to similar or even identical elements; you can also combine any other geometry within a MultiBody. The only restriction is that it’s not possible to use MultiBodies with settings requiring an object selection, for example an object emitter. In this case, RealFlow expects you to choose an object node and you’re only allowed to select a node consisting of a single item.

MultiBody nodes can be turned into soft or rigid bodies and which are, of course, capable of interacting with fluids and RealWaves. Daemons, capable of influencing dynamic nodes, can also act on MultiBodies without limitations. MultiBodies can even be used with RealFlow 5's MultiJoints to connect the individual parts, but there's one restriction: it’s not possible to adjust individual parameters for the grouped objects, because all included items are treated equally. The different masses of a MultiBody's elements are controlled with a "Density" value. Nevertheless, this type is a very nice time-saving feature, especially for large setups.

The loading time of MultiBodies, compared to SD files with many objects, is significantly shorter. MultiBodies share most of the settings with their standard counterparts and there are only few differences. Anyway, you’ll find explanations for the most important parameters here.

a. The Texture panel

It’s not possible to create wet-dry maps with multibodies, but you can add a bitmap to the node to texture it. The texture will be visible from the moment you’ve attached it and there’s no need to activate the Viewport’s texture mode.

Load textureYou can load any supported bitmap here. The images below show a MultiBody in original and shattered states.

b. The Rigid Body panel

Except from “@ mass” all parameters are exactly the same as with standard object nodes. Another difference is that a MultiBody’s “Primitive” type is always set to “Mesh” by default and “Collision Side” is “Outside”. Of course, you can change these initial settings according to your needs.



Introduction | 162

@ densitySince MultiBodies can consist of a lager number of objects, it would be a major limitation to use the same mass value for all items. With a density-based approach it’s possible to overcome this restriction, because now small parts will also have low mass.

c. The soft Body panel

MultiBodies can also act as soft bodies. The parameters are almost identical except of a few differences: the “Mass” parameter is replaced by “Density”, it’s not possible to use “Hires object” and the “@ Update at frame” is not available.

DensitySince MultiBodies can consist of a lager number of objects, it would be a major limitation to use the same mass value for all items. With a density-based approach it’s possible to overcome this restriction, because now small parts will also have low mass.

d. The Display panel

Again, most of the settings are exactly the same as with standard objects and the only difference is the “Show positions” switch instead of “Show path”.

Show positionsThe position of each individual part of the MultiBody is indicated by a cross. Please note that these positions are not necessarily equal to their centres of gravity. In many cases it’s necessary to activate the Viewport’s “Wireframe”or “Bounding Box” shading mode to see the crosses.

10.04 plug-insPlug-ins are external modules to enhance the functional spectrum of a software. RealFlow now gives you the possibility to either create your own plug-ins or purchase them from 3rd party companies or vendors – if available. To write your own plug-ins you will need to be proficient in a programming language – preferably C++. The Software Development Kit (SDK) provides the interfaces and data structures for most of RealFlow’s functions. These functions help you to directly access certain parts of the software and modify them to your needs. If you already have experience with RealFlow’s Python scripting interface, then you will quickly become familiar with the C++ SDK. Once you have installed a plug-in, it appears in a list and you can use it like any other object.

10.05 ImportAs well as using the shortcut (Ctrl + I for Windows and Linux, Cmd + I for OS X) or the appropriate menu function for adding objects from other sources, you can also go to the Icon Bar and choose the Import command. Nodes can be loaded in different formats, but there are few things to bear in mind: the most common and reliable format is RealFlow’s native SD file type. Please note that there can only be one SD file per project and it’s not possible to selectively delete nodes from an imported SD-based scene. If you want to remove individual objects, it’s necessary to go back to your 3D software, delete the object and export everything again. Another way is to make the considered node inactive:

Selected node > Node Params > Node > Simulation > Inactive

Other supported file formats are: LWO (Lightwave), ASC (ASCII objects), OBJ (Maya), XML (Allplan), DXF and MXS (Maxwell Render). These formats can be mixed with SD files without limits.

10.06 MultiJointsMultiJoints are actually not a type of object. This is a completely new method to connect nodes, designed to substitute RealFlow 4’s constraints. With Joints it’s possible to connect



Introduction | 163

selected objects and define certain forces to make them either stick together or break apart. A MultiJoint node is added like any other object:

Menu Bar > Add > Objects > MultiJoint

Viewport > Right-click menu > Add > Objects > MultiJoint

or from the Icon Bar by choosing the appropriate symbol. A MultiJoint node has no viewport representation, since it’s not an object in a physical sense. MultiJoints are a rather complex concept and offer a wide variety of settings. Therefore they’re treated and explained separately in the following chapter.

u MultiJoints can only be used in combination with rigid or soft bodies.



Introduction | 164

11 RealFloW MUlTIJoINTs

With MultiJoints you now have a modern and sophisticated way of connecting objects. MultiJoints are actually a group of individual Joints, with the same specifications. They have been created to replace the former constraints, available in RealFlow 4. Joints are much more flexible, robust and better in many ways, though the most striking feature is that they can be created automatically – just by detecting if objects are close enough. Other advantages are controllable forces, enhanced collision detection, plastic deformation and the ability to use them with rigid and soft bodies. It’s even possible to join rigid and soft bodies. RealFlow’s Joints have incredible possibilities. They can behave in many different ways without restricting the user to a limited number of predefined modes, like hinges, ropes or sliders. It would make no sense, for example, to connect standard hinges with soft bodies.

MultiJoints can be seen as a secondary simulation system for dynamic objects. Of course, rigid and soft bodies can interact without any connections or bindings, but Joints have no influence on non-dynamic objects. That’s actually the only requirement, because it makes

no sense to apply Joints on emitters or RealWave surfaces. Joints are a perfect addition on the new object dynamics solvers, helping you to create much more realistic simulations. It’s also no problem to add more than one MultiJoint node to establish various kinds of interactions and connections. With this easy method you can define different specifications for different links, e.g. break forces or distances.

Since MultiJoints are completely different from previous methods of connecting bodies, it’s important to give you a detailed overview, helping you to understand how they work. With Hybrido, the new grid fluid solver, experienced users will have no problems running their first simulations, because there are many familiar parameters, but the concepts behind Joints are absolutely new and there’s nothing comparable.

11.01 MultiJoint settingsAdding a MultiJoint node is as easy as creating any other node. You can find it under the Icon Bar’s object menu

or call it from

Menu Bar > Add > Objects > MultiJoint

Viewport > Right-click menu > Add > Objects > MultiJoint

The new node is only added to the Nodes windows, but there’s no default viewport representation and it doesn’t appear under Global Links. Joints can only be seen when they’re used with different objects. They are shown as little crosses. Please remember that a MultiJoint item is not an object in a physical sense; it’s a just a way to connect different nodes and then control these links. Unlike many other node types, there are no common settings and even the Node panel lacks many well-known parameters.



Introduction | 165

a. The Node panel

This menu consists of just two entries. Since a MultiJoint has no dimensions, it doesn’t carry any settings for changing its size or orientation in space. You can see the Joints from the moment they have been created.

SimulationBy default, a MultiJoint contributes to a simulation, so this parameter is set to “Yes”. In many cases it’s necessary to simulate a scene without the influence of certain nodes – in this case choose “No”. “Cache” is used to start a new simulation, based on previously recorded (=cached) data.

ColorEach RealFlow node can have its own RGB colour. Choose your favourite colour here to colour the connectors.

b. The creation panel

This is the place where you specify the objects to be linked. It provides several ways and methods to establish a joint connection between different nodes, but please make sure that either “Rigid body” or “Soft body” is activated from the Node’s “Dynamics” option.

Objects AHere you can specify the first group of objects you want to connect to a second group, found under “Objects B”. Once both groups are defined, RealFlow establishes Joints between them, based on the settings of the available parameters. When you click on

“Objects A”, a node picker is opened, showing you all suitable objects. Of course, multi-selection is allowed, but you should always keep track of which objects you want to include in “Objects A”, and which in “Objects B”. It’s therefore a good idea to apply 2 groups under Nodes and split the object pool.

Objects BThis is the second group of objects you have to choose to create the desired links. The method used is exactly the same as with “Objects A”, withone difference: it’s possible to leave “Objects B” empty. If you do so, nodes from “Objects A” will be linked with RealFlow’s world space. Another speciality is to attach exactly the same nodes to “Objects A” and “Objects B”. This selection creates connections between all selected items. A good example is a brick wall.

u The node pickers, available with “Objects A” and “Objects B”, only show nodes with active dynamics settings. So, if your node selection list is empty, please check that “Dynamics” in the Node panel is set to either “Rigid body” or “Soft body”.



Introduction | 166

Creation ModeThis is a very important feature, because you can determine whether the creation process of Joints is fully automatic, or whether you want to see links at certain positions. You can choose from 5 different modes:

“By contact” is the most convenient method. It's an automatic mode to create Joints between the nodes from "Objects A" and "Objects B". The quantity and position of the Joints generated depends on 4 parameters which are only available with "By contact". Your only task is to distribute the objects as you want, and adjust the values – RealFlow will take care of the rest. By changing the nodes' positions and the associated "By contact" values you indirectly specify where the Joints will be created.

Two bodies, connected with “By contact”

“By stem (leaves A, trees B)” is a very interesting mode. The name is pretty self-explanatory and already gives you an idea of what this mode can be used for. With this mode, RealFlow creates trios of points which are randomly orientated, but perpendicular to the leaves' axis. These trios of points are then used to place the Joints linking the leaf objects with the tree nodes. Typical applications for “By stem” are the spines of a hedgehog or porcupine, branches of a tree and, of course, leaves connected to a branch. “Objects A” will contain the leaves, “Objects B” the base objects. The "By stem" mode isn't symmetrical and it's important to put the leaves into "Objects A" and the tree nodes into "Objects B". If you don't follow this rule, the Joints can appear at unwanted positions and the leaves could end up looking

twisted. Another requirement is that the leaves have to be relatively close to the trees.

Joints, created with the “By stem (leaves A, trees B)” method. The white triangle indicates the connections.

“At locators positions” was introduced to overcome the restriction in “By contact” that you cannot directly determine where the Joints will be added. With this option you’re now able to create Joints at a certain position, given by one or more helper objects. RealFlow uses the pivot points of these helper objects to establish the connections. To label a node as a locator, it’s necessary to add it to the “@ Locators” list, which becomes unlocked by activating “At locators positions”. An example is the construction of a door hinge.

Bodies, connected with “At locators positions”. The locators are dashed and transparent.



Introduction | 167

u Any polygonal object can serve as a locator; it’s not necessary to activate the object’s dynamics features.

Another option is called “At locators bbox centers”. This mode uses the geometrical centre of a (virtual) bounding box around the selected locator(s) to create the Joints.

The last mode is called “At locators vertices” and works in a similar way to the previous methods, but here RealFlow doesn’t use the pivot point or the centre of the bounding box – everything’s based on vertices. This also means that you’ll get a higher number of Joints, depending on the number of vertices. The objects you want to use with this function also have to be added to “@ Locators”. It’s unlocked automatically when you activate this option. The construction of a wheel, where the tyre is connected to the mesh of a metal wheel, would be a perfect application.

Bodies, connected with “At locators vertices”. The locators are again dashed and transparent.

With “At locators positions”, “At locators bbox centers” and “At locators vertices” every single Joint you create connects the two nearest objects – one from “Objects A” and one from “Objects B”. They’ll be linked, even if they are far away from the Joint. There is no distance limit.

@ Contact distance searchThis feature works only with “Creation Mode” set to “By contact”. There’s always a certain distance between the nodes from “Objects A” and “Objects B” – even if they’re touching.

In such a case, distance would be zero. With this parameter you can define the distance at which RealFlow should look for objects to connect. By increasing this value you can look for pairs which are further away. If you want to keep the default value of 0.002 you have to bring the nodes very close together, which would be the perfect occasion for using one of RealFlow’s new snapping tools:

Menu Bar > Edit > Snap > Bounding box > Nearest side

This function calculates the closest possible distance between two selected nodes, and in the best case the objects will touch. It also recognizes the order of your node selection: the first item is always the one that’s repositioned to be brought into contact with the other body.

Connected bodies with a large “@ Contact distance search” value.

@ Contact area min.You can only change this parameter with "Creation Mode" set to "By contact". To establish Joints, the contact area between the faces of two objects must be greater than this value. When object faces are nearly anti-parallel (i.e. parallel and confronted), the concept of contact area is obvious: it's the area of the contact surface you obtain if you put together the two bodies, touching at those anti-parallel faces. If object faces are not anti-parallel, the concept becomes a bit more complicated: it could be seen as the area of the intersecting surface you'll get when moving one of the objects towards the other over a certain distance which can be specified with "@ Contact distance search".



Introduction | 168

@ Contact angle max.Another parameter that’s only available with “By contact”. Joints will only be created when the angles between nodes' faces are smaller than this value. It's possible to enter values close to 0 - in that case, Joints are only established between faces which are almost anti-parallel. If you use high values for the angle, you can create Joints between surfaces which are confronted, but far from being anti-parallel.

When you increase the value of the contact angle, Joints can be created between non-anti-parallel surfaces.

@ Contact number max.Again, this option is only available with the "By contact" mode. Since "By contact" mode generates the Joints automatically, you cannot control how many of them are created. However, with this parameter you can limit the number of connections. RealFlow selects the most significant Joints.

@ LocatorsSimilar to “Objects A” and “Objects B”, this field is a node list which is only available when “Creation Mode” is set to locator mode. You can open a node picker and choose the objects serving as locators. RealFlow uses their pivot points, the centre of their bounding boxes or their vertices to create Joints between the different nodes. Objects, used as locators, don’t need dynamic features activated (“Dynamics” = “No”).

Limit processed jointsSometimes a large number of Joints is created between two bodies. This situation can occur when you use high-resolution meshes or when one body of the pair is a soft body (links between or with soft bodies always require a large number of Joints, because soft

bodies can deform). By default, all these connections will be processed during simulation, leading to very long simulation times.

To avoid this problem, you can activate “Limit processed joints”, because this option restricts the number of Joints that are actually processed at same time during simulation. This doesn’t mean that RealFlow creates less connections; rather, they will be treated differently during simulation (e.g. if you decide to use “Limit processed joints” and click on “Create/Update”, you’ll see the same amount of Joints as if this parameter was set to “No”). RealFlow can literally choose from the entire set of Joints the ones which are best suited for each calculation during a simulation.

@ Max processed joints per pairThe number you enter here is the maximum number of Joints the solver will process at the same time. Joints to be actually processed during internal calculations are turnsselected from among all the Joints. For this reason, it is easy to achieve results similar to those obtained by processing all the Joints at the same time, but with a significant saving in time. It all depends on the value you select for this parameter.

An example:Imagine a bone linked to its surrounding flesh. The bone’s vertices are used to create the Joints, let’s say 1,000 and “Max processed joints per pair” is set to 50. During calculation all of them will be processed, but only 50 at once.

Disable collisions by pairsYou have two options: “Yes” and “No”, the default selection. When you set “Disable collision by pairs” to “Yes”, the solver stops processing collisions between all body pairs connected by Joints.

Disable all collisions A-BThis is another selective mode and is based on the nodes in “Objects A” and “Objects B”. The difference to “Disable by pairs” is that objects from the aforementioned lists don’t necessarily have to be joined, e.g. because the distances between them are too big. So, you can disable collisions between pieces when you already know that they won’t interact (or don’t want them to interact). The result is a significant increase in simulation speed.

A good application for this function would be a pre-fractured object where you don’t need collision between the individual pieces until it begins to break apart. With this function set to “Yes”, the simulation will be much faster.



Introduction | 169

Create/UpdateWhenever you’ve changed a value from the Creation panel, you'll need to confirm these settings and feed the Joints solver with the new data. RealFlow will then create updated connections, based on your input. For the very first creation process, this button has to be used as well.

u The creation of Joints far away from objects is an exclusive feature of rigid bodies. The properties of soft bodies don't allow such a creation mode. If the Joints, created for the soft body, are too far away from it, you will see the Joints, but they will be ignored. In such a case you have to create the Joints closer to the soft body.

c. The Forces panel

With rigid and soft bodies, forces are the key to everything. They cause accelerations, deformations and changes of direction. MultiJoints are the same – forces are used to influence the links between interacting objects. These forces also affect the way a body behaves and moves, so they have an immediate impact on dynamic simulations.

Joints can be seen as an invisible rubber band between bodies. Forces are used to determine the bands’ rigidity. This is something that’s also displayed in the viewport during simulation. Under certain conditions, connected objects start separating from each other, and you can see the changing Joints as lines made up of dashes with variable length. Higher forces give you more rigidity and the bodies can even glue together completely.

@ Max force = 15,000 @ Max force = 20,000 @ Max force = 30,000

Force max modeThis parameter determines the appropriate mode for how forces should act on Joints. There are three options available. With“Unlimited”, forces are treated is infinite. This behaviour leads to a situation where touching objects cannot become separated, no matter what happens. Connected nodes behave like a single object. The question is surely why it’s necessary to glue objects together, instead of using a single body? The basic idea is simply to connect things you don’t want to become separated, like the already-mentioned wheel, or soft feathers attached to the rigid part of an arrow. The great advantage with “Force max mode” is that you are not restricted to a certain mode, once it’s been established. It’s possible to switch over to other modes, using certain force limits, at any time. If you want to control the forces acting between connected nodes, choose “Constant limit”. It also unlocks two settings: “@ Max force” and “@ Max force random”.

Distances and forces play an important role for simulations with Joints; therefore it’s important to use the appropriate method. With “Depending on distance” you can unlock a series of parameters for ruling a distance-based force distribution. The decisive parameter is the current space between two points linked by an individual Joint, which is tested with each simulation cycle. The force that’s needed to separate two points linked by a Joint depends on this particular distance.



Introduction | 170

@ Max forceAs already mentioned in the introduction to Forces, Joints can be compared to rubber bands between bodies. “@ Max force” controls this connection. “@ Max Force” tells RealFlow which force is needed to separate the objects and they’re pulled back from the moment they come to rest when the external force is smaller than “@ Max Force”.

With higher settings you can increase the Joint’s tendency to contract, so the objects are pulled back faster. Small values make them behave like a worn out rubber band; in these cases the objects can’t be pulled back, because the body’s weight force exceeds “@ Max force”. Estimating “@ Max force” isn’t always easy, because it doesn’t just depend on gravity and mass, but also on the size of the contact areas between linked objects.

As a rule of thumb, one could say: “If the contact area between “Objects A” and “Objects B” becomes larger, higher forces are needed to separate them.” To get a feeling for forces, the best idea is to play with this value and check the occurring forces under "Statistics".

@ Distance step (D)This parameter is only available with "Force max mode" set to "Depending on distance". When forces aren’t strong enough to keep the linked points together, they start separating. The distance between them is measured with each simulation cycle, because it’s variable. With “Depending on distance” selected, the maximum force that can be exerted by a joint to keep together the two points it links will depend on the distance between them at each moment.

The function, describing the force limit, is defined as a piecewise linear function, based on 6 separate sections with a length given under “@ Distance step (D)”. The force limits are determined using the appropriate entries from “@ Max force at 0D - 5D”. Please have a look at the image below. If the distance between two points exceeds 5D, the force limit will maintain the related “@ Max force at 5D” value.

You can also create an interesting effect: if you don’t want to have any forces at all until a certain distance “d” is reached – just try this setup:

@ Distance step (D) = d (the target distance)

@ Max force at 0D = 0 and

@ Max force at 1D = 0

@ Max force at 0D – 5DThese parameters are only available with "Force max mode" set to "Depending on distance". As already stated, force limits can be described as a piecewise linear function, so it’s possible, for example, to define a decreasing range of forces with growing distance.

Example of a force distribution, depending on the distance between 2 joined points

@ Max force randomTo give a simulation a more realistic appearance, it’s often a good idea to randomize things a little. “@ Max force random” was introduced for exactly this purpose. The added variation ranges between 0 and the entered value. So, if this parameter is different from 0, you have to take it into consideration while adjusting “@ Max force”.

d. The collisions panel

Collisions between rigid and soft bodies can be turned on or off selectively, e.g. with global and exclusive, but Joints provide an additional method. To give you total control over interacting objects, this panel provides several modes for various occasions and setups. It’s actually really important to make up your mind about collisions, because this feature



Introduction | 171

strongly affects simulation speed and your final results. Without collision detection, bodies will interpenetrate, which is normally only useful for certain effects. The options from this panel only affect joined nodes, but not their interaction with other rigid or soft bodies without Joints. In other words: even if you have disabled collision for connected objects, they’re still able to collide with “regular” items, e.g. joined bricks falling onto a ground.

Enable if breakUnder certain circumstances, a connection can break leaving two separated or hinged bodies behind. RealFlow’s standard setting is “No”, but there’s one thing to consider: if collisions were enabled at the moment of creation, they’ll remain active, regardless of whether the Joints are broken or not.

In case "Enable if break" is set to "No", the linked nodes can interpenetrate. To achieve a more realistic scenario, it’s advisable to set “Enable if break” to “Yes. When this mode is active and any Joint, linking a body from “Objects A” with a body from “Objects B”, is broken, you can achieve the following combinations:

• If “Disable by pairs” is active, it enables only collisions between the A-body and the B-body.

• If “Disable all collisions A-B” is active, it enables collisions of the A-body with all nodes from “Objects B” and collisions of the B-body with all items, listed under “Objects A”.

• If neither of the previous modes is active, the action is the same as with “Disable all collisions A-B”.

Enable if distance exceededThe mode of operation is the same as with “Enable if break”, but isn’t based on breaking Joints, but on a certain distance between two linked points of a Joint. Again, you can choose between “Yes” and “No”.

@ Enabling distanceIf “Enable if distance exceeded” is active, this parameter becomes accessible. If the distance is greater than the given value, collisions can take place.

@ Enabling distance randomSimilar to “@ Max force random”, this parameter adds a random number to “@ Enabling distance” to create a more natural look. The value is calculated between 0 and the number entered here.

e. The Break panel

From the moment a link is broken, the connection stops working and you cannot observe the typical pull-back behaviour. With "Break" parameters you can define rules and criteria for breaking Joints under certain conditions. These settings give you extra realism, especially with any form of collapsing structure, but also in situations where the connections act like ropes or hinges which are broken due to high forces.



Introduction | 172

Break if max force reachedAs you may remember, “@ Max force” defines the rigidity of a connection between two bodies. Low values create less restricted motion and pull-back forces are not that strong. When this given “@ Max force” value is reached, the Joint breaks – but only if this mode is active.

Break all in pair if few unbrokenThis is an interesting feature, because it reacts to the number of broken connections. It is best explained with a simple example: two cubes are linked via 5 connections – 4 at the cube’s vertices and one in the geometric centre of the polygons. Now imagine that 3 of these connections are already broken, but the remaining 2 are strong enough to keep everything together.

n a case like this, the Joint would act like a hinge and the bodies would be loosely connected. With “Break all if few unbroken” set to “Yes” and “@ Unbroken number to break all” set to 2, RealFlow would break the remaining links and the objects would be completely separated. To give another illustration: imagine a brick wall being destroyed by a hitting object. Some bricks might stick together, because not all Joints are broken and so the nodes are hinged. To avoid such a behaviour, just define a certain limit with “@Unbroken number to break all”, e.g. 2, to dissolve all connections.

This feature has two settings: “Yes” to enable it and “No” to deactivate it. It’s also important to know that it can be used with any break mode.

Unbroken torus nodes stick together, broken ones are separeted.

@ Unbroken number to break allBy default this parameter is locked and only accessible when “Break all in pair if few unbroken” is set to “Yes”. If this value is reached by a particular pair of joined bodies, all remaining connections between them will be broken. Other links in the MultiJoint won’t be affected. You can find an example under “Break all in pair if few unbroken”.

Break if distance is exceededAgain you can choose between “Yes” and “No” to activate/deactivate this function. Like many other similar parameters, this one also depends on the distance between points, linked by an individual Joint. A very important factor with distance is “@ Max force”, because it directly affects how far bodies can separate from each other before they’re pulled back. By activating “Break if distance is exceeded”, you’ll unlock the parameter below where you can enter the desired distance value. If “Force max mode” is set to “Unlimited’” this feature is not available, because the linked points cannot separate so it makes no sense to talk about distance.

@ Break distanceIf the given distance is exceeded, the connection is broken. “@ Break distance” is measured in RealFlow units, related to the viewport’s grid.

@ Break distance randomHere it’s possible to add a random number to the previously defined “@ Break distance” parameter. The final value is calculated between 0 and the entered setting.

f. The plasticity panel

Plasticity is normally a feature of soft bodies, but it’s also available with Joints. “Plasticity” means that deformations are irreversible and the vertices’ displacement is final. Reversible deformations can be observed with rubber balls, foamed materials or jelly-like substances, to name but a few. Irreversible transformations can be observed with metals, styrofoam or clay, for example. Here, plasticity means that the separation of points, linked by Joints, becomes permanent under certain conditions. Since a certain amount of separation is essential for plasticity effects, this mode is only available if “Force max mode” is not set to “Unlimited”. The result is a very realistic behaviour in situations where you want to create cracking effects, for example a breaking dam.

u It’s currently not possible to use plasticity effects with “Limit processed joints”.



Introduction | 173

PlasticityTo enable permanent dislocation of points, switch to “Yes”. The effect of “Plasticity” is exactly the same as described in the previous introduction. The image below shows a simulation of a breaking wall made of two layers and two MultiJoint nodes. The white layer has been simulated without activated "Plasticity" and the fragments collapsed without deformation. The orange layer uses "Plasticity" and shows a strong non-reversible deformation. Some fragments stick together as if they were connected with a kind of underlying "tissue" or "grid", but other parts can still leave the assembly. Here some Joints are broken.

@ Plasticity distanceWhen the entered distance is reached, the connection between Joints becomes irreversible, behaving like an overstretched rubber band.

@ Plasticity distance randomTo give your simulation a more realistic appearance, we recommend that you add a certain amount of randomness. The value that’s added to “@ Plasticity distance” ranges between 0 and the number entered here.

@ Plasticity aquiredThis parameter has the same meaning as "@acquired" with soft bodies (see page 157). It's the percentage of deformation kept as permanent by the joint. This means that the joint won't try to recover its initial situation any more. So, with a value of 0.2, 20% of the currently observed joint's deformation will be permanent. Thus, the value can range between 0 and 1.

u In both cases (soft bodies and MultiJoints) "acquistion" means a percentage of the deformation suffered at each time step (changing the physical situation at each time step). This can lead to high acquisition of deformation with relatively low values. You have to play a little with the "@ threshold" (sodt bodies), "@ Plasticity distance" (MutliJoints) and the acquired percentage to obtain the desired results.

g. The statistics panel

This panel has been added to give you an idea of the current state of your MultiJoint simulation. All relevant parameters are listed here. The force-related values are of particular interest, because they'll help you to adjust an appropriate "@ Max force" value for your simulation.

@ Joints numberThis is the total number of individual Joints, a MultiJoint consists of.

@ ProcessedHere you can see the number of Joints which are currently processed at the same time during calculation. If this value is very high and your simulation is slow, you should consider using "Limit processed joints" under the Creation panel.



Introduction | 174

@ Joint groups numberWithin a MultiJoint there are groups of Joints connecting particular body pairs. From here on, we will refer to such a group as a Joint Group. This value indicates the total number of Joint Groups inside the MultiJoint. In other words: this is the number of linked body pairs.

@ ActiveIf a MultiJoint itself is inactive, then none of its Joint Groups are active. When you delete a body or change its dynamics mode then all Joint Groups associated to this body will be set to inactive. "@ Active" indicates the number of currently active Joint Groups.

@ BrokenSometimes all Joints linking a particular body pair are broken. This means that the corresponding Joint Group is broken as well. This value tells you how many Joint Groups are currently broken.

@ Partially brokenAnother possibility is that only some Joints of a body pair are broken. In such a case, the

corresponding Joint Group is only partially broken. Here you can see how many groups are currently partially broken.

@ Plastically deformedIf "Plasticity" is enabled, this value indicates how many Joint Groups are really experiencing this certain type of deformation.

@ With collision pair enabledCollisions between all body pairs are not always processed. You can choose to exclude the collisions between certain bodies or even disable them when creating a MultiJoint. The parameter shows you the number of Joint Groups whose corresponding body pairs are allowed to collide.

@ Max force being usedHere you can see the maximum force that has been exerted by an individual Joint in the MultiJoint during the last calculation.

@ Max force used since creationThis value indicates the maximum force an individual Joint has experienced since the beginning of the simulation.

u For "@ Max force being used" and "@ Max force used since creation" there's an important addition: this information can be used as an orientation to determine the values for "@ Max force", "@ Max force at 0D-5D" or "@ Max force random". This, of course, requires that "Constant limit" or "Depending on distance" are enabled under "Force max mode".

h. The Display panel

Each RealFlow node has its own Display settings and Joints are no exception. Since Joints aren’t physical objects, consisting of polygons or grid cells, the possibilities are limited and only concern the illustration of the connectors.

VisibleA connection between two points is indicated by a little cross, similar to a Null node. These crosses directly represent the Joints’ positions. When the bodies are separated, you can also see lines of dashes between the linked points. "No" disables this representation.



Introduction | 175

Multiple coloursBy default, Joints have a uniform colour, defined under the Node panel. If you’d like to see everything more vividly, activate this function and the connectors will be shown in different colours. Colours play an important role with MultiJoints and even if this feature is set to "No", you can differentiate between these states by colour:

Colour State

Green Normal state

Red Broken

Orange Breaking in progress

Yellow Plasticity state

11.02 collpasing Dominos (Tutorial)RealFlow 5's new rigid and soft body solver “Caronte” is a production-ready tool with endless possibilities. Dynamic bodies can interact with all of RealFlow's solvers, including Hybrido's grid fluids. Another extension is the sophisticated MultiJoint system (see page 164). MultiJoints create links – based on distances and contact angles – which can act like constraints. Other advanced features with MultiJoints are plasticity effects and full force-control for stunningly realistic dynamics simulations. To speed up the creation of rigid and soft body dynamics projects, a new object type has also been introduced: MultiBodies (see

page 161). With this versatile helper it's possible to group thousands of individual items into a single node and you can use load more than one MultiBody object to overcome RealFlow's “one-SD-per-scene” limit. With MultiBodies you don't have to deal with long lists of nodes or groups. MultiBodies can also react on particles, daemons and they can be connected with MultiJoints. When you load a MultiBody object into your scene, you'll also notice significantly faster processing and displaying.

a. preparing The simulation

This tutorial gives you an introduction in how to make use of all these new possibilities and how to combine them. The project consists of a row of pre-fractured domino-like blocks being hit by a “bullet”.

The individual chunks are connected with a MultiJoint node. The bullet is just a simple sphere with some initial velocity which adds force to the system, making the dominos collapse and break into pieces. Of course, the fragments are merged into a MultiBody node. Importing the fragments is the first action. To add them, please go to:

Nodes Bar > Objects > MultiBody

Once you've added the node to the scene, a file picker will open, asking you for the appropriate SD file you've exported from a 3D program previously. After a few seconds (depending on the file size and number of fragments), the objects will appear in the viewport. Though you can see lots of individual items there, the Nodes panel shows just a single entry: "MultiBody01". You can treat this object like any other node: activate its dynamics features, make it exclusive to other nodes or adjust particle interaction settings.



Introduction | 176

To complete the scene, you can now add a few more nodes: a gravity daemon, a sphere, a cube (acting as a floor) and a MultiJoint object. While the gravity daemon will keep its default settings, the other items have to be adjusted. The floor is a simple rigid body without movement:

Cube01 > Node > Dynamics > Rigid body

Cube01 > Node > Rigid body > Dyn motion > No

The bullet (Sphere01) has to be downscaled, because it should only trigger the dynamic collapse of the dominos and not entirely destroy them, so a scale of 0.2 x 0.2 x 0.2 is fine. Since it will interact with any other node, the sphere's dynamics features must be enabled. This workflow is the same as above, but “Dyn motion” must remain active. Mass shouldn't be too high and there must be an initial velocity. The direction of this velocity depends on the orientation of the dominos. In this scene, the bullet will move along the positive X axis. Of course you can experiment with different values for “@ mass” and “@ Velocity” to see how the simulation will change when you alter these parameters. These are the settings:

Sphere01 > Node > Rigid body > @ mass > 450

Sphere01 > Node > Rigid body > @ Velocity > X > 6.0

The MultiBody node also requires some adjustments. it has the same properties as any other RealFlow node, and the switch for activating rigid body dynamics can also be found under its Node panel. With mass it's a little bit different, because you won't find such a parameter. The reason is that it's not possible to control the individual “@ mass” settings for each element. Therefore, “@ density” will be used. Since density is defined as mass per volume, the mass for each chunk can be calculated from a given density.

“@ density” shouldn't be too small, because the dominos consist of many items, and light-weighted bodies might perform unwanted movements or become highly accelerated. In this scene, the value is 11000, but in your own project you'll most likely use a completely different setting. These values depend on many things, for example scene scale and the size of the imported objects. If “Dyn motion” is set to “No”, activate it to make the chunks moveable.

The last settings concern the physical behaviour: the fragments should bounce a little when they hit the floor, so an “@ elasticity” value of 0.5 will be used. “@ Object friction”

shouldn't be too high, because the individual elements are very close together, so this might lead to wedged objects. In such a case, there can be rather high tensions and when the affected MultiJoint links break, the objects are sometimes highly accelerated. A value between 0.4 and 0.5 should be fine. To add more friction, it's also possible to increase the floor's corresponding parameter to something around 0.6 or 0.7.

The "Rigid body" settings for the MultiBody node.

b. adjusting MultiJoints

Finally, the MultiJoint node has to be adjusted. To find out the correct settings, it's a good idea to make up our mind about what you want to achieve. In this project, the first domino should break after being hit by the bullet. The chunks will then be tossed against the following blocks, which should lead to a chain reaction breaking the dominos break apart one after the other. To establish the connections between the MultiBody elements, you will need to choose “Objects A” and “Objects B”. With this scene it's easy, because both fields must contain “MultiBody01”:

MultiJoint01 > Node Params > Creation > Objects A/Objects B > MultiBody01

If you cannot see the MultiBody node in the file picker, please check if its rigid body dynamics option is active. Click on “Create/Update” and the joints will be drawn in the viewport as little crosses. If you want to make them invisible, please go to:

MultiJoint01 > Node Params > Display > Visible > No

All the other parameters will remain untouched, because they completely satisfy our requirements here. Under “Forces” you can see that “Force max mode” is set to



Introduction | 177

“Unlimited”, which will prevent the chunks from completely breaking apart. To activate a breaking mode, the parameter has to be “Constant limit”. The main task is now to find a working “@ Max force” value. To get an idea of how this setting works, it's a good idea to start a simulation with the default values, but before that the remaining adjustments have to be finished:

MultiJoint01 > Node Params > Collision > Enable if break > Yes

MultiJoint01 > Node Params > Break if max force reached > Yes

Finally, simulation quality has to be determined. The default setting is “Low” which is enough to evaluate the scene. The final simulation, though, will be made with “Medium”. To change this level, please go to the Simulation button and click on the little triangle next to it to open “Simulation options”. There you can find the following setting:

Rigid/Soft body solver > Quality > Medium

u Rigid and soft body simulations are independent from "MIN substeps" and "MAX substeps". They are only controlled by the adjusted "Quality" level.

Now it's time to perform a first test and after a few frames it's obvious that “@ Max force” has to be increased. It takes a few simulation cycles to find out the working settings, because they don't only depend on the physical properties of the objects, but also on your personal taste. Forces can easily become really large and initial values between 100,000 and 1,000,000 are often a good start. Based on these values you can adjust “@ Max force” to your needs. A good idea is to start with rather high settings first and then gradually decrease the value, for example:

10,000,000 > 5,000,000 > 1,000,000

With such a gradient it's possible to quickly find out from which point the dominos will start breaking apart. The rest is fine-tuning, which is always the case with physical simulations of natural phenomena. It simply takes some time to find out the settings to make the objects (or particles) behave the way you want them to. In this scene, “@ Max force” is 525,000 and “@ Max force random” is 250,000. The final result is very appealing and shows a realistic behaviour. Three images from the complete sequence can be seen on the right.



Introduction | 178

12 RealFloW MesHes

Meshes are one of the core concepts of RealFlow – regardless of whether you’re dealing with grid fluids, particle fluids or RealWave particle layers. The first question surely is: “What is a mesh?”. In RealFlow a mesh is a three dimensional representation of the outmost particles of one or more emitters. The mesh engine puts a sort of skin over these particles to visualize the fluid’s volume. This polygon mesh can then be treated like any other object inside your 3D object. You can apply shaders and textures, even with UV coordinates, combine it with motion blurred particles, and render everything to create a convincing fluid.

Close view of a RealFlow standard mesh with visible polygons.

One of the most important criteria for a good mesh is the number of particles. This parameter is responsible for the quality of a fluid and also for the final mesh. The better the particle simulation, the better the final mesh. But even with smaller particle amounts it’s possible to create a convincing mesh. The secret is to find the correct settings and

that’s, of course, not always easy. Meshing always needs a certain amount of testing to find out the working parameters and to avoid an unwanted “blobby” look with thick and round edges. Another common misunderstanding is the belief that the number of polygons (“Polygon size”) automatically improves the quality of a mesh.

Mesh creation, respectively mesh adjustment is subdivided into a few steps:

1. Mesh settings. These are the parameters for the polygon hull, e.g. “Polygon size”, filtering and so on. All these settings directly affect the mesh’s polygons.

2. Field settings. With these parameters it’s possible to control the influence between the particles and they’re directly related to the used emitters, not to the mesh container. These settings are not available for grid fluid meshes.

3. Testing and meshing. Testing is, as already mentioned, an essential part of the process. You normally have to create sample meshes for more than one frame to guarantee a consistent look of the mesh over the entire simulation range. The final mesh process should always be performed as a separate task and never during the particle simulation.

All mesh settings depend on each other in some way and this makes it more difficult for beginners to find appropriate settings. The best way is to test out the individual parameters step by step and have a close look at the results. This helps you to get a better understanding of how the parameters influence the final mesh.

12.01 adding a MeshTo create a mesh you simply have to add a mesh object either by selecting the appropriate type from the Tool Bar or the Menu Bar:

Edit > Add > Mesh > [ Mesh type ]

You can choose from three different mesh types: “Particle mesh (RenderKit)”, “Particle mesh (Standard)” and “Grid mesh”. These three types are substantially different, but also share a couple of common settings. Please note that particle-based mesh types only work with particle emitters, while the grid mesh can handle both standard and grid fluids. The only premise is that at least one grid domain is attached to the mesh container.



Introduction | 179

If there’s just one emitter in your scene, the emitter is automatically attached to the emitter container and you only have to think about the settings. With two or more emitters you have the choice of whether you want to group them all under a single mesh node or create individual meshes.

a. Right-click Menus For Mesh Nodes

For the purpose mentioned above, RealFlow provides a specific right-click menu with various options. To open this menu, locate the mesh object in the Nodes panel and right-click on it.

The right-click menus for RealFlow meshes.

“Rename” helps you to change the node’s name. When altering names you should always be careful not to enter an already existing name and avoid special characters, like $, & or country-specific glyphs.

“Remove” will delete the currently selected mesh node including the attached emitters. In this case all settings will be gone and can only be restored with an “Undo” action:

Ctrl + Z (WIN, Linux) / Cmd + Z (OS X).

“Open curves” opens the Curve Editor for the node and adds it to the editing list. Please note that there are no properties that can be animated with the pure mesh node. If you want to animate parameters, please select one of the settings under Node Params.

“Group” allows you to create a new group and directly attaches the mesh node including all connected emitters to this group. If the mesh node is already grouped you can additionally see an “Ungroup” entry to detach the object.

“Build” is used to create a mesh from a single frame. In this case you don’t have to mesh the entire simulation range and you can get a preview. This function is important for testing your mesh settings.

“Insert emitters” lets you choose from the list of all available emitters in your scene and you can add them selectively one by one.

“Insert all emitters” automatically attaches all available emitters at once.

“Clean list of emitters” removes all emitters from the selected mesh node, leaving an empty container behind. Of course, this mesh object can be filled again with emitters.

“display mesh on viewport” is either ticked or unticked. By default, this option is active and the meshes are shown once they’re created. You can save time by deselecting it, because the display of high resolution meshes can take a while.

“Tree” shows a submenu which is the same for all nodes and gives you the opportunity to manage the Nodes window. You can show or hide certain node types selectively. “Expand All” is used to open the mesh node’s branch, showing all attached emitters. “Collapse All” closes the selected node’s branch and hides the attached emitters. “Show All” and “Hide All” are filters to show/hide all entries in the Nodes panel. You can also control visibility for each object class individually by selecting the desired entries from the list.

“Copy name” simply copies the node’s name to the clipboard. It can then be pasted to any other object.



Introduction | 180

b. special settings For Grid Meshes

Grid meshes show some slight differences. The first, and probably most important one, is that you cannot attach grid fluid emitters to a mesh container, but only domains. Also, it’s only possible to add one domain. In other words, you’ll need one mesh container per domain. Standard grid fluid particles (e.g. splashes) are meshed either with the standard (ST) or the RenderKit (RK) engine. Right-click menus for grid meshes show an additional entry:

c. storing Mesh Files

Of course, meshes can be stored in individual files with RealFlow’s Export Central (see page 55). There you have several options to define paths, file names and different formats. The standard format for meshes is BIN (see page 62). Though it has the same extension as standard particle files, the content is completely different.

12.02 common settingsAs already mentioned, all three mesh types share a couple of common settings. These settings have the same functionality and therefore they can be explained here together.

a. The Filters panel

Filters are a very important and effective tool to sharpen meshes and eliminate the rounded and “blobby” look. Especially meshes from emitters with smaller particle amounts can profit from this option, but also high-resolution simulations will look better with at least some filtering. Though you might lose details, the result is convincing and actually filtering should be applied to any mesh.

FilterYou can choose whether you want to apply the filters (“Yes”) or not (“No”). Filtering is a

very fast method and doesn’t increase meshing time too much. The result is always worth the slightly longer creation process.

RelaxationThis type stretches and sharpens the mesh’s edges and gives you a much more natural look. The result is a more watery and realistic appearance. “Relaxation” helps you to get quality meshes even from low resolution emitters. The default value is a very good starting point and it’s very likely that you won’t have to alter it at all. “Relaxation” is very sensitive, so instead of changing the filter’s strength it’s often better to lower or raise Steps. Though “Relaxation” is very effective, it has limits: emitters with just a few hundred or thousand particles are not really suited to create a perfect mesh – even with filtering.

“Relaxation” should also be used with care in terms of creating a believable fluid. An overdone effect can lead to very sharp and unnatural edges, and the entire mesh starts shrinking. The higher the settings, the more details get lost. Of course, this is sometimes wanted – for example for a liquid metal look one would expect from mercury or similar substances with high surface tension. Also sponge-like tissues are a very nice field of application for high “Steps” settings and the “Relaxation” filter.

TensionIf you can see unwanted high frequency structures on your mesh, then it’s a good idea to activate this filter type. “Tension” flattens the mesh surface and removes these artefacts. Similar to “Relaxation”, this type is also very sensitive and strongly depends on the according “Steps” settings. Normally, high-frequency patterns don’t occur very often, so the “Tension” filter is rarely used.



Introduction | 181

StepsEach filter is affected by this parameter. Higher settings strengthen the influence of “Relaxation” and “Tension”, and they can lead to completely over-filtered meshes. Values above approximately 120 may produce unrealistic results, unless you really want to achieve a certain effect. Another issue is that very high settings will reduce the amount of details. The default value of 64 is sufficient for many scenes, but of course it makes sense to experiment with lower or higher settings. A range between 32 and 96 seems to work best for most applications.

Filter = No Relaxation = 0.1 Steps = 64 Relaxation = 0.5 Steps = 64

u Higher “Relaxation” and “Tension” values should be compensated with lower “Steps” settings.

b. The clipping panel (RFRK/standard)

Clipping is a very effective and convenient way to reduce a mesh’s size. Whenever there are invisible parts they should be clipped. Try to use objects which are as simple as possible with even surfaces, for example cubes, because complex objects will only increase mesh creation time!

u The settings described below are only valid for RFRK and standard meshes. Grid fluid meshes have no clipping options.

Clipping boxAt first glance there doesn’t seem to be a visible difference between “Clipping box” and “Clipping objects”. With both functions you have to select an object that’s used to define the boundaries of the mesh.

With “Clipping box”, the result is always a rectangular volume, regardless of the object used. RealFlow calculates a bounding box around the node and only the inner part of this box will be used for clipping, while outside parts won’t be considered. After the generation of the mesh the bounding box around the clipping object is displayed as a red frame.

Clipping objectsClipping isn’t restricted to a single object and RealFlow supports multi-selection with this tool. Simply choose the desired nodes from the node picker and arrange them to your needs. All items will be taken into consideration while clipping the mesh. In opposite to “Clipping box”, RealFlow considers the actual shape of the object and calculates a proper mesh following the faces of the clipping object(s). This process, of course, takes longer to calculate than the Clipping box method. A comparison between “Clipping box” and “Clipping objects” can be seen on the following page.

InOut clippingYou can decide which “side” of the clipping object should be used. “Inside” uses the object’s volume and everything inside it will be cut away. “Outside” clipping deletes all polygons outside the used node. Open parts or holes are filled with polygons and the result is a closed mesh.



Introduction | 182

Camera clippingThis option needs a camera, of course. It makes no difference whether the camera is imported or native – both types can be used. “Camera clipping” cuts away everything that’s outside the currently adjusted field of view. That’s something like WYSIWYG – “What you see is what you get” – and also works with animated cameras.

@ Clipping CameraHere you can specify the camera object you want to use for clipping.

Realwave clippingWhenever you have to use particles in combination with a RealWave object, it’s a good idea to think about “Realwave clipping”. Invisible parts of the mesh below the surface can be cut away to save resources and rendering time. Since there’s only one RealWave object per scene allowed, there’s no node picker available. The existing object is recognized automatically when you turn this option to “Yes”.

Clipping object “Torus” Clipping box Clipping object

c. The Texture panel (RFRK/standard)

If you want to add certain properties (e.g. speed, pressure or temperature data) to your mesh, then you should have a look at this panel. Here you can find all necessary settings for translating physical data into UV coordinates. Please keep in mind that the texture can only be seen with the viewport’s texture mode:

Menu Bar > View > Scene > Textured

u The settings described on the right are only valid for RFRK and standard meshes. Grid fluid meshes have different options.

UVW MappingWith this parameter you can choose which data type should be applied to the mesh. You can select from “UV particle”, “UV sprite”, “Speed”, “Pressure” and “Temperature”. The last three properties can also be visualized on a particle basis with the emitter’s Display tab (see page 101). There it’s possible to adjust a colour range for the lowest and highest appearing values. By default this range is represented by a gradient from blue to white and these information can be translated to the mesh. If you don’t want to see any attributes, click on “None”.

Load textureTo visualize the attributes from UVW Mapping it’s necessary to load a texture. This function calls the OS’s file picker and loads any greyscales or colour maps.

TilingIf you want the texture to be repeated on your mesh, activate “Tiling” by setting it to “Yes”. But be careful, because “Tiling” creates regular patterns.

Apply map nowSometimes it’s necessary to refresh the map, because of changes in size, tiling or fluid properties. To apply the map again to the mesh, this button is used.



Introduction | 183

Speed infoThis setting is only relevant when your render engine is capable of reading out vertex data. In this case you can apply the speed information from the mesh to add motion blur, for example.

d. The optimize panel (Grid Mesh/RFRK)

Fluid meshes often consist of several hundred thousand or even millions of polygons. For fast display and rendering inside your 3D application this fact sometimes is a real performance killer. Therefore, RealFlow provides effective methods to optimize your meshes and reduce the number of polygons. Especially with view dependent scenes, a reduction of polygons is a perfect way to decrease rendering times.

u The following settings are only valid for grid fluid and RFRK meshes. Standard meshes have different options.

OptimizeThis entry provides three options: “No”, “Curvature” and “Camera”. “No”, of course, disables any optimization. Both of the others unlock further settings to control the mesh quality. The “Camera” option depends on the current view. Areas closer to the camera have higher resolution, while distant parts show reduced quality. “Curvature” analyses the mesh’s geometry and polygons in flat areas will be removed first. Higher values can be used to delete polygons from areas with more curvature, too.

@ Quality factorTo specify a mesh’s quality, you can enter a value between 0 and 1. Higher settings yield better meshes, but decrease calculation speed.

@ Polygon Reduction PercentYou can easily reduce the number of polygons by determining a certain percentage. An example: By entering a value of 75, this function keeps approximately 75% of the original polygons and deletes the remaining 25%. So, a mesh with 100,000 faces will have around 75,000 polygons left after optimization.

@ Optimize CameraBefore the mesh engine can calculate the mesh based on a certain view, a camera has to be selected. This camera can also be animated to create a dynamic view-dependent mesh. It’s also possible to attach imported cameras from other 3D programs.

@ DistanceThis value represents the distance between the camera and the area where the first polygons will be removed. With growing distance (= higher values) the number of polygons decreases. The area of highest resolution is always next to the camera.

e. The shader panel

An interesting feature is the possibility to use different shaders for displaying the grid fluid mesh in the viewport. This gives you a much better impression of the final mesh. The shaders are OpenGL compatible and therefore displayed very fast – actually in realtime. Of course, shading speed strongly depends on your graphics card and the available memory.Especially with grid fluid meshes from the new large scale solver, the visualization of displacements is an interesting feature.



Introduction | 184

Mix ratioHere you can specify the ratio between refraction and reflection. Smaller values reduce the refraction and create a chrome-like look. Reflections always require an environment map and the transparent shaders do not calculate reflections between nodes from your scene. Inversely you can also enhance the influence of refraction by increasing “Mix ratio”.

Environment MapTo show reflections it’s necessary to load a map that will be projected onto the current mesh. With spherically projected maps you’ll get the best and most accurate results, but any other image will work as well, though there might be visible seams. You can use TGA, BMP, PNG, TIF and JPG files. This function will surely create the best results, and it’s also very fast.

A standard mesh with different environment maps, shaded in realtime.

The Displacement shader

For grid meshes “Displacement” is surely the most interesting, because you can directly display the displacement generated from a cached grid fluid simulation. With this fluid type you have the option to activate the calculation of a displacement map and use it with

TypeRealFlow offers a total of 4 different methods with additional options: “None”, “Transparent”, “Displacement” and “Custom”. It’s also important to know that a mesh’s colour selection from the Node panel can influence the final appearance of some shaders.

None“None” is RealFlow’s default setting and the mesh is displayed according to your settings made under the View menu: “Bounding Box”, “Wireframe”, “Flat Shaded”, or “Smooth Shaded”. By choosing another option from “Type” the interface provides sets of different parameters to specify the desired look.

The Transparent shader

This shader mimics reflection and refraction effects by performing some simple calculations with the angle between the mesh’s normals and the user’s (or camera’s) point of view. The transparent shader isn’t aware of the mesh’s shape and recognizes only the visible part of the surface. This means that two completely different meshes will be shaded exactly the same way when observed from a certain point of view.

DepthThis parameter mimics the amount of refraction, but on a very simple level. A value of 0.0 means that there’s no refraction at all, while higher settings lead to more distortion. Please note that this is not a physical accurate calculation of dielectric materials, it’s more an approximation. Also this effect is not always clearly visible, because it strongly depends on the current point of view and the environment map used.



Introduction | 185

any mesh. Other forms of displacement are valid, too, of course, and the shader can be used as a preview if you’re planning to add some custom displacement later inside your 3D software, for example. The image format must follow the 2n rule. This means that you can use any bitmap with a colour range of 2, 4, 8 or 16 bit. RealFlow uses colour images instead of grey scale bitmaps to achieve displacement along all three axes to create effects, like choppy waves.

ImageThat’s just the path to the image you want to load.

ScaleYou can scale the projected displacement map to your needs by simply adding values different from 1.0. Please note that this option only changes the way how the map is displayed. It does not affect the real scale of the mesh’s UV grid.

RepeatThe number of repetitions is controlled with this setting. Low numbers lead to stretched views, while higher settings produce patterns. Please note that this option only changes the way how the map is displayed. It does not affect the real scale of the mesh’s UV grid. Tiling is only performed along the horizontal axis and any height information will be ignored.

Source (only available with grid fluid meshes)

You can choose between “Domain” and “Image”. The first option directly loads displacement maps from the attached grid fluid domain with the appropriate feature. It can be activated under:

Grid fluid domain node > Node Params > Displacement > Calculate > Yes

Please note that the above feature cannot be added in a post process and must be enabled before the simulation starts. If the grid fluid doesn’t carry displacement information, you can also load a bitmap sequence with the second method “Image”. The image(s) must be RGB files.

The custom shader

OpenGL has a programming language implemented known as GLSL (OpenGL Shading Language). It’s a C-like language that was introduced to create own definition of shaders and RealFlow provides an interface to GLSL. This way you can specify custom tailored shaders by either importing source code or using a so-called framebuffer as texture. The framebuffer method allows you to build complex shaders with a variety of different attributes. You can apply code for vertex, fragment and geometry shaders.

A custom toon-like shader.

Vertex ShaderHere you can specify the path to an external vertex shader program, typically a .vert file.



Introduction | 186

Fragment ShaderThis feature has the same function as “Vertex Shader”, but requires a .frag file.

Reload ShaderWith this button you can reload and update the shader file(s).

When set to “Yes” it’s possible to use the following parameters for creating your own shader definition. Some of the values are represented by numbers; others use colours. Colour parameters can only use positive settings and colour integers between 0 and 255 will be translated into values between 0 and 1. You can also define 5 textures which will be passed to the shader. The available settings are:

FloatVar0-9This field expects a floating point number.

Vec3Var0-9Here three values are needed, because in RealFlow a vector always consists of three elements.

Vec4Var0-9Similar to “Vec3Var0-9” three values are necessary, but they’re represented as RGB colours. A RGB colour also uses a triplet of values and can be seen as a vector.

Texture0-4Just load up to 5 custom textures to be passed to the OpenGL shader engine.

For more information about shader programming please search the Internet or visit OpenGL’s official site. There are also many free examples available which can be used with RealFlow. Next Limit does not provide support for GLSL.

12.03 particle Mesh (RFRK)In 2009 Next Limit released the RealFlow RenderKit (RFRK) for high performance meshing and particle shading. This add-on also includes a completely new meshing engine, called FlowMesher, originally developed to create meshes during the rendering process. The idea behind this workflow was to save the steps where the mesh has to be created inside RealFlow, then stored, and finally imported to a 3D application. FlowMesher allows you to create meshes directly from particle data inside the 3D software. Now, this mesh type is also part of RealFlow, but there you still have to create and store the meshes before they can be used with a 3D software. The advantage is that the meshes are now compliant with all render engines, and not only with mental ray or RenderMan.



Introduction | 187

The main difference to RealFlow’s standard meshes is that you can directly select which particle attributes are stored with the mesh. You can choose from all available properties, which are part of the BIN file specification. The attributes are an integral part of the mesh and can be interpreted by certain render engines and then translated into vertex shaders for much more realistic results. In combination with RFRK meshes these attributes are called “Magnitudes”. You can switch them on and off selectively to visualize fading effects, for example, based on a particle’s age. Another idea is to visualize different zones of pressure for foamy areas. Especially in combination with particle-based shading methods you can create convincing and believable fluid renderings of unseen quality.

u Settings for “Filters”, “Optimize” and “Shader” are equal for all mesh types and therefore explained only once. Please have a look at the previous pages for finding the appropriate information.

a. The Mesh panel (RFRK)

This is the place for the mesh’s fundamental settings. They directly influence the way the polygons are created around the particle cloud.

BuildThis option tells RealFlow whether the mesh should be generated during the simulation process or not. It’s recommended to set it to “No”, because meshing should always be a

post process. There are so many settings that it would actually be impossible to create a convincing mesh on the fly simultaneously with the particle simulation.

TypeThe standard type for RenderKit meshes is “Sphere”. With “Sphere” the mesh is calculated very fast, but can sometimes show round borders. To compensate for this, the “Smooth” parameter and the particle emitter’s Field settings for “Radius” (see page 189) can be adjusted to achieve a better result. Without smoothing you can see the individual spheres around the particles.

Auto polygon sizeRealFlow’s mesh engine automatically adjusts the polygon size to get the best balance between quality and number of faces. You can activate/deactivate this feature by simply switching to “Yes” or “No”. With “No”, the “Polygon size” field is unlocked.

Polygon sizeHere you can enter a custom value for the mesh’s polygon size. Smaller values lead to larger mesh files, but also more detail. Lower “Polygon size” values take longer to calculate and need more resources. Please note that “Polygon size” is not responsible for the rounded look of a fluid’s borders. If you want to avoid rounded borders, filters and radius settings are of much higher importance. A sufficient amount of particles is also needed. Finally, the look of a mesh strongly depends on your scene scale.

Polygon size = 0.10 Polygon size = 0.04

Smooth“Smooth” blends the individual spheres and metaballs together to achieve a coherent



Introduction | 188

mesh. Without an adequate “Smooth” value you can see the individual spheres around the particles. The radius of these spheres is exactly the value you’ve entered under the emitter’s field settings:

Emitter (grouped under the mesh node) > Node Params > Field > Radius

Very high “Smooth” settings have an effect similar to very high filter steps (see page 180). If the value is too high, the mesh starts to look unnatural and many details will be lost. Please keep in mind that “Smooth” directly depends on “Polygon size” and high “Smooth” values can increase the mesh creation time significantly, but lead to smoother results.

Smooth = 0.0 Smooth = 200.0

Surface proximityTo decrease or increase the distance between the mesh’s polygons and the emitter’s particles, this value must be raised or lowered.

b. The particle Magnitudes panel (RFRK)

“Magnitudes” are fluid properties that can be used for vertex mapping and shading inside your 3D application. The RenderKit meshing engine provides a wide variety of magnitudes and you can activate or deactivate them according to your needs. Please note that you need a compliant render engine to make use of the magnitudes. Not every available renderer supports this information. The easiest way is to render with the RealFlow RenderKit, because it has interfaces to Next Limit’s Maxwell Render, mental images’ mental ray, and

Pixar’s RenderMan. In combination with Maxwell Render the attributes are not platform-specific and can be used with all major 3D programs.

Some attributes can look very similar, for example “Force” and “Pressure”, but this strongly depends on the mesh’s particle source(s). Other values, like “Age” might also create a uniform colour distribution, especially when the emitter’s “Volume” mode is on.



Introduction | 189

c. The Display panel (RFRK)

Each RealFlow node has certain display options to visualize the object in the viewports. RenderKit-style meshes also have a preview function for the individual parameter magnitudes, for example “Velocity” or “Temperature”. It’s an easy way to evaluate the results without having to export the mesh to a 3D application.

ColorBy assigning a colour to the mesh you can easily differentiate it from other meshes or particles. You can apply any valid RGB colour and the currently selected colour is displayed in the appropriate field.

Particle magnitudeWhen working with magnitudes and properties, it’s usually required to preview the results before they are rendered. To activate this feature you can select a particular property and watch the results in the viewport. The last images on the previous page show the particles’ “Velocity” and “Density” magnitudes. It’s required to switch to RealFlow’s “Smooth Shaded” mode to make the attributes visible:

Mesh node > View > Element > Smooth Shaded

TransparencyThe mesh can be made opaque, semi-transparent or completely transparent. Higher values increase transparency. This option is useful for evaluating mesh quality in combination with the particle cloud’s shape, for example.

Back face cullingWhen working with high polygon numbers or older hardware it might take a while to display a mesh in the viewport. This process can be accelerated by activating this option, because Back face culling doesn’t draw hidden polygons.

d. The Field panel (RFRK)

While the mesh-related adjustments are directly accessible from the mesh-node, it’s different with the particle-related parameters. They can only be seen with an emitter attached to the mesh node. These parameters can be adjusted individually for each emitter, making it possible to define specific settings and values for the emitters to generate a much better and diversified mesh. To get your hands on these parameters, select the desired emitter that’s grouped under the appropriate mesh node.

RadiusThe RenderKit mesh engine draws spheres around each particle by default. These spheres can be blended using the “Smooth” parameter. The individual spheres can be seen when “Smooth” is not used. The radius of these spheres is adjusted here.

Radius = 0.10 Radius = 0.02



Introduction | 190

Of course, “Radius” is also responsible for metaballs – if the metaballs do not influence each other, you can see the spheres with the adjusted Radius.

Subtractive fieldNormally meshes from two or more emitters are used to build a single mesh. In fact they’re added, but you also have the possibility to subtract meshes. This can be compared with a Boolean operation in your 3D application, where objects can either be added or subtracted to generate new structures.

e. The particle Filter panel (RFRK)

This set of parameters represents a complex, but easy to use tool to enhance particle shading and rendering. It’s possible to isolate particles from the core fluid based on the numbers of neighbouring particles.

CoreWith this parameter it’s possible to specify a coherent area of the fluid, which can be seen as a core. Particles with a certain distance or number of neighbours won’t be taken into account for the mesh. This helps to separate the basic core fluid from splashes and you can render foam structures, for example. With higher settings, the core fluid starts shrinking. Please note that this is a very sensitive value, especially with dense particle clouds.

SplashIf you want to create a higher amount of splash particles, this value should be increased. In some cases, for example when your particles are very close together, the effect of “Splash” may be less obvious.

VelocityYou can also separate particles by using a certain velocity threshold. Particle with velocities greater than the adjusted value can be rendered separately from the core fluid.

The “Core” value in this case is 0.8 and leaves a reduced mesh.

12.04 particle Mesh (standard)This is the traditional mesh type from previous RealFlow versions. It’s,a fast tool and provides many settings, making it a versatile mesh type, suited for many applications and different kinds of fluids. Like the RFRK engine, this type is also subdivided into two parts for mesh polygon settings and particle-based adjustments for the attached emitters.

The standard mesh’s core function is based on a powerful metaball algorithm to create the organic look of fluids. Metaballs can influence each other, or in other words: The individual spheres around the particles attract each other and make connections. With growing influence the mesh becomes thickerand smoother. Many 3D programs offer metaball functions, but RealFlow’s engine is highly optimized and provides a couple of special features for fluid generation. Even UV coordinates are supported. The standard mesh type offers more modes: Polygons and cloned objects. Polygons can be used for shattering effects, while cloned objects are good for grainy substances.

u The settings for “Filters”, “Optimize” and “Shader” are equal for all mesh types and therefore explained only once. Please have a look at the previous pages.



Introduction | 191

a. The Mesh panel (standard)

The Mesh panel allows you to adjust the polygon structure of your fluid mesh. You can also choose from different types of mesh creation, and you’ll find optimization tools when defining a camera-based level of detail. These functions directly influence file size and the amount of detail of the final mesh.

BuildBy switching from Yes to No you can prevent the mesh engine from creating meshes during the simulation. It’s highly recommended to perform meshing as a post process to have full control over the settings. Additionally it’s often necessary to create sample meshes from different frames to achieve a consistent look.

TypeYou can choose from 3 types: “Metaballs”, “Mpolygons”, and “Clone obj”. “Metaballs“activates the standard meshing engine to create the familiar fluid look. “Metaballs” creates spheres around the particles. These spheres influence each other based on the related Field settings (see page 194).

“Mpolygons” works similar to “Clone obj”, but doesn’t give you the possibility to define a

custom object. RealFlow automatically attaches a 2D polygon to each particle to represent the fluid cloud. “Clone obj” unlocks the subsequent parameter field and lets you choose any available node. Each particle is then represented by the selected particle. The result looks like an instanced object, though it’s not really instanced, but cloned. This means that you’ll need much more disk and RAM resources than with instances. The more complex the clone object, the bigger the final file.

Detail of a mesh, created from Mpolygons.

Clone objThis is the place to choose the node you want to use for the “Clone obj” type. It’s only possible to select a single object – multi-selection is not supported.



Introduction | 192

Polygon sizeThis is the most important setting when considering structure and surface, because it strongly influences the final size. Smaller values create higher resolutions and more polygons. With higher resolutions you can generate a better-fitting mesh with more details. A mesh can be compared to a wireframe that’s spread over an object. Now imagine a wireframe with just a few cells: It’s very hard to sculpt the grid and wrap it tightly around the underlying object. The denser the grid cells, the more accurate the results will be, and that’s exactly the effect with smaller “Polygon size” values: The mesh fits better to the outlines of the particle cloud, showing more details.

Please keep in mind that rounded or thick fluid borders cannot be removed with more polygons. If you want to create a mesh with thinner edges, add a “Tension” filter (see page 180), change your Field settings (page 194), add more particles and consider scene scale.

@ Num FacesThis value cannot be changed directly. It depends on “Polygon size” and will be updated automatically when any mesh parameters have changed, and the mesh was built again. While building the entire mesh range, “Polygon size” will also display the number of faces with each frame. By using small “Polygon size” settings and large meshes, “@ Num Faces” can easily reach several hundreds of thousands or a few million polygons.

LOD resolutionWith this option it’s possible to adjust a view-dependent mesh resolution based on your camera settings and point of view. It’s not only possible to define a distance range, but also the minimum and maximum size of the polygons. This feature allows you to customize your mesh to always achieve the best quality. The further away the polygons, the lower the resolution that can be adjusted. By activating “LOD resolution”, the associated settings are unlocked.

@ LOD CameraOf course, “LOD resolution” needs a camera object to work. You can choose any available camera node from a list. The field of view and point of view settings are analysed and used for the calculation of the mesh’s resolution.

@ Min distanceThis is the minimum distance from the camera and represents the area with the highest resolution. It interacts with “@ Max distance” and the range between both values is

interpolated, building a range. Within this range, RealFlow calculates the appropriate polygon resolution.

@ Min Polygon sizeThe minimum size of the high resolution area is determined here. If your camera is very close to the mesh, the “@ Min Polygon” size should be correspondingly smaller.

@ Max distanceThe maximum distance from the camera is specified with this value.

@ Max Polygon sizeIf the distant areas of the mesh are very far away from the camera, this value can be rather big. Make sure you avoid a coarse look of the final mesh.

b. The optimize panel (standard)

Meshes can consist of up to many millions of polygons and this can be a real challenge for some 3D programs. It can also take long to render those high-resolution structures. A very good way to reduce the amount of polygons without losing (too much) detail is RealFlow’s ability to optimize a mesh. Especially in combination with a camera optimization, because you can specify that parts closer to the viewer should have a higher resolution, while distant areas should consist of less faces. Optimizing will increase the mesh creation time, but the render time can be drastically reduced, so you should always consider the available optimizations.



Introduction | 193

OptimizeIt’s possible to choose from 3 different modes. The first one is “None” and disables the optimization process. It’s also the standard setting. “Curvate” analyzes the mesh’s topology to find areas where it’s safe to remove polygons. “Camera”, activates the “Camera” field and optimizes the mesh based on the user’s point of view. The camera view should of course be maintained during final rendering. The optimization parameters are valid for both “Curvature” and “Camera”.

u The original polygon number for the examples shown below is 360,015.

@ CameraHere you can select the camera you want to use for the appropriate optimization process. This field is only available with Optimize > Camera.

@ Merge IterationsThis parameter specifies the number of optimization cycles and depends on “@Ite Threshold”. With each iteration pass, RealFlow tries to remove more polygons, but always related to “@ Ite Threshold”. With large “@ Merge Iterations” the mesh starts shrinking!

The left part uses a “Merge Iterations” value of 5.0 (244,656 faces), the right part 15.0 (145,776 polygons).

@ Ite ThresholdAs has already been mentioned, “@Ite Threshold” is closely related to “@ Merge Iterations” and can be seen as a trigger. Higher values are used to remove more polygons, but also decrease the mesh’s quality. The standard setting is a good starting point.

Left: @ Ite Threshold = 1.0 (265,468 polygons). Right: @ Ite Threshold = 12.0 (131,426 polygons).

@ Face subdivisionIn some cases, meshes show unnaturally hard edges, because of a lack of polygons in certain areas. “@ Face subdivision” can be used to add faces, creating a smoother look. However it also increases the number of polygons, leading to larger files. After this process, some parts of the mesh show a characteristic pattern, as shown below. It’s recommended to use filters and field settings instead of “@ Face subdivision”.

A mesh with activated “@ Face subdivison” shows an increased number of polygons (374,212).



Introduction | 194

@ Sub ThresholdYou can specify a certain trigger value to start the process of subdividing a mesh’s faces. Please note that, in most cases, this value has no influence on the final result.

c. The Field panel (standard)

This option panel is only visible with at least one emitter attached to the mesh node. It’s possible to adjust all the particle-related values for each emitter individually. You simply have to spot the desired emitter under the mesh node and click on it – the Node Params window immediately shows the available settings.

Blend factorIn RealFlow a metaball object consists of spheres around the fluid’s particles. This means that the particles’ positions are read and translated to a sphere. These spheres are able to influence each other. With a “Blend factor” of 0.0, the individual spheres can be observed. The size of these spheres can be adjusted under “Radius”. Please note that “Blend factor” and “Radius” are closely connected. With higher “Blend factors” the spheres start melting together, and the mesh appears rounder and thicker – depending on the adjusted radius. At some point you’ll lose details, but the mesh appears smoother, because some surface ripples, unwanted bumps or dents are ironed out.

The art is to find a balance between “Blend factor”, “Radius” and, last but not least “Polygon size”. Since all these values strongly depend on the particle simulation, testing is very important with meshes, though the default values are a very good starting point. You can alter “Blend factor” in both directions – either greater than the default of 95 or smaller.

RadiusAs mentioned under “Blend factor”, radius represents the size of the metaballs around the particles. With a “Blend factor” of 0.0 each particle is displayed as a sphere with the

adjusted radius. Very large “Radius” values normally lead to a roundish mesh with thick borders. A good starting point is the currently adjusted “Polygon size”. In combination with the default “Blend factor” of 95 you often get an already convincing mesh, or at least something you can play and experiment with to get the desired result. “Radius” can be very small, even below 0.01, but there’s a limit when no mesh polygons are being created at all. This limit depends on your fluid simulation and number of particles.

A “Blend factor” of 0.0 can be used to visualize the individual spheres of a mesh.

Subtractive fieldBy default, meshes from multiple emitters are added and blended together, but it’s also possible to subtract them. If you want to subtract an emitter from another, simply activate its “Subtractive field” option.

d. The Noise panel (standard)

In some relatively rare cases, a mesh might appear very smooth and surface structures are missing. That’s a situation where you can add a fractal noise to create a more interesting surface. This option doesn’t affect the particle simulation, only the mesh surface. Depending on your mesh and current scene scale, it’s sometimes necessary to use higher values to make the noise visible.



Introduction | 195

Fractal noiseTo activate the noise function simply switch this parameter to Yes and unlock the related settings. The settings are very similar to RealWave’s “Fractal” modifier (see page 210).

@ AmplitudeThis is the height of the noise ripples. Higher values create more distinctive patterns. Please note that this parameter is rather sensitive and should be altered carefully.

@ FrequencyThe number of oscillations per time unit is called frequency. Higher values create a denser pattern with more structures. A high “@ Frequency” value can lead to unnatural results.

@ OctavesThis setting could be seen as an overall noise. You can create more structures on the surface by raising “@ Octaves”.

A mesh with “Fractal noise” turned off... ...and on.

e. The Deformation panel (standard)

By activating this option, parts of the mesh are deformed based on the particles’ speed information. The result is a mesh with a filament-like structure. Depending on the entered value it’s possible to create a structure which becomes thicker (or thinner) with growing particle velocity. Deformations can help to visualize speed effects, where very fast parts of the fluid become torn and thin, while slower areas appear slightly thicker. As this effect reduces the amount of detail, the values should be chosen carefully. It might be necessary to change “Blend factor” and “Radius” in combination with these parameters. In order to evaluate the minimum and maximum speed values, it might also be necessary to check the emitter’s Statistics window:

Node Params > Statistics > V min / V max

Deformation looks best with activated filters (see page 180):

Node Params > Filters > Filter > Yes

Speed stretchingEach particle field (consisting of “Blend factor” and “Radius”) is elongated based on the speed of each particle. This results in some visible stretching and the individual particle might appear like little cylinders. By setting “Speed stretching” to Yes the following input fields are unlocked.

@ Min str scale / @ Max str scaleThese values represent the amount of deformation for the “Min speed” and “Max speed” settings entered below. Both range between 0.0 and 2.0.



Introduction | 196

Speed flatteningAnother effect that can be seen in nature with fast travelling fluids is flattening. Drops and parts of the fluids become slightly oval and flattened because of air friction. “Speed flattening” mimics this effect.

@ Min flat scale / @ Max flat scaleBoth values determine how strong the flatten effect is pronounced. The settings can range between 0.0 and 2.0.

Deformation deactivated Deformation activated

12.05 Grid MeshThe grid mesh is a new feature in RealFlow 5 and exclusively made for the new grid fluid solver (see page 65). Since this type of fluids has completely different demands regarding meshing, it became necessary to introduce a completely new type. The grid mesh is capable of creating seamless transitions between the core fluid and the particles of the secondary emitters (splash and foam).

There are some fundamental differences to the standard and RFRK meshes. The most important is that a grid mesh is not based on particles. Nevertheless the grid fluid particles can be used in combination with a standard mesh engine to create a three dimensional

representation of the fluid. You can also add particle-based fluids to the grid mesh, so a combined grid for the grid-based fluid and the particle-based fluids will be generated. The only restriction is to use only one grid domain node per grid mesh! Another obvious difference is that there are no field settings for grid emitter particles. This means that all settings are directly and exclusively made under the mesh node’s Node Params window.

Grid meshes often need some amount of filtering to smooth the jagged edges of the grid fluid. This coarse look is caused by the grid fluid domain’s cellular setup and occurs with very low “Detail threshold” values. As you might have already read, grid fluid domains are subdivided into cells. The higher the number of cells, the better and smoother the final mesh – will turn out. So one method to avoid this artificial look is to raise the grid fluid domain’s “Resolution” setting (see page 72), another one is a “Relaxation” filter (see page 180). Another way to achieve a smoother impression is to use displacement maps, but that’s only reasonable with ocean-like structures.

An exciting feature with grid fluid meshes is the option to create displacement data to give much more detail on the fluid surface. The displacement information is already generated during the grid fluid simulation, but only displayed with an existing mesh.

a. The Mesh panel (Grid Mesh)

This window provides the fundamental settings for the mesh and its polygons. These parameters are the only ones you can use to shape the mesh, as there are no field settings for the particles.



Introduction | 197

BuildThis setting defines whether the mesh is built during the simulation process or not. Though grid fluid meshing is a fairly fast process, it’s better to do this in post process. For small fluid domains and small amounts of particles it’s no problem to simulate and mesh the fluid simultaneously, but with heavy scenes it’s recommended to separate meshing from the fluid calculation. To speed up the meshing process, RealFlow’s command line version is the proper means, since this version does not spend CPU time updating the viewport with particles, shaded objects or existing meshes.

Detail thresholdThis parameter is connected to the appropriate setting from the grid fluid splash node (see page 77). A value of 0 means that the mesh is created around the entire fluid, including those areas where more detail is demanded. You will end up with meshes that are very coarse in the areas where accuracy is required. A value of 1 will create a mesh just around the core of the fluid and areas with a need for higher detail are left out. This way you can combine the mesh with the grid splash nodes and achieve interesting results for large scale scenes.

Detail thresold = 0.2 Detail threshold = 0.5

With smaller amounts of particles, the mesh in this case is often reduced to a very small area and sometimes there’s no visible mesh at all. An insufficient amount of particles can also lead to rather thick meshes. Filtering could be a help here, but it’s not possible to completely get rid of the coarse appearance. The best way to enhance mesh quality is to increase the grid fluid domain’s number of cells with the “Resolution” parameter.

Auto polygon sizeThis option is activated by default and polygon size is determined automatically by the mesh engine, based on various parameters, e.g. number of particles and resolution. It creates a balance between these factors, but in some cases the results might lack details and finer structures. Under these circumstances, “Auto polygon” size must be set to “No” to unlock “Polygon size”.

Polygon sizeHere you can enter the desired size of the polygons. Lower settings create more polygons and larger files, but also show more and finer details. “Polygon size” is not suited to remove round and thick borders of the fluid. To get thinner edges use filtering and/or more particles.


Open boundariesBy default the meshes are closed and the boundary is the grid fluid domain container. If you want to remove these restricting “walls”, choose “Yes”. The result is an open mesh.

b. The Texture panel (Grid Mesh)

The dialogue for grid fluid meshes is directed on the characteristics of this particle type. Grid fluids only represent the core fluid of a large scale simulation and therefore, only a limited number of possibilities is required.



Introduction | 198

UVW Mapping = None UVW Mapping = UV particle

UVW Mapping = Top projection UVW Mapping = Top projection (average velocity)

TransparencyIf you want to see how the mesh fits the particle cloud, transparency is a very good means. By defining a certain amount of transparency you can easily evaluate the quality of your mesh. 0.0 means that the mesh is completely opaque, while 1.0 is to the same as setting “Visible” to “No”.

Back face cullingThis option makes it impossible to select polygons from invisible parts of the mesh.

UVW Mapping“None” disables this feature. “UV particle” takes the particles’ UV coordinates into consideration and creates an UV grid for the mesh. This mapping type can sometimes lead to distortions “Top projection” is just a flat projection method, so the map becomes stretched and distorted at the mesh’s edges. “Top projection (average velocity)” uses the same mapping method as the previous option, but it’s based on the fluid’s velocity. The 4 images on the right show all available types.

Load textureThis is the dialogue to open and load the desired texture used for mapping.

TextureWith this option it’s possible to toggle the texture’s visibility. Once a texture has been applied you can easily switch it on or off by changing between “None” and “File”. The second option requires a previously loaded file.

c. The Display panel (Grid Mesh)

It’s often necessary to hide a mesh to have a look at the particles underneath. because this helps to evaluate the accuracy of the mesh or simply makes other parts of the scene visible. The Display tab provides various settings to draw the mesh the way you want.

VisibleYou can hide the mesh by changing this option from “Yes” to “No”.

ColorA mesh can be dyed by choosing a new colour from the operating system’s colour picker.



Introduction | 199

13 RealFloW caMeRas

In RealFlow cameras a very important means to evaluate the quality of a simulation or test out different views and perspectives. To give you total freedom, RealFlow can handle both native and imported cameras, and you’re able to add as many cameras as you want. Imported cameras are also a special case, because they can carry all animation information from your 3D software; also they’re the only object that can be deleted from SD files without removing all the other elements. By default, imported cameras are locked to preserve the settings. But please note that some applications provide very specfic functions with cameras and not all of them will be translated to RealFlow.

RealFlow cameras actually work like any other camera inside 3D programs – they’re similar to pinhole cameras. Of course, there are already sophisticated cameras (e.g. in Maxwell Render), representing complete lens systems, but that’s more a feature for rendering, not for fluid and object dynamics. RealFlow cameras have a basic, yet adequate set of functions.

To switch to camera view, the fastest method is to grab the camera object from the Node panel and drag it to the viewport. Another method is to right-click into the viewport and select the appropriate camera:

Right-click menu > View > [ Camera node name ]

13.01 The Node panelThis set of functions is common to any RealFlow object, though the parameters slightly vary. The Node panel is used to specify a node’s location and position inside 3D space. “Simulation” is used to include or exclude an object from a simulation. For cameras this is more or less dispensable, because they’re not physical objects – they only represent the user’s current point of view. Position-related settings always need a trio of values for all three dimensions X, Y and Z. Even “Shear” deformation works, but has no influence on the camera’s perspective, though the representing icon is distorted. “Color” simply assigns a new colour to the object’s representation in the viewport.

u A complete explanation of the remaining Node panels features and parameters can be found on page 95.

Parent toThis is possibly the most interesting function. By parenting a camera to another object, it’s possible to change its position remotely. Instead of animating the camera object itself, this function forces it to follow the movements of an animated object. This is an especially exciting feature for object dynamics: you can follow falling bodies, create impressive views from object crashes or follow others moved by the power of fluids. By using “Parent to” it’s absolutely easy to create most complex motions without creating a single key!

13.02 The camera panelThis window provides all necessary parameters for adjusting the camera, respectively the point of view.

u Most values are animatable to create the desired motion and field of view changes. With imported cameras, many fields are locked, though you’re still able to rotate and move them without limitations, but with the next frame or reset, all values are restored.

VisibleYou can switch the viewport's camera icon on and off with this option.

LookAtThis is the point in space the camera is oriented to – it requires three values for X, Y and Z.



Introduction | 200

Below you can see two views: the first one is a camera’s standard perspective, the second shows a clipped view. If you have a close look, you’ll note that even the background grid is clipped!

You can enter any positive or negative value, including 0. When "Link target" is used, these fields are not accessible, because the “LookAt” vector is then determined by the target node. In RealFlow’s viewport, “Look At” is represented by a dotted line.

Link targetYou can use any available node as a target, the camera is then oriented to. Even daemons can be used for this purpose. The target object doesn’t have to be identical with the Parent to node, because both features work completely independently from each other. When “Link target” is activated, the camera automatically focuses the selected item, regardless from any performed motion.

RollThis value is given in degrees and controls the camera’s inclination along the horizontal axis. “Roll” is often used for dramatic effects and flyovers appear more realistic with animated rolling.

FOVThis is the abbreviation for “Field Of View” and describes the visible section of the scene. Larger values create a wider impression; small settings will narrow your view, giving more focus on a certain object. “FOV” expects an angle as input.

Near Clip Plane / Far Clip PlaneWith clip planes you’re able to restrict the field of view in near and far distances. Everything that’s outside this pair of imaginary planes is simply cut away and not visible anymore. By specifying clip planes it’s possible to look inside closed objects, without having to delete polygons – it’s a non-destruction method. There’s just one value available, because clipping only makes sense along the camera’s viewing direction and therefore it’s closely linked to “Look At”.



Introduction | 201

14 RealWaVe

RealWave is a powerful wave simulation toolset for small to mid-range ocean surfaces with versatile features. Objects, for example, are able to provoke waves from interactions; they can contribute to foam-maps or generate splash particles. Even particles from standard emitters are able to create waves and ripples. Another principle behind RealWave is the use of predefined modifiers to achieve various types of different conditions from calm or breezy to stormy. All these modifiers, objects, and particle-based waves can be combined without any limitations. Finally, scripting opens another dimension by giving you the ability to use your own formulas or load displacement maps for custom waves. With RealFlow 5, new ready-to-use modifiers have been introduced. The two most important ones are:

• Statistical Spectrum waves (see page 214)• Gerstner waves (see page 213)

Statistical Spectrum waves. Gerstner waves with overlaid Fractal modifier.

The only wave form that cannot be simulated with RealWave native tools are breaking waves. This type can often be seen near coasts or on a very rough and turbulent sea, where the waves get high enough to become unstable, and finally break. With RealWave’s ability to connect wave surfaces and objects it’s even possible to create impact and Tsunami-like waves. For the creation of breaking waves, RealFlow 5 now provides the new grid-based fluids (see page 65) or Python/C++ approaches.

The idea behind RealWave is the displacement of a mesh’s vertices to achieve certain wave forms and structures. With RealWave it’s possible to simulate complete ocean surfaces including all primary and secondary effects, such as foam or spray. The combination of different modifiers allows you to simulate an almost infinite variety of waves and the interaction of waves and rigid body objects or pre-animated items is another strong feature. All these possibilities and a wide range of further options make RealWave fairly unique, because there are no limitations regarding interaction of RealFlow’s dynamics and fluid solvers. The only restriction in terms of interaction is that there can only be one RealWave mesh in a scene. For use with 3D programs, it’s necessary to store the meshes into SD files and, unlike to previous RealFlow version, these files are no longer limited to 2 GB!

Aside from all these benefits, RealWave is fully customizable and the results can even be meshed to establish seamless connections between the ocean surface and the particles, e.g. for impressive splashes. And all this is performed at high simulation speed, because RealWave uses all of your CPUs and cores. Another strong feature is RealWave’s ease of use. Links between the various solvers are simply established with drag and drop. Due to this tight integration, RealWave also supports global and exclusive links, and each object and emitter has its own RealWave parameter set for adjusting the interactions to your own special needs.

RealWave is based on a so-called hexamesh structure. This name is based on the arrangement of triangulated patches resulting in a hexagonal pattern (see below). Please note that RealWave surfaces always intersect interacting objects: there’s is no “hole” inside an object where the wave polygons are left open.

The size of these patches can be adjusted to create a denser mesh with higher resolution to show more details and finer structures.



Introduction | 202

14.01 File TypesWith RealFlow 5 a series of new file types has been introduced. These files make it much easier to handle large amounts of data stored with simulations of ocean surfaces. We can differentiate between 4 different categories:

• Particles BIN, PD, ASC, PDC• Surface cache (“Realwave Cache”) RWC• Surface deformation SD, LWO, BIN• Textures TGA, BMP, JPG, TIF

By default RealFlow exports RWC files storing the surface data in single file per frame. These files are used for playback purposes and can also be used with the new RWC Sequence modifier (see page 213). Another default export format is TIF which is used for displacement maps. These textures are recorded together with TXT files containing displacement information for the adjusted axis setup (XYZ or YYY). Displacement TIF images support 16-bit colour depth.

14.02 Basic WorkflowsOver the next few pages you can find a couple of fundamental workflows for RealWave, showing you how to establish particle-wave or wave-object interactions, for example. The advantage is that everything’s kept as easy as possible and in most cases you really just have to make a few clicks. The result of these settings is a complex interplay of RealFlow’s different solvers and wave surfaces.

a. adding a Modifier

Adding a new RealWave surface is just a matter of seconds and as always you have several options:

Toolbar > RealWave > SurfaceEdit > Add > RealWave > SurfaceRealWave node >Right-click menu > Add > RealWave > Surface

From this simple operation you get a plain mesh without any waves or displacement information. The easiest way to add structures to this plane is the use of a modifier:

1. Right-click on the RealWave node.2. Expand the “Add Wave” submenu.3. Choose the desired modifier and click “Reset” to see the structures.4. Optional: repeat step 3. for additional modifiers.

b. Dynamic objects and particle Interaction

When an emitter or object is added to a scene with a RealWave surface, you’ll notice a new panel under Node Params, called “RW Particle Interaction”, respectively “Realwave”. This set of parameters controls the entire interaction between the particles and the ocean surface. Bodies and particles have the ability to create secondary small waves, just as in real life where splashes produce ripples on water surfaces. You can control everything from impact strength to wave speed with these settings. When particles interact with a surface they can also contribute to a foam map.

For the interaction with dynamic bodies, the appropriate feature has to enabled under the object’s node settings first. Additionally the (rigid) body should be made moveable, otherwise only static interactions, like wave reflections, are possible:

Node Params > Node > Dynamics > Rigid body / Soft bodyNode Params > Rigid body > Dyn Motion > Yes

Finally you have to adjust the appropriate RealWave parameters of the currently selected object. This panel is only visible with a RealWave surface in your scene and contains all necessary settings, including the option to generate foam maps:

Node Params > Realwave

Another method is the usage of particles to create small ripples or fine surface structures. In combination with RealWave, particles act like small objects causing more or less strong impacts disturbing the and displacing the mesh. Similar to rigid bodies, emitters also have an individual RealWave panel:

Node Params > RW Particle Interaction



Introduction | 203

Rain drops from particles on a RealWave mesh.

Rigid/soft bodies and emitters (particles) share some parameters, for example wave speed and texture strength. In the same way as with rigid bodies, the RW Particle Interaction panel is only visible with an already existing RealWave node. Additionally, there are two extra emitters that will only work in connection with a RealWave object:

• Object splash (see page 216)• Crest splash (see page 220)

u The individual settings and their meanings for rigid/soft bodies are explained in detail starting on page 154. The emitter-based settings can be found on page 97.

c. Foam Maps

Foam maps are created from interactions between particles from all kinds of emitters or objects and the RealWave surface. Each particle can print a mark onto a projected texture map. The intensity and life-span of these spots is controlled by a few parameters. Objects can also contribute to foam maps. To activate the generation of these maps a certain switch has to be turned on from the RealWave node’s parameter window:

Node Params > Realwave > Calculate texture > Yes

Particles as well as objects have a special parameter called “Texture strength” to control the strength of the energy samples on the final map. This setting can be found under the emitter’s/object’s “Realwave” window. By default it’s already set to 1.0 and normally you don’t have to think about it anymore.

The last step is to prepare the output functions for the image sequence:

Export menu > Export Central > REALWAVE > Realwave node > Foam texture (*)

That’s actually all you need. The appropriate settings for ageing and propagation are also made under the RealWave node’s settings. More particles create better foam maps, because the distance between the individual samples is reduced. This leads to a denser map with better visible foam. RealFlow provides a realtime preview in the viewport. To see the evolution of the maps, switch to the smooth shaded mode:

View > Element or Scene > Smooth Shaded

Please note that the map preview is only available during simulation. During playback you’ll only see the last simulated foam map, but not the changes over time. To get a better view of the maps it’s recommended to make the particles invisible:

Node Params > Display > Visible > No

d. particle layer

In many cases it’s necessary to create splash particles from moving or impacting objects, add foam particles, or simply use fluid particles in combination with waves and objects. Under such circumstances you’ll often need a connection between the RealWave node's mesh and the particles from different emitters.



Introduction | 204

With “Particle layer” you can easily transform the vertices and polygons of the RealWave mesh into particles. These particles cannot move freely; they’re glued to the mesh and follow exactly any motion of the waves. Wave particles can now be combined with emitter particles, giving the impression of a seamless water surface.

u RealWave particles are influenced by destructive daemons, like k Volume. With this daemon the particle layer starts disappearing. To avoid this, it’s a good idea to make “k” daemons exclusive to emitter particles.

14.03 RealWave settings

A RealWave node always consists of two parts – the node and a modifier. You’ll notice that there’s already an existing modifier called “Object interaction global” with each RealWave. This default modifier can’t be removed, since it’s inevitable with wave-object interaction.

By clicking on “Object interaction global”, you can also see that it has its own Node Params settings. These adjustments are, as the name implies, valid for all objects the wave is

interacting with. If you want to change basic parameters, for example wave speed, for all bodies, it’s no longer necessary to do this for each object individually. Nevertheless you can specify individual “Object interaction” settings for single nodes or groups of items with an appropriate modifier.

a. The Node panel

The Node panel parameters only affect the RealWave object itself, respectively the global appearance of the plain mesh, not the modifiers.

u The settings listed under Node are the same as with other RealFlow nodes, e.g. emitters or objects, and have been widely discussed before. The only difference is that it’s not possible to convert RealWave objects into rigid or soft bodies or use transformations with “Shear”. Explanations for Node can be found on page 95.


Initial states are very useful. By creating such a state, you can write a single file, containing all current adjustments and modifications. To use them, simply reset to the saved initial state and start the simulation again.

u Initial State has been explained before – please go to page 96 There’s also a standard workflow for creating an initial state.



Introduction | 205

d. The Realwave panel

Just like the settings and panels before, this section is again only valid for the RealWave node, not the modifiers. Modifiers have their own adjustments and are discussed later in this chapter. “Realwave” is responsible for the mesh’s appearance and your’re also able to activate some core features here, for example the calculation of foam-maps.

TypeYou can choose between “Hexamesh” and “Custom”. “Hexamesh” is the default setting for creating a standard mesh with a dimension of 5.0 x 5.0 units. “Custom” unlocks the next parameter, giving you the opportunity to load other objects into RealFlow and turn them into a RealWave object.

Custom objThis feature is only accessible with Type set to “Custom”. By clicking on the hyphen you’ll have access to the file picker. Simply select a 2D or 3D object that you would like to translate into a RealWave mesh.

The Initial State panel for RealWaves is exactly the same as for other nodes.

c. The Display panel

Like any other node, RealWave also has its own display options. There are 4 functions:

VisibleMaking a surface invisible in the Viewport is handy when you are evaluating the motion of rigid bodies which are influenced by waves, or the distribution of crest particles.

Show normalsA RealWave mesh consists of polygons, similar to RealFlow objects, and it’s possible to visualize their normals. You can choose between “Yes” and “No”.

Normal sizeWhen “Show normals” is set to “Yes”, you can control the length of the normals here.

TextureIf you want to show a textured view you can use either "Depth factor" or "Foam".



Introduction | 206

Polygon sizeThis is the most critical parameter with RealWave regarding file size aside from the node’s scale settings. Smaller values lead to longer simulation times and bigger files, but you can also see much more details. With larger settings you can create vast ocean surfaces, but you’ll also lose details. It’s important to find a good a balance between the amount of details and polygon size, because with very fast travelling waves, high resolution meshes tend to chaotic structures, like spikes and peaks, or visible patterns.


Displacement modeBy default this option is always enabled and also activated under Export Central (see page 55 and the following). The result is a sequence of 16-bit TIF files together with TXTs. The TXTs is a standard ASCII file and contains the maximum and minimum displacement values for each axis of the normalized map. “Displacement mode” provides two options: “Auto” and “Range”.

With “Auto”, a maximum displacement height is determined for each frame a 16-bit map and the other corresponding height values will be related to this maximum. That’s certainly a convenient method, but can lead to some unwanted noise. because the mentioned maximum height might change with each frame. To avoid this phenomenon, “Range” can be used. Here it’s possible to specify a fixed height that’s valid for all frames and the pixels are calculated accordingly.

@ range With “Displacement mode” set to “Range” you’re able to limit the creation of displacement maps to a certain height, valid for all frames.

Displacement format This parameter determines which axis will be considered while creating the displacement maps. The result is a colour-coded 16-bit TIF-RGB picture (colour depth depends on the used format). By default all three axes, “XYZ”, are used to write the map. With the second option only the height information is used. This mode is called “YYY”.

Damping factorRealWave allows you to define static areas where no wave motion takes place. These zones act like islands and are defined by a selection of mesh vertices. Once they’re selected and recognized as static points they appear red. “Damping factor” has influence on waves interacting with these static points. With 0.0 all waves are reflected and the points act like a solid wall. With values greater than 0.0 the waves still interact with the static points, but loose some energy after a while (depends on “Damping factor”) until they disappear.

Autogen static“Autogen static” can be used to create reflecting and refracting waves around a moving object. When this function is set to “Yes” it creates a static zone inside the object that is constantly updated to represent the body’s position changes.

DownstreamSometimes it’s necessary to simulate river-like surfaces or strong streams. For these cases RealWave offers the “Downstream” option.

In some cases it’s necessary to raise wave height or change “Water friction” from the object’s “Realwave” panel to make the object move at all. With additional modifiers new forces are introduced with the motion of the waves. These motions may “overwrite” the downstream force. In this case you have to raise the downstream value. If the floating object sinks, “@ mass” from the rigid body menu must be altered. Alternatively you can also use the “Balanced mass” button.

Stream angleThe direction of the downstream force can be adjusted under “Stream angle”. This value accepts settings given in degrees.

Calculate textureThis is the global switch to activate RealWave’s foam map engine and also unlocks a series of parameters for controlling the texture’s final look. Unless this option hasn’t been set to “Yes” foam textures cannot be calculated. Another important issue is to activate foam



Introduction | 207

textures under Export Central (see page 55) or the files won’t be written to disk. With an object’s or emitter’s “Texture strength” setting it’s possible to control their contribution to the maps.

@ resolutionBy default the texture size is 64 x 64 pixels. To change this value simply add the new desired value. Please keep in mind that very large texture maps require more time to be created and stored. Since foam maps always require a certain amount of post-processing, “@ resolution” normally doesn’t need very high values, because you can enlarge the maps later and blur the foam marks.

@ diffusionInstead of blurring the foam marks in a post process you can also apply a blurring filter during the creation of the maps. “@ diffusion” blends the individual spots and cares for a smoother appearance. But please note that very high values can lead to unrealistic results and may increase simulation time.

@ diffusion = 0.0 @ diffusion = 0.5 @ diffusion = 1.0

@ dissipationThe life-span of foam strongly depends on the weather and the environmental conditions. During storms foam normally stays much longer than under breezy conditions. Waves, breaking against rocks and cliffs also produce rather long lasting areas of foam. To simulate this behaviour “@ dissipation” can be adjusted. Higher values make the foam marks disappear faster. With 0.0 the foam will never vanish.

Depth factorYou can either enter a fixed value, valid for the static points of the entire mesh, or load a texture to create customized patterns. To grab an image, right-click on the parameter and choose “Load texture” from the context menu. This action opens a new window where you can load and process yur images. The patterns on the depth map are translated into static points and act like obstacles or islands. Waves can be reflected and refracted at the borders of the static points and create the impression of wave-shore interaction.

Particle layerAs already mentioned in the introduction to RealWave on page 201, this option bounds particles to the vertices and polygons of a mesh. These particles will also follow the waves and cannot become detached from the wave surface. “Particle layer” is used to connect the particles from emitters with RealWave surfaces. Of course it’s possible to store the particle layer into a BIN file and reuse it with a Binary loader, for example (see page 112). That’s a very handy method to combine particles from different sources for meshing, retiming or other enhancements.

RealWave “Particle layer”. Mesh from a particle layer with activated shader.

EDIT StaticThis is another mode that makes it possible to edit a RealWave mesh. With this option you can define any of the surface’s points as static. These points are not affected by waves and remain immobile while waves can be reflected at their borders. Multiple selection is possible by holding the Shift key pressed during selection. Static points appear red, as you can see on the following page. Static points are also influenced by “Depth factor”.



Introduction | 208

Modifiers also contain a wide variety of different settings to achieve a realistic look and adjust the waves to your own specific needs. Of course, it’s also possible to generate foam maps with each modifier individually or in combination. Another very important feature is full interaction with moving, travelling, or floating objects. These bodies can also contribute to the surface and disturb the waves created by the modifiers. Particles are also taken into account while working with modifiers, as well as depth maps or static points.Each modifier has its own set of parameters and they strongly differ from each other. With “Spectrum” you can even choose from three different types, creating new looks.

a. common settings

There are two parameters valid for all modifier types, regardless of their built-in set of formulas and functionality. These settings are only explained once here:

ActiveYou can choose between “Yes” and “No”. The active switch is normally only needed with more than one modifier or other sources of wave creation, e.g. travelling objects. Under such circumstances you can disable the appropriate modifier and evaluate the underlying wave structure for fine-tuning. Active is common to all modifier types.

WeightAnother common parameter for all available wave types. With “Weight” it’s possible to define a kind of mixing strength. By default, each set of waves contributes to the final result at equal strength and weight. To reduce the influence of a certain modifier, simply decrease its weight. The range starts with 0.0, while 1.0 stands for 100%.

b. The object Interaction Global settings Modifier

Whenever you apply a RealWave node, there’ll be this default modifier. It governs the interplay between wave surfaces and other RealFlow nodes.

Rows with static points on a RealWave surface.

CLEAR StaticThis button is only available with activated EDIT Static mode. It simply removes all static points from the mesh.

14.04 RealWave ModifiersA modifier is a convenient and easy method to create different kinds of waves. The strengths of these prebuilt functions are speed and the almost unlimited combinations. It’s possible to combine “Fractal” with “Spectrum” types, “Statistical Sprectrum” waves with “Control Point”, or “Fractal” with “Gerstner” waves. The different types cannot only be combined, but also weighted: just mix 50% “Statistical Spectrum” waves, with 70% “Fractal” and add 25% “Control Points” for a completely new look.



Introduction | 209

u “Active” and “Weight” are valid for all modifiers and explained once on page 208.

Max heightEach object can contribute to wave creation this parameter sets the maximum height of the generated waves. RealFlow automatically suggests a value, but you should consider changing it anyway. “Max height” should match the scene’s elements.

Wave speedThe waves that are generated from impacting or moving objects always have a certain speed, controlled with this value. Very fast waves may cause instabilities, like unwanted patterns, peaks, or chaotic structures. In this case, either reduce “Wave speed” or increase the RealWave’s polygon size. Similar to “Max height”, this parameter should also match the object’s physical parameters.

Wave DampingWithout damping, waves would travel forever. In reality waves always have a certain amount of damping causing a loss of energy. With this value it’s possible to control the propagation of the waves over the surface and the moment when they completely disappear. Higher values reduce the life-span of the waves.

Depth effectObjects that travel below a RealWave surface can still influence it and create a more or less clearly visible bulge. Emerging objects are also able to produce such a displacement of the surface, indicating that the object is about to pass the surface.

c. The control points Modifier

With this type you have full control over the origin of your waves and the number of wave generators. You can choose as many control points as desired from the RealWave mesh.

Each of these points will then act like an oscillator. In other words: the points perform an up-and-down movement according to the adjusted parameters. It’s even possible to define different start times for the oscillation of the points to create a diversified and interesting surface. With Control Points you can achieve very complex patterns. The process of selecting the points is fairly easy. You simply turn on the the edit mode (“EDIT CP”) and choose the desired number of points. The selected vertices appear green. Now simply hit simulate and watch...

u “Active” and “Weight” are valid for all modifiers and therefore only explained once on page 208.

FrequencyFrequency is a term from physics and describes the number of oscillations per second and is measured in Hertz [ Hz ]. With growing frequency the waves carry more and more energy. In RealWave this parameter controls the number of up and down movements of the control points. Higher values produce more waves with less distance in-between, but exaggerated settings can also lead to reduced stability. You can also create interference effects by choosing several areas of equal “Frequency” and “Amplitude”. When these waves collide, they become cancelled. An illustration of this effect can be seen on the next page.

AmplitudeThis is another parameter from physics and describes the distance between the highest and the lowest point of an oscillation. Some books define it as the distance between the highest or lowest point and the wave’s baseline. In connection with the “Control Points” modifier, “Amplitude” is the maximum elongation (or "height") of the points.



Introduction | 210

EDIT CPWhen you click on this button, RealWave switches into edit mode and lets you select the desired number of control points, which are actually the mesh’s vertices. A selection is always rectangular, but with a pressed Shift key you can add more points to your current choice.

Control point selecttion and the beginning of a simulation.

CLEAR CPIf you’re not happy with your current selection or don’t need it anymore, use “CLEAR CP”.

d. The Fractal Modifier

This is certainly the most commonly used modifier. It provides a typical noisy surface with bumps and dents, and an underlying base oscillation of the entire surface. Stretching factors can be used to create wavefronts indicating the travelling direction. The fractal surface can be simulated very fast and is perfectly suited as a basic structure for other, overlapping waves to create more details.


HeightThis parameter is responsible for the maximum height of the enitre surface, while the height of the smaller ripples are controlled with “Slope”. It could also be seen as base height, because the vertical height of the smaller waves and ripples are controlled with the slope value.

Interference effects with colliding waves.

Begin timeYou’ll be able to exactly define the time in seconds when the points should start oscillating. This is especially useful with more than one control point modifier. You could start with wave generation at different times and create interesting interactions.

CyclesThis is the amount of up and down movements. The total number of movements (n) is calculated with this simple formula:

n = Cycles • Frequency

Wave speedThe waves will have some initial speed once they’re created. Wave speed is the other measure for the wave’s energy. With activated damping, higher and faster waves will travel longer and not vanish so fast.

DampingWithout damping a wave would travel for ever, regardless from the initial amount of energy. Under real conditions, water waves will always lose their energy. This results in waves, becoming flat and slower over time until they completely vanish. “Damping” controls how fast the waves disappear. With strong or undamped waves, they become reflected at the RealWave mesh’s borders, creating more structures and ripples. For a realistic appearance, waves should always have at least a small amount of “Damping”.



Introduction | 211

AngleHere it’s possible to determine the waves’ travelling direction. You can create interesting effects in combination with other modifiers by using slightly different angles.

OctavesTo create more details on the wave surface, octaves should be raised. It could also be seen as the fractal’s frequency. Higher frequencies lead to a more complex fractal and therefore you can create waves. With values above 10 to 12 you’ll hardly notice any change of the surface’s structure. Denser meshes show more structures.

SlopeAs mentioned under “Height”, this value is responsible for the vertical height of the surface waves generated with “Slope”. Try to avoid exaggerated values, because they mostly look unnatural. For very large ocean surfaces, “Slope” should range between 1.0 and 3.0.

Octaves = 8, Slope = 4.0 Octaves = 8, Slope = 7.0

Fractal speedA wave always travels along the surface at a certain velocity. This speed can be adjusted here and should always be in relation to scale, environment, objects on or around the surface, the viewer’s distance and the RealWave node’s dimensions. In combination with other modifiers fast waves might lead to instabilities. In this case either create a wider mesh or reduce “Fractal speed”.

Fractal scale X/YWaves can be stretched in both horizontal directions. Stretched waves create a better impression of larger water surfaces and often give you a much more realistic look. Stretched waves should be more or less perpendicular to the waves’ travelling direction.

SeedFractals always need starting values to create the wave structures. By changing “Seed” you’re able to change the initial look of your surface. With different seed values it’s possible to place the waves at different locations. Seed accepts any positive or negative integer value.

e. The spectrum Modifier

Spectrum is a very versatile modifier to create very different waves. For this purpose you can choose from three different subtypes which are all ruled by the same set parameters: “Sinusoidal”, “Asymmetric”, and “Sharp”. The waves are created within a certain range of frequencies, defined by “Min. freq.” and “Max. freq.”. These parameters are very sensitive and even smallest changes can produce a completely different result. Spectrum types are mostly used as an underlying base wave to get a better behaviour and a more convincing appearance.

Spectrum waves can be very fast and therefore it’s often necessary to slow down their movement. Since there’s no wave speed setting with this type, you have to use higher “FPS output” settings of up to 150 or even 200, while playback is done using the standard frame rate of the used TV or cinematic system, e.g. 30 for NTSC or 24 for HDTV. If you want to use spectrum waves in combination with different modifiers and high “FPS output” values, also consider adjusting the other modifier’s speed setting.

“Sharp” waves, in particular, are not always easy to adjust and usually require some testing. With very large surfaces, spectrum waves tend to produce regular patterns.



Introduction | 212

They’re more suitable for small or mid-ranged scenes. Please note that “Sharp” spectrum waves always have a negative vertical offset at the beginning of the simulation – that’s important to bear in mind when you’re applying crest emitters.


ShapeAs already mentioned in the introduction you can choose from three different types:

“Sinusoidal” uses standard sine functions in horizontal directions to create a regular pattern. This is most useful for an underlying base wave in combination with other modifiers.

“Asymmetric” generates a more realistic surface without regular structures and provides waves of varied heights and widths. This type is also ideal for combinations with the Fractal modifier to get a more differentiated look.

“Sharp” produces waves with sharp crests, similar to Statistical Spectrum waves but based on other rules. Nevertheless it’s possible to achieve very realistic cresting waves with this modifier, though without the typical motion patterns of statistical waves.

Shape = Sinusoidal Shape = Asymmetric Shape = Sharp

Min. frec.This is this minimum frequency of the waves. There should be at least a difference of 0.1 samples between “Min. frec.” and “Max. frec.” to achieve reasonable results.

Max. frec.To change the maximum frequency of the wave spectrum change this value. The waves’ samples are created from the range between “Min. freq.” and “Max. freq.” With values around 2.0 and above it might be possible that regular patterns appear on the surface. In this case simply reduce this setting.

SamplesThis is the number of waves or samples that will be generated from the given frequency range. To achieve wider gaps between the wave crests, reduce “Samples”. For more waves, raise it.

V scaleChange and adjust the vertical height of the waves with this parameter. For a more realistic look avoid very high values. “V scale” is a rather sensitive value, so try to change it in relatively small steps.

V scale = 0.2 (“Sharp”) V scale = 0.5 (“Sharp”)

AngleDetermine the origin and the direction of the waves with this setting. Please be careful with “Angle” and sharp waves. Changes often yield a completely different look, because the sharp crests are influenced by the waves’ direction.



Introduction | 213

f. The scripted Modifier

With this modifier it’s possible to create your own waves based on Python scripting. Of course, this process requires knowledge of Python and the appropriate functions provided by RealFlow. Once you’re a little familiar with this scripting language you can write your programs to displace the hexamesh vertices according to your needs.

Please note that in RealFlow 5 there has been a major enhancement in this feature: vertices can now be manipulated in all directions. Vertical horizontal displacement is possible and therefore you’ll be able to create breaking or convex waves with appropriate scripts or plug-ins. If you’re not familiar with programming tools, we recommend that you use the new grid fluid solver (see page 65) for breaking waves.


EditA click on this button opens an extra scripting window. This window contains a few comments, introduced by a “#” symbol, and an empty function for updating the surface’s vertices. This part can be filled with your script and RealFlow will execute the instructions to create the desired waves.

g. The RWc sequence Modifier

This new modifier loads a previously simulated sequence of RWC files from the disk and applies it to a RealWave surface. An important difference to RWC is that SD files store the entire simulation within a single file, while RWC files are written per frame. With earlier versions of RealFlow this was a problem, because of the 2 GB limit for SD files, but this limit does no longer exist. Actually, RWC Sequence is not a traditional modifier, it works like the Binary Loader (see page 112), which is capable of importing pre-simulated BIN particle sequences.


RWC Sequence When you click on the hyphen, RealFlow opens the well-known file picker for you to choose a series of RWC files from any location on your hard disk drive.

Mode You can choose from three different modes: “Normal” simply plays back the sequence from the first to the last frame. You can limit the range by entering appropriate values for the first and the last frame in the timeline. “Loop” jumps back to the very first frame after the end has been reached and “PingPong” plays the sequence back and forth.

Reverse You also have the possibility to start with the last frame for playback.

Number of frames This field tells you how many RWC files were found and applied to the RealWave mesh.

Frame Offset If you want to start playback a little later you can specify the desired frame here. Please note that this value does not truncate any frames – it just shifts the beginning frame.

h. The Gerstner Modifier

Franz Joseph von Gersnter (1756-1832), a mathematician from Bohemia, invented a theory about the creation of waves based on simple trigonometric functions. The theory assumes a circle-shaped movement of waves, creating a sharp wave with a certain wavelength



Introduction | 214

and amplitude: a trochoid-shaped wave. With small amplitudes the result is very close to a sine curve, but higher amplitudes create sharper waves and clearly visible crests. The modifier’s source-code can also be found under RealFlow’s “plugin” folder.

AmpWave = 0.25, LengthWave = 2.0 AmpWave = 0.4, LengthWave = 4.0

Since “Gerstner” waves are based on simple functions like sine and cosine, which are summed up over the entire number of mesh vertices, this type is calculated very fast. The disadvantage is the rather uniform look of the waves, so the “Gerstner” modifier is better suited as an underlying displacement for more complex setups.


Dir Wave To change the wave’s direction, enter a value in degrees.

AmpWave You can adjust the wave’s height with this setting. It’s a very sensitive parameter and values of around 0.4 will create intersecting “loops”, showing you the trochoids, mentioned

in the introduction. Higher settings create “sharper” waves with more distinctive crests, but this is also dependent on “LengthWave”.

LengthWave This is simply the distance between the wave crests. Lower values create a denser sequence of waves, while larger ones give you wider gaps.

SpeedHere you can adjust the waves' velocity.

i. The statistical spectrum Modifier

This is also an entirely new wave type in RealFlow 5 and probably the most realistic one. With this modifier you’re now able to create believable ocean surfaces with cresting waves based on statistical methods. “Statistical Spectrum” takes various environmental parameters into account, such as water depth or the surface’s dimensions. The result is an absolutely convincing ocean surface with natural wave behaviour and a customizable amount of “choppiness”. This value is responsible for the degree of sharpness of the waves. Waves can now range from slightly round to distinctly sharp.

With “Resolution” and “Dimension” you can even adjust the level of detail:

Level of detail [ m ] = Dimension [ m ] : Resolution

An example: Let’s assume you have created a surface with a “Resolution” of 1024 and a “Dimension” of 400 m. The smallest structures you can observe on this ocean have a size of 0.39 m according to the formula above:

400 m (Dimension) : 1024 (Resolution) = 0.39 m

If you need even more detail and smaller structures, you can either raise “Resolution” or lower “Dimensions”. With higher “Resolution”, RealWave needs more time to calculate the surface. Statistical waves are characterized by a typical “back and forth” movement. At the collision points of these motions, the crests appear.

“Statistical Spectrum” waves are not only available with RealWave; they’re also implemented



Introduction | 215

in RealFlow’s new grid fluid solver. There you can add a custom amount of displacement to the final mesh and you’ll find many similar parameters. You can read more about the statistical displacement features for grid fluids on page 73.


QualityBesides from the mesh’s polygon size this is the most critical parameter in terms of simulation time. You can choose from 6 different levels: 256, 512, 1024, 2048, 4096 and 8192. With each level simulation time will drastically increase but, as shown in the previously given formula, you can create much finer structures.

DepthThis parameter affects the dispersion of the waves and is only noticed if the length of the wave is close to the value of the depth. In these cases this parameter has a decelerating effect on the dispersion of the wave. In most cases you won’t see any effects or changes, because the depth used is normally rather high compared to the length of the waves.

Vertical ScaleTo alter the height of the statistical waves, “Vertical Scale” is used. You normally have to adjust this parameter when you’re changing the surface’s dimension value. “Vertical Scale” has a strong influence on the credibility of the entire simulation and can also be used for the creation of heavy storms with high waves.

Dimension“Dimension” is closely linked to “Quality” as described before. By changing “Dimension”,

while keeping “Quality” untouched, you can achieve a zooming effect. To keep the relations between “Dimension”, “Quality” and objects you’ll probably have to adjust “Vertical Scale”.

Wind SpeedThis option introduces a wind force that directly influences the waves. The magnitude of this force is measured in meter per second [ m/s ].

Wind directionTo change the origin and direction of the waves this parameter is needed.

Min Wave LengthWith “Min Wave Length” the amount of detail on the surface can be controlled. Higher values flatten the surface and create fewer ripples. Please keep in mind that this parameter is connected to “Dimension”. When you enter lower values for “Dimension”, you should also lower “Min Wave Length”, to guarantee that the RealWave object still shows enough structures.

Min Wave Length = 2.0, Dimension = 200, Min Wave Length = 0.01, Dimension = 200

Weight Against WindThis is a weighting parameter for waves which travelling direction has some component in the opposite direction of the wind. If “Weight Against Wind” is 0.0 then all waves against the wind are eliminated. If it’s set to 1.0 then its normal strength is used. Values between determine the amount of waves to be eliminated.

ChoppinessOne of the main features of statistical waves is the possibility of creating sharp crests for the waves. This parameter directly influences the sharpness of the waves. Values closer



Introduction | 216

to 0 will produce “rounder” waves. Be careful with high values, because the horizontal displacement of the waves can be so strong that inner polygons may turn to the outside. This creates intersections and an unwanted look. “Choppiness” strongly depends on “Vertical Scale” and “Dimension”.

j. The object Interaction Modifier

As mentioned earlier, a RealWave node always carries an “Object interaction global” modifier for use with other bodies. Since this default attachment acts globally for all objects, this modifier has been introduced to perform settings on a local level. To make use of it, you have to go to the object’s Realwave panel and change “Interaction Wave” to the desired modifier:

Object > Node Params > Realwave > Interaction Wave > Object interaction[nn]

u Settings are exactly the same as described on page 208, “Object Interaction Global Settings”.

14.05 RealWave emittersRealFlow provides two exclusive particle emitters to use with RealWave surfaces. In nature you can observe fine water droplets created from wave crests or interactions between the water surface and objects, for example after impacts. The RealWave specific emitters are able to mimic these phenomena, but on a completely different background from the new grid fluid emitters. When you’re using RealWave you’re dealing with polygons, while grid fluids are based on cells which become filled with particles. That’s why the results usually appear completely different. Nevertheless it’s possible to achieve a seamless connection

between RealWave’s polygons and the associated particles: particle layers and meshing. A RealWave surface can be translated into a particle cloud (see page 203/204) and these particles stuck to the wave node’s polygons and vertices – another difference to grid fluid particles. Such a particle layer can be used to create meshes in combination with Object Splash and Crest Splash emitters.

a. object splash

The Object Splash emitter is a fully featured emitter that only works in combination with a RealWave object. Another requirement is an object to interact with the wave surface. From the moment the selected objects react with the RealWave mesh, the emitter starts creating particles from the interacting polygons, resulting in a splash-like particle cloud. The amount of emitted particles strongly depends on factors like number of polygons, velocity, entrance angle, object mass, and of course resolution. Therefore it’s hard to predict how the final splash will turn out.

Object Splash introduces two different panels to adjust a wide range of parameters. The first panel concerns the interaction of the splash particles with the object; the other affects the process of particle creation. The RW Particle Interaction panel is available for any standard particle emitter panel and will only be accessible when a RealWave surface exists and an interaction (Global Links/Exclusive Links, see page 24) with the emitter and the RealWave object has been established.

u Please visit page 68 for a detailed description about Node, Initial State, Particles, Statistics and Display panels.



Introduction | 217

The RW particle Interaction panel

This is the place to adjust the particles’ behaviour when they hit the surface or sink below it. RW Particle Interaction is also responsible for secondary waves created by a particle’s force. These ripples can be seen in the last of the images above. Whenever you’re working with splash or crest particles, you should pay special attention to this panel, because it greatly enhances a simulation’s credibility.

Upward forceParticles below the water surface always try to move in the direction of the surface and counteract gravity. This tendency can be adjusted with “Upward force”.

Destroy on depthParticles that reach the entered depth will be deleted and removed from the scene. This value strongly depends on the wave modifier you use and the final wave height.

On surfaceYou can choose from three options: “No interact”, “Destroy” and “Place”. “No interact” makes the particle fall through the RealWave surface – there they can be deleted with a

k Volume daemon, for example. “Destroy” automatically removes the particles when they hit the surface, and with “Place” they float on the surface. With “Place”, particles might accumulate between the wave crests and should be deleted with a k Age daemon.

@ FrictionThis parameter is only available when "On surface" is set to "Place". You can adjust the particles' friction to make them stay closer to the object for a longer time.

Split“Split” will break the particles apart to create child particles. Once it is set to “Yes”, you’ll have access to “@ # child”. “Split” can create huge amounts of spray, foam and splash particles, so please mind your “Max particles” settings.

@ # childHere you can determine the number of children that will be generated from each particle when “Split” is set to “Yes”.

Hit forceEach particle has a certain mass that’s capable of influencing the RealWave surface. This mass generates a force that creates little ripples and secondary waves. If you need stronger ripples, you don’t have to change the fluid’s density (which would lead to a completely different fluid behaviour); simply raise “Hit force” and boost this effect. Depending on size, level of detail and environmental conditions, it’s sometimes better to deactivate “Hit force”. Large “Hit force” settings in combination with high “@ Wave speed” values can lead to unwanted high-frequency patterns.

Propagation of high-frequency patterns on a RealWave surface



Introduction | 218

Hit levelsWith values larger than 0, RealFlow analyzes the neighbour of the affected vertices of the RealWave surface and disturbs these points. This mode can be seen as a "radius of action", and it's a recursive operation. With a value of 2, for example, the neighbours of the already considered vertices will be disturbed as well. This means that high values will A) slow down the simulation and B) affect very large parts of the wave surface leading to an unnatural look. Therefore "Hit levels" should not be greater than 5.

Hit levels = 0 Hit levels = 5

@ Max heightSince particles can create ripples and secondary waves, it’s sometimes necessary to restrict the height of these waves to avoid unrealistic behaviour. Imagine an ocean surface where tiny drops produce huge waves. That’s an example where relations are shifted and the effect is completely overdone.

@ Wave speedThe travelling speed of the secondary ripples can be restricted with this parameter. High velocities can also lead to unwanted spikes and high-frequency effects which spoil the entire wave.

@ Wave dampingTo prevent the particle-induced waves from endless propagation, we recommend you to limit their life-span. With “@ Wave damping” you can make them disappear smoothly and create a much more realistic behaviour.

@ Depth effectAn object can disturb the surface and create waves not only when it crosses the surface, but also below it. As in real life, a submarine can create waves when travelling below the surface at a shallow depth. This parameter sets the depth limit at which any object will affect the surface.

Texture strengthIf you can hardly see the particle marks on a foam texture, we advise you to either raise this value and/or the emitter’s “Resolution” parameter. To achieve a less distinctive effect, values smaller than 1 should be considered.

The RW_object_splash panel

Wave behaviour is described with the RW Particle Interaction panel, and the splashes are adjusted here. Typical settings concern involved objects and splash strength. Object splashes depend on many parameters and it sometimes requires a little patience to achieve optimal results.



Introduction | 219

Objects As usual you can choose one or even more objects from a node picker to attach them to the splash emitter. If you need control over the individual splashes then it’s recommended to use one emitter per object.

Waterline multThis setting is used to increase the number of created particles. It’s closely related to he emitter’s “Resolution” parameter and ranges from 0 to 1. 0 disables the waterline emission, while 1 is used to maximize it.

@ WidthExperienced RealFlow users will certainly know that it used to be hard to create a sufficient amount of liquid-type particles around an object hitting a RealWave surface. Liquid-type particles can only be created at specific positions to keep the fluid stable. For better control, this parameter has been introduced in RealFlow 5. “@ Width” controls the area around the object from where the particles will be emitted. It works in world units – a value of 1.0 means that particles will be created in an area of 1 metre around the object.

@ Width = 0.1 @ Width = 0.5 @ Width = 1.0

@ H/V strength These values can be seen as multipliers to enhance the splash. You can define values for the horizontal and the vertical emission separately. The range of these parameters is not limited and you can enter any value, but exaggerated settings should be avoided. Higher values will produce faster velocities in horizontal or vertical directions. A value of 0.0 for “@ H strength” may produce a perfect vertical emission, depending on the “@ V strength” value – and it’s vice versa with 0.0 for “@ V strength”.

@ Side emissionThis option modifies the angle and strength of the emitting particles along the normal direction. Higher values are required to create wide-angle particle emissions around the object.

@ Normal speedWith this parameter you can modify the speed of the particles when they are launched from the waterline.

Underwater multThis setting works like “Waterline mult”, but the particles are emitted from polygons below the RealWave surface. This is great for creating particle trails from emerging objects or vehicles that move underwater, e.g. submarines. The range is between 0 and 1, where 0 disables the creation of particles.

@ Depth thresholdWhen you activate “Underwater mult” this setting becomes accessible. Particles are only created between the RealWave mesh and the specified “Depth threshold” value. “@ Depth threshold” must always be positive.

Speed multAnother multiplier to influence the emitted particles. Each particle has a certain velocity at the time of creation. This speed will be multiplied with the entered valued to create more impressive, faster, and higher splashes. Very high values might lead to exploding particles and unnatural results, but with moderate changes it’s possible to fine-tune a splash.



Introduction | 220

Parent Obj SpeedThe object that’s used to create the splash also has a certain velocity at the time of impact. A value of 0.0 won’t add any velocity to the particles. A value of 1.0 will add the full velocity of the object.

Speed thresholdParticles will only be created when the speed of the object at that point is above the threshold. This option is useful to avoid particle creation at low velocities.

Speed variationThis is a random value that affects the velocity direction of all the particles being emitted.

Drying speedThe perturbing points of the attached object contain a wet/dry value that is updated when the object interacts with the water surface. When the point is below the water surface, it’s considered “wet” and particle emission is allowed. “Drying speed” controls the transition speed from wet to dry when the object has come above the water surface. This is useful for creating the typical splashes of objects emerging from a water surface which continue to launch particles for a while. This is often observed with large objects, for example ships.

b. crest splash

Crest Splash emitters are the perfect solution for emitting large amounts of spray on a RealWave surface. The various options allow you to launch particles depending on a wave’s height to achieve cresting effects or drifting foam particles. The particles can even be used to create foam maps that can be projected onto the RealWave surface.

It’s better to use dumb particles with this emitter to speed up the simulation, Since the Crest Splash emitter is mostly used to mimic foam and spray, it’s fine to use dumb-type particles. Additionally it’s always a good idea to destroy the particles after a certain time or when they leave the RealWave surface. The Crest Splash emitter can be used for many purposes, such as white caps and spray on wave crests, so you normally need large amounts of particles. You’ll often spawn several million particles during an entire simulation process, but this also strongly depends on the RealWave mesh resolution. So don’t forget to adjust “Max particles” from the Particles panel.

u As mentioned earlier, the Crest Splash emitter also has RW Particle Interaction settings. They completely match the settings described with Object Splash. For more information and details, please visit page 217.

The RW_crest_splash panel

The settings found here, are used to determine the circumstances and environmental conditions, in which crest particles will be created. Some of them react rather sensitively.

Choppiness for emissionWhen this parameter is set to 0.0, only the height and velocity information of a wave will be used for the creation of crest particles. Raising it to values greater than 0.0 will add a new component, based on the “sharpness” of the waves. Please note that this is a very sensitive parameter and also requires a certain amount of crests. If you can’t see any particles, either try enhancing choppiness, or start with 0.0 and slightly raise the value.



Introduction | 221

The images show a statistical spectrum wave with settings of 0.05 and 0.3. In the second case, particles are only created on the highest tops of the waves. “Choppiness for emission” works with any modifier.

SpeedThis value controls the emission rate together with resolution. Higher settings will create more and of course faster particles.

Speed variationA great option to avoid patterns. Due to the regular polygon structure of a RealWave mesh, patterns often occur during creation time. Adding some randomness to “Speed” helps to suppress these artefacts.

Height for emissionHere you can trigger the emission of particles. Please note that particles are only created above this value. It strongly depends on the used surface modifier and the final height of the waves. The parameter can be used to create spray on wave crests.

Speed for emissionThe surface waves also travel at a certain speed and this velocity can be used to trigger the creation of particles. If the surface’s speed is above this particular value, particles will be emitted.

14.06 a RealWave scene (Tutorial)

The interaction between RealWave surfaces and rigid bodies is a very good example of the interplay of different forces. RealFlow's capability to combine forces and motion from its various dynamics solver can be used to achieve complex interactions and feedback. In this tutorial, a 3D model of a buoy will be influenced by the forces of waves. For the ocean surface, a Statistical Spectrum modifier will be applied and combined with a fractal wave. In a second step, a 3D model of a buoy will be added, and finally a MultiJoint node will be used to control the buoy's behaviour and motion.

a. adding and adjusting Modifiers

Combining different RealWave modifiers is a very easy task, but there are few things to consider to achieve realistic behaviour. The most important values for a credible ocean simulation are scale and wave speed. Both properties must be in relation to each other, because with very fast waves, the surface gives you the impression of shallow water, for example near a shore. On the open sea, wind moves huge water masses and the water reacts a little sluggishly. In relation to the ocean's scale, the waves appear rather slow.

First of all, a RealWave is needed. It can be added from the Nodes Bar or the Menu Bar:

Edit > Add > RealWave > Surface

The node you can see now is a flat, triangulated mesh with a size of 5 x 5 units. If you hit simulate now, nothing would happen, because there's currently no information about wave height, speed or wave length. All these properties have to be added separately with a modifier. To add a modifier, please follow these steps:

RealWave01 > Right-click > Add Wave > Statistical Spectrum

To get a bigger ocean surface with enough room to place a camera and catch larger parts of the wavy ocean, the mesh's dimensions will be scaled to 15 x 15 units. Please note that, depending on your axis setup, you either have to modify the node's Y or Z scale parameter. Now, the wave modifier settings will be adjusted. The goal with this scene is an ocean with cresting waves and a lot of turbulence and detail. To find out the required settings, it's a good idea to have a look at the surface with RealFlow's default values.



Introduction | 222

A RealWave mesh with a default statistical spectrum modifier.

The waves could be slightly sharper and have a little more velocity. While the amount of waves is sufficient, the surface seems to lack fine details. Details can be added easily by increasing the mesh's “Polygon size” value. Of course, the files will contain much more data now, but that's the price of a better resolution. For a comparison, adjust “Polygon size” to:

RealWave01 > Node Params > Realwave > Polygon size > 0.07

Hit the “Reset” button and you will now be able to see a highly detailed surface with lots of fine ripples. The modifier's “Quality” level can also help to create more structures, but greatly increases simulation times. Additionally, “Quality” also influences the wave shapes, so with each new setting you'll see a completely different surface.

StatisticalSpectrum01 > Node Params > Statistical Spectrum > Quality > 512

To achieve a more realistic view, turn the viewport's shading mode to “Smooth” by pressing the 0 key. Now you have an impression of how a final render would look. The crests are rounded and some details are lost. To enhance the surface, you could reduce “Polygon size” and increase “Choppiness”. Both values should only be modified within small ranges, since they're very sensitive. “Choppiness”, in particular, could create unwanted effects, such as intersecting polygons on top of the waves. In this case, between 0.9 and 1.1 should work. If you can see intersecting waves crest polygons, please use a value of 1.05, for example. With the viewport's “Smooth” shading mode it's possible to get a realistic

idea of the final wave: if the waves look flat here, they will most probably do so in your 3D program. “Polygon size” can also be used to get more distinctive wave crests.

StatisticalSpectrum01 > Node Params > Statistical Spectrum > Choppiness > 1.05

The next setting affects the waves' velocity - this parameter is controlled with the modifier's “Wind speed”. The waves should be relatively fast, but you have to consider wave height and dimensions. A value of around 100 appears realistic here, but you can also experiment with lower or higher settings.

So far, the results look pretty realistic, but it's now time to mix a fractal modifier to the existing surface. This addition will create an underlying wave with different wavelength, amplitude (=height) and velocity. The result is a much more realistic impression, because in nature, ocean waves are always a mixture of many different waves. The statistical spectrum modifier is already pretty close to nature, but cannot simulate the deep troughs between the wave crests. With the fractal modifier, this is no problem. Mixing waves is one of RealWave's greatest strengths and you can even determine the degree of this combination with the “Weight” parameter.



Introduction | 223

To add this modifier, please go to:

RealWave01 > Right-click > Add Wave > Fractal

As you can see under Node Params, the settings are completely different from the statistical spectrum modifier. For a first test, leave the default parameters untouched and simulate a few frames. For a direct comparison you can simply deactivate a modifier and run the simulation without it. This feature is great to control how a modifier influences the already existing surface:

RealWave modifier > Node Params > Modifier name > Active > No

The first thing is certainly speed. In relation to the statistical spectrum waves, the fractal waves appear too fast and “Speed” should be reduced to 0.4 – 0.3. Another thing that can be observed is that the waves' directions are not synchronized. The angles don't have to be exactly the same, but they should be similar, so a value of 42 degrees is fine. “Height” should also be decreased to a value of around 0.5. “Octaves” determines the “bumpiness” of a wave surface and “Slope” controls the height of these bumps. To get more ripples, “Octaves” will be set to 4, while “Slope” remains 1.0.

The final simulation is a believable simulation of an ocean surface with enough detail, ripples and waves. Also, the velocity matches the scene's dimensions and you can see a nice swelling sea. It's time to add the buoy model.

b. animating a Buoy

The buoy model, used here, is a highly detailed object from a 3D program, imported into RealFlow with the Ctrl + I (Win/Linux) or Cmd + I (OS X) command. The SD file should be located in the project's “objects” folder for easy access. It's very likely that you have to adjust the buoy's position, but imported objects are locked by default. To make it editable, choose:

Buoy > Node Params > Node > SD <-> Curve

For the initial position of the buoy, you can look for an interesting area with higher waves and place it there. Currently, the object is steady and the animation will be simulated using rigid body dynamics. To activate this feature, the appropriate property has to be enabled:

Buoy > Node Params > Node > Dynamics > Rigid body

To make the buoy node float and move, you have to activate its dynamic motion feature. Another important setting concerns the buoy's mesh shape: by default, this type is set to “Mesh”, but this can lead to unnecessarily long simulation times. For this scene, “Convex hull” is absolutely fine. You can find these settings under the buoy node's “Rigid body settings”.

A quality model of the buoy, used in this tutorial.

Your model will most likely sink and overturn, because the centre of gravity is probably too high. Both settings can be changed easily. The parameter that's responsible for making the buoy float is mass. The question is which value you have to add to make it float. Fortunately, RealFlow provides a button to adjust mass automatically, which is located under the Node Params “Realwave” panel: “Balanced mass”. When you press this button, RealFlow enters the correct mass value and the buoy won't sink anymore. If the buoy behaves like a cork, you should increase mass in moderate steps of 10 or 20 until you get the desired motion.

To prevent the buoy node from overturning, it's necessary to shift its centre of gravity in the direction of the negative height axis. This can be either the Y or the Z axis – depending on your preferences and the 3D software used. Values between -0.5 and -1.5 should be fine here, but if your objects can't be stabilized, you should consider values of -2.0 or more. It's also possible to visualize this particular point:



Introduction | 224

Buoy > Node Params > Rigid Body > @ CG > Y (Z) > -1.0

Buoy > Node Params > Display > Show CG > Yes

Now the buoy smoothly follows the motion of the surrounding waves. If you can see flickering waves near the buoy, it's necessary to reduce “Strength V” and “Strength H”. Both values determine how strongly the wave surface is influenced by an object. Setting them to values of around 0.3 should solve this problem. If you can still see this unwanted behaviour, then increase “Perturbation res” to avoid overly strong perturbations. Please keep in mind that “Perturbation res” works inversely, so higher settings reduce the amount of turbulence. A value between 0.3 and 0.5 should work in many cases. All the described parameters are attributes of the buoy's RealWave panel.

You might observe that the buoy is drifting. To avoid this it's possible to add a chain-like structure where the individual links are connected with a MultiJoint node and everything's linked to a ground object. On page 176 you can find a tutorial about how to work with MultiJoints.



Introduction | 225

15 IDoc

An IDOC is an acronym standing for “Independent Domain Of Computation”. If you look under the grid fluid icon, you can see a total of three emitters: “Splash per IDOC”, “Foam per IDOC” and “Mist per IDOC”. Another location for IDOCs can be found right to the RealWave icon. From this menu you can add IDOCs for both standard and grid fluids, and simulate them over your network. This method is perfectly suited for side-by-side comparisons, for example.

IDOC “fluids” cannot interact with each other and the particles become mixed

The idea behind IDOCs is that you can perform multiple simulations within a single scene, but on different machines. The most important aspect with this “object” class is that the emitters are calculated separately from each other. This means that RealFlow does not simulate interactions between the IDOCs, respectively the individual emitters!

15.01 The settingsLike any other of RealFlow’s nodes, IDOCs also have their own Node Params windows and panels to control visibility and other basic settings. Since they’re not physical nodes and are not meant to interact with items or particles, there’s only a basic set of parameters.

a. The Node panel

Settings under Node should already be pretty clear, because they’re common to all RealFlow nodes, except from slight differences. If you’re not familiar with these parameters, please go to page 86. There you’ll find detailed explanations.

b. The IDoc panel

Here you can find all necessary functions to start a network simulation. When everything’s adjusted correctly (“Job manager”), this job is actually just a one-click action.

UpdateThis button automatically attaches an emitter to its appropriate IDOC. RealFlow detects whether an emitter is inside an IDOC and directly establishes the required connection. Another method is to drag the emitter onto the IDOC node within the Nodes panel. The “Update” button is much faster for more than one domain, because it supports multi-selection and all emitter nodes can be added with a single click. That’s not only comfortable, but also makes sure that you cannot forget a domain!



Introduction | 226

Send to job managerBy clicking on this button, RealFlow appends the current IDOC to the Job Manager’s network queue. "Send to Job Manager" only considers the particular IDOC. To check whether it’s added correctly, just open the Job Manager from:

Menu Bar > Layout > Job Manager

c. The Display panel

In some cases it’s necessary to toggle a node’s visibility to get visual access to underlying objects or particles. Display helps you to manage viewport representation.

VisibleTo hide the currently selected node, choose “No” from the drop down menu. "Yes" makes it visible again.

TransparencyYes, even an IDOC node can be shaded and made to obey your settings under the View menu. With this parameter you can adjust the required amount of transparency. Higher settings create more transparency. The range goes from 0.0 to 1.0.

15.02 Working With IDocsAdding an IDOC node is the first step, but it’s actually nothing more than an empty container without a function. The real power of IDOCs is the Job Manager (see page 228), which finally splits the simulation into several computational domains and spreads them over your network. That’s even possible for a single emitter.

Imagine the following project:

You have created a scene with grid fluids and a ship, travelling along a given path. Now you’ve located a supporting standard particle emitter to create some neat splashes on board of the ship. The particles from the grid fluid and the particles from the standard emitter cannot interact, but they’re both located in the same scene. That’s a perfect situation for a single IDOC node. The grid fluid can be calculated on your main computer, while the standard fluid can be sent to a network machine, to be simulated in high resolution.

The creation of IDOCs is an easy task and you can either start with an IDOC or an emitter node. The IDOC is by default a cubic domain with a size of 1 x 1 x 1 units and it can be scaled like any other RealFlow object. The next step is the creation of an emitter. To be recognized, the emitter must be located inside an IDOC, though the exact position doesn’t play a role. It’s actually only important that the emitter’s viewport symbol lies within the appropriate box. Once this has been done, it’s time to connect the emitter to the desired IDOC – that’s just a drag and drop thing. Grab the emitter and drag it onto the appropriate IDOC. All this is done within the Nodes panel and that’s already all you have to do at this point. It’s even possible to attach multiple emitters to a single IDOC and these particle are able to interact. To add more domains, either repeat this process or directly use the following method for multiple IDOCs.

IDOC nodes without and with attached emitters.

Another convenient way of using more than one IDOC is to use the “Multiple” node. The workflow is slightly different, but still very user-friendly. Again, the three-emitter example is used. Instead of creating the domains one by one, “Multiple” can be used to create the desired number of domains in one pass. For this purpose, you should start with a cube object, for example. Resize the cube to enclose all available emitters, go to the Icon Bar



Introduction | 227

15.03 Grid Fluid IDocsThis is more a function than a class of nodes and was created to simplify the process of creating IDOC-based grid fluid emitters: “Splash per IDOC”, “Foam per IDOC” and “Mist per IDOC”. Before these functions can be used, a “Single” or “Multiple” IDOC node must already exist. By selecting one of the grid fluid IDOC emitters, RealFlow directly creates an appropriate emitter and attaches it to the IDOC bin. That’s actually the only difference to “normal” splash or foam emitters – there are no extra settings or features.

u Grid fluid IDOCs are also described on page 84.

and select “Multiple”. A dialogue will open, asking you how many subdivision RealFlow should add. Here, three IDOCs along the X axis are needed:

In the next step you’ll be asked which node you want to use to create the IDOCs. The result are three IDOC nodes, representing the boundaries of the cube exactly.

You’re not limited to cubes or box-shaped items – in fact you can use virtually any form, but RealFlow always calculates a bounding box around the supporting object to draw the IDOCs. Since the cube object isn’t needed anymore, you can delete it. If you’re not happy with RealFlow’s automatic setup you can still rescale and move everything.

Equal IDOCs generated from a cube node (semi-transparent)

Once you have subdivided both emitters and IDOCS, you can activate the Job Manager, append your job to the simulation queue with

[ Selected IDOC ] > Node Params > IDOC > Send to job manager

and start the network simulation. The following chapter tells you everything about this exciting feature.



Introduction | 228

16 RealFloW JoB MaNaGeR

This brand new tool allows you to use more than one computer for effective network simulations of so-called IDOCS. An IDOC is an “Independent Domain Of Computation”. If you have a look at the grid fluid icon, you can see a total of three nodes: “Splash per IDOC”, “Foam per IDOC” and “Mist per IDOC”. Another location for IDOCs can be found to the right of the RealWave icon. From this menu you can add IDOCs for standard particle fluids and simulate them over your network. The last method is perfectly suited for side-by-side comparisons, for example.

The idea behind this concept is that it’s not always necessary to simulate interactions between different particle sources, because such an interplay doesn’t always enhance realism or there is simply no interplay. One could say that these fluids are independent from each other and therefore it’s possible to spread their calculation over several machines

in a network. For this purpose, RealFlow 5 now offers a Job Manager to establish the connection between your network computers and monitor the progress.

u Please note that network simulations require appropriate licenses. You will need on Node license for each machine you wish to use for network simuation. If you only hold a Standard licenese for 1 computer, network simulations are unfortunately not possible. Please contact Next Limit’s Salesdesk for more information.

16.01 Getting startedFirst of all, it’s important to have a look at the different applications of RealFlow’s new network simulation feature:

1. Job Manager application 2. Job Node application3. Job Manager web interface4. Job Manager “CmdSendJob” plug-in

Before you start it’s important to determine which computer will be the manager, controlling the network simulation process, and which ones will be used as simulation nodes. Nodes will receive the data from the various IDOCs in your scene and simulate them independently. The Job Manager application doesn’t have to be installed on the fastest computer. The machine running the Job Manager can also serve as a node. You can even start more than one manager in a network, but this requires a few preconditions:

• The additional managers must not run on the same machine

• Nodes cannot be launched via the application icon or the batch script provided by Next Limit. In such a case, the nodes will start searching the network managers and they will bind themselves to the first manager responding to their requests.

• Nodes must be launched from a terminal application and bound to a specific IP, for example on a Windows PC: nl_job_node.exe -node:192.168.0.100

• Extra managers can share the same port, but this causes lots of messages during the binding process.



Introduction | 229

Both manager and node applications need IP addresses to be found within your network. Another requirement is the existence of open ports, used for manager-node communication. Additonally, there shouldn’t be more than one node per machine.

The web-interface is the manager application’s control centre and the place where you can add, remove or start network jobs. Everything you adjust in the web-interface will be sent to the manager application and then distributed to the various nodes. The Job Manager’s web-interface can either launched from any web browser or RealFlow’s built-in “Job Manager” window by entering the manager’s IP address together with its port, which is 8080 by default for HTTP services.

The last step is the “CmdSendJob” plug-in. This is used to trigger a network simulation manually and can be called individually for each IDOC. Then the plug-in writes out an RFS script file, containing simulation path and information, and an appropriate FLW file. To make use of the plug-in, it must be “installed” under Preferences and then you call it with the “Send to job manager” button.

Example settings for the Job Manager’s Preferences.

u The source code of the “CmdSendJob” plug-in is included with your RealFlow distribution as one of the examples for the Software Development Kit (SDK). It's a good example how to write your own commands to trigger certain events.

a. launching Manager and Nodes

Now it’s time to start everything. There are two ways of going about this. The most convenient method is to click on the aliases/applications included with your RealFlow distribution. Your other option is to use a terminal application or command line shell, similar to “RealFlow -nogui”. Using a shell is the proper method if you have to add flags to the node or manager applications. You can learn more about flags and how to use them directly below.

Under Windows operating systems browse to RealFlow’s program directory and enter:

prompt>nl_job_manager.exeprompt>nl_job_nodeexe

Linux needs these commands:

prompt> ./bin/nl_job_managerprompt> ./bin/nl_job_node

To open the manager and node applications under OS X, it’s necessary to browse to RealFlow’s program directory and double-click on the appropriate applications. Of course, you can add them to the Dock as well. If you have to launch the applications from a terminal, the commands look like this:

prompt>“Job Manager.app/Contents/MacOS/Job Manager”prompt>“Job Node.app/Contents/MacOS/Job Node”

When launched from a terminal, the manager application accepts a couple of flags. A flag is an extension that’s simply added to the command line to trigger actions or make certain settings. On the following page you can see a table with flags, accepted by the manager and the node.



Introduction | 230

Flag Action

-nogui Launches the manager or node in console mode.

-local The node is forced to use a local RealFlow Node license, instead of the License Manager.

-node:ip Binds a node to a specific IP. Here are some examples:

prompt> nl_job_manager.exe -nogui prompt> nl_job_node -local prompt> "./Job Node" -node:192.168.0.99

The node application has to be launched on each computer you want to run as a simulation node. If you have a larger number of computers, it’s a good idea to either add the programs to your startup items or write a script to activate them automatically. All actions have one thing in common: a new window is opened, giving you basic information about connections, available computers and server/node status.

Messages from the binding process the Job Manager canvas.

The next step is to specify the appropriate ports to make everything go together and run. If you’re not sure about open ports or cannot establish a connection between server and nodes, you should use a port scanner to detect closed ports and open them. Firewalls and Internet hardware often block specific ports, so in that case you have to define rules to make them usable. Please have a look at your appropriate manuals.

The manager/node settings can be found under:

Manager/Node application > File > Settings (Windows/Linux)

Manager/Node application > RealFlow Job Manager (Node) > Preferences (OS X)

Manager and node application preferences share the same layout.

To add the already given port 65454 (or whatever you can see in the Job Manager window) permanently, it’s necessary to change a few basic settings:

1. Under “Port Range” you can enter the “Binding port” you’ve seen in the manager’s server window (e.g. 65454) or any other available and open port with a number higher than 20,000. For “HTTP Port”, 8080 should be entered, because this is the default port for most web-based services. The last parameter specifies the “Maximum number of nodes connected”. Just enter an arbitrary number or leave the given value. The option “Start manager and node hidden in tray” opens both server and node, but without displaying the initial window. They’re just located in the tool bar or the Dock.



Introduction | 231

2. The other part is located directly within RealFlow:

Menu Bar > File (Windows/Linux) > Preferences > Job Manager Menu Bar > RealFlow (OS X) > Preferences > Job Manager

“Manager Location” requires the IP address of the manager application’s computer and “Port” is the same number you’ve entered under 1., for example 65454. “Apply path translation rules” is only needed for heterogeneous networks. If you want to use such a network, “Path Translation Rules...” should be specified, too, or the Job Manager won’t be able to resolve the path to your files. “Delete temporary files if success” should be checked to free disk space. “Web Interface” is normally the IP address used before (“Manager Location”) together with “HTTP Port”, for example: 192.168.1.15:8080.

u A more detailed description of the individual settings can be found on page 53, “Preferences”.

These settings only have to be made once, unless you change the server’s address or location within the network. To make everything work it’s necessary to reload all Job Manager applications. Now you can establish connections between the server and its nodes.

b. The Web-Interface

Please have a look at the Job Manager window. The first lines give you hints about which port you have to specify in RealFlow preferences when sending jobs to the Job Manager, and the port for the web interface:

Waiting for RealFlow instances: Binding to port: 65454HTTP Petitions. Binding to port: 8080

To open the web interface, which carries the control over the job manager, you have to options:

1. From your Internet browser2. Directly within RealFlow’s Job Manager window: Menu Bar > Layout > Job Manager

In both cases you can see an empty line for a web address. There you have to enter the Job Manager’s address and the port, the server is bound to. To open the interface you have to know the IP address of the computer, where the manager application is currently running, for example:

http://192.168.1.15:8080

u The Job Manager window is a working web browser, and if you enter a web address of your choice, RealFlow directly connects to the Internet and loads the desired page. However, please note that Next Limit cannot guarantee your computer’s security while browsing through the web.

The Job Manager window in RealFlow 5.

You can see basic information about date, time and network bindings. Additionally there are three tables, containing data about currently processed jobs, available (=running)



Introduction | 232

nodes and workgroups. “Job Manager Actions” offers a variety of functions to manage your jobs. The “Log” section is a mirror of the most recent manager application’s messages.

current Jobs

Here you can see a lot of columns, indicating the most important parameters and settings of a simulation. With “Priority” you can determine which job should be processed first – the order is just from top to bottom.

A shortened representation of the “Current Jobs” table

The “Status” field is very important, because it describes the job’s current status with a series of messages shown in the table below. Any status, except “Simulating”, can be set to “Pending” via “Retry” or “Restart”.

Message Description

Pending A job is in the queue and ready to be simulated.

Stopped A job can be cancelled either before or during a simulation.

Simulating The simulation is currently in progress.

Finished The simulation has been completed without (apparent) errors.

Unknown idoc The requested IDOC, shown in the “IDOC” column, doesn’t exist.

Unknown path The given Scene/script path is wrong and cannot be reached.

Script error The RFS file, specifying the simulation environment, is faulty.

Unlicensed One or more simulation nodes are unlicensed.

Disconnected A job in “Simulation” state lost its connection.

Message Description

Broken This message pops up when a job is currently simulating and the manager application was closed or crashed. Nevertheless, a node might continue to simulate a scene successfully. In this case, “Status” will soon be changed to “Simulating”/”Finished” automatically.

Failed You can see this status when the simulation failed without a specific reason.

The small icons on the right are used to manage the displayed jobs or add a new one manually. “Edit” and “Add” share the same options and you can find a description of these parameters directly below.

Icon Function

“Edit“ opens a new browser form to edit a job.

“Stop” a current job. You can resume with “retry”.

“Restart” a stopped or pending job to continue the simulation.

“Remove” a job from the “Current Jobs” table.

“Add” opens a new browers form to create a job manually.

current Jobs – “add”

“Add” leads to a new page where you can create a job manually. To become familiar with these settings, it’s useful to create a job out of RealFlow (“Send to job manager”) and open it with “Edit”. There you’ll find all required settings and you can use them as an orientation or template for creating your own jobs.

RealFlow Scene or ScriptThis field specifies the path to the desired FLW or RFS file which will be used for the current network simulation.

Translation RulesHere you can see 4 fields, carrying rules for working with heterogeneous networks. Please read more about this topic on page 238.



Introduction | 233

Delete Scene or Script file when simulation endsIf this button is checked, all temporary files will be removed to save disk space, but you have the option to keep them – it’s your choice.

Assign to workgroup or nodeIf you want to bind the job to a certain workgroup or node, you can choose the available machines and groups from the drop down menu.

IDOCUnder “Name” you can enter the name of the IDOC meant to be simulated with this job. It must be exactly the same name as seen under RealFlow’s Node panel. If the IDOC cannot be found, the Job Manager prints out a status warning: “Unknown idoc”.

u In script mode it’s not possible to make any changes to this or the following settings, because they’re already determined in a script that’s created automatically with the “CmdSendJob” plugin.

Frame range“First frame” and “Last frame” tell RealFlow where to start and stop the simulation.

Maximum number of threadsThis setting specifies how many threads will be used for the current job.

Mesh ParticlesCheck this box if you want to create meshes from the particles of the previously entered IDOC.

Use CacheIf you want to create meshes in post-process, tick this option. In this case, the already simulated data from the related IDOC are read and used for meshing.

Reset SimulationIf this function is active, the scene will be forced to reset before the simulation starts. This can be an interesting option for scenes using scripts to initialize certain variables.

Reset/SubmitIf you select “Reset”, you’ll reset to the Job Manager’s default values, as with web-based forms. “Submit” will send your settings to the manager.

Do not start job automatically (only available with “Add New Job”)With this option you can delay the execution of the new job. When you add a job with the “Hold Job” option activated, then it will have “Stopped” status.



Introduction | 234

To start a job, a node must meet all of the following requirements:

• At least one node must show “Status = Ready”.• If a workgroup is specified, a node must belong to the group chosen for the job.• A node must have an “RF version” number, equal or higher to the one of the job. This

is of importance in cases where you have to resimulate scenes from older RealFlow versions.

• A node’s maximum number of threads must be equal or higher than the one specified for the job.

There are also a few things to bear in mind with jobs, sent to the Job Manager via the “CmdSendJob” plug-in. These jobs

• don’t have any workgroup assigned.• don’t have any minimum number of threads assigned. • are always set to “Pending” status.

The other fields are also filled in automatically and contain various specifications about your simulation. This information will be updated automatically.

Nodes

Nodes are added and removed automatically, though an updated list requires reloading this page. The different columns give you some basic information about the computers you’re using and “Status” tells you whether the node can be used for simulation or not.

A abbreviated representation of the “Nodes” table.

The little icon on the right gives you the option to edit the desired node. The “Status” column is again of special importance and can show a variety of states, shown in the table on the right.

Message Description

Ready The node is available for simulation.

Disconnected There’s no connection with the manager.

Ignored Ignored nodes are those with the “Ignore” flag set to “On”, regardless of whether it is available or not.

Waiting The node is currently connected to the manager. If a node stalls on this status for some reason, it can be reconnected with the “retry” action. Usually you can see this message when the node starts to bind itself to the manager.

Simulating A simulation is currently in progress.

Unlicensed The node can’t be used due lacking a valid license. The “retry” action will appear in this case for a second chance.

Disabled The node is disabled. This can happen when the workgroup it belongs to is disabled or has reached its maximum amount of jobs.

Nodes – “edit”

The settings for nodes are displayed a new page when you click on “edit”.

Node NameHere you can enter a node’s real name, as it appears in your network, e.g. “MyComputer”, “RF_Render_Node” and so on. Please bear in mind that node names must not include blanks or special characters. Another option is to use an IP address. Both methods are valid, but the name and IP have to exist, of course.

Ignore Node with this IPIt’s sometimes necessary to exclude a computer from a simulation, because it’s busy with other jobs, needed by someone else or there’s currently no appropriate license available. Check this button if you want to ignore the observed node.

The manager rejects any connection from the specified IP and if the node was already connected to the manager, then it’ll be kicked out. A common scenario could be a Maxwell Rendernode in conflict with RealFlow simulation node. For disabling purposes it’s better to use the “Disable” check box, because this mode acts more like banning a node.



Introduction | 235

Show Node even when disconnectedDisconnected nodes will be removed from the Node list automatically, but you can force them to be kept by activating “Visible”.

Disable NodeIt’s also possible to completely disable a node’s functionality with this option.

Reset/Submit“Reset” restores the previously visible settings and “Submit” passes everything to the manager. You’ll probably have to reload the web-interface to make the changes visible.

Remove nodeThis link removes the currently edited node manually from the Nodes table.

Workgroups

In networks it’s possible to create different workgroups, for example depending on a division’s tasks, like fluid simulation, rendering or compositing. With “Workgroups” you can

tell the Job Manager, which groups of computers should be used for network simulations. You can even choose which machines within a workgroup will contribute to a network job and, of course, the number of available nodes depends on your license.

An example of a “Workgroup” table with an added node.

Workgroups – “add”

Clicking on “Add” leads you to a new page where you can make the desired settings and restrictions. The setup is simple, because you just have to enter a workgroup and the number of simulating nodes. Available workgroups and nodes within the observed workgroup are also displayed.

u Editing and adding workgroups share exactly the same settings and parameters.

Workgroup NameHere you can enter any valid name of an existing workgroup. Please note that workgroup names don’t allow blanks or special characters. Recursive workgroups are not allowed. Any workgroup containing the one you are editing will not appear on the list of selectable workgroups. Even if it appears, it can’t be used for simulation tasks.

Workgroup membersInside this multi-option field you can see the available members of a workgroup.

Maximum number of nodes simulatingTo specify how many machines of a workgroup should be able to simulate RealFlow jobs, enter the desired number here. With 0, all nodes will be taken into account, as long as they have appropriate licenses. When a workgroup reaches its maximum amount of running jobs, the rest of its nodes will be disabled.



Introduction | 236

Working ActivityWith “Enabled” you make sure that the current workgroup and its nodes can be used for simulations. Disabling a workgroup disables all nodes belonging to it recursively. Please note that a workgroup cannot be disabled while any of its nodes is simulating.

Reset/Submit“Reset” restores the previously visible settings and “Submit” passes everything to the manager. You’ll probably have to reload the web-interface to make the changes visible.

Job Manager actions

This section contains a couple of links, leading to new pages, for managing jobs and nodes. “Add New Job” has exactly the same function as its counterpart under “Current Jobs” and with “Add New Workgroup” it’s actually the same.

“Manage Nodes” has many features from the “Edit” page under “Nodes”, but you can process all available nodes easily from a clearly arranged table. The buttons and entries are self-explanatory and already discussed in the previous sections. Below the table you will also find a couple of functions in the form of links. These are used to switch certain attributes from selected nodes on or off. Additionally, there’s a small “Help” section, explaining the table’s columns. “Reset” and “Submit” work as usual.

Another set of functions is used to remove finished, broken or inactive jobs conveniently. Instead of deleting them individually under “Current Jobs”, these actions can be used to delete all jobs at once. Finally, there’s “Clear Incidences”. In RealFlow’s Job Manager, an incident is an entry to its RSS feed showing you the manager’s messages in a clearly arranged feed.



Introduction | 237

You can call this page from a browser with:

http://192.168.1.2:8080/feed.rss

RealFlow’s built-in Job manager window isn’t capable of displaying RSS feeds, because it doesn’t support the feed-protocol, but you can at least follow a text version.

log

The “Log” part displays the last 20 messages from the manager application. It’s much more convenient to have an overview directly in the web interface than to have to switch between different applications to view the messages. This section doesn’t have any functions and the content is only intended to provide information.

16.02 sharing simulation JobsThough it’s not really required, it’s better to launch the server first and then connect the nodes. With each new node that’s recognized, the server window prints out a message. Each node also gives you visual feedback about its connection to the server.

When you open the web-interface you also have a complete list of available nodes and a variety of basic information about network addresses, operating systems and so on. To share a simulation you of course are required to have an appropriately prepared scene, so let’s start with a sample setup. This scene is very similar to the IDOC example from the previous chapter, but added again for your convenience.

u This example assumes a homogeneous network. This means that all computers in the network must have the same main operating system (Windows, OS X, Linux) and the same paths to the used resources/files.

The project consists of 4 emitters, influenced by a gravity daemon. Simply place the emitters along a horizontal line and draw a box around them, just like in the image below. For better differentiation you could assign various colours to the particles. Of course, such a basic scene could easily be simulated on a single computer – it’s being used here simply to explain the concepts behind RealFlow’s Job Manager.

The next step is to add an IDOC node to the scene:

Icon bar > IDOC > Multiple

Menu bar > Edit > Add > IDOC > Multiple

Before anything is displayed in the viewport, RealFlow asks you to subdivide the IDOC into several independent domains. The number of subdivisions should represent the number of connected nodes. Assuming that you have 3 nodes in your scene, enter “3” under “X”. And now you can also see why the scene contains a cube object around the emitters. That’s not for limiting the particles to a certain space, it represents the IDOC’s boundaries. RealFlow shows a dialogue where you can choose “Cube01”, for example, to create the domains directly from the selected object.



Introduction | 238

Since there are 3 IDOCs and 4 emitters, it’s necessary to adjust the IDOCs – this can be done by simply rescaling/moving them with the R/W key or the Scale/Move tools from the Icon Bar. So, the IDOCin the middle must enclose 2 emitters, while the other ones contain a single emitter each. Finally, delete the surrounding cube, select the IDOC node sand click on:

Node Params >IDOC > Update

After this action you can see that RealFlow attached the emitters to their related IDOCs and you’re actually ready to simulate the scene. To send the simulation data to the active nodes, multi-select all available IDOCS and click on

Node Params > IDOC > Send to Job Manager

Another, maybe more convenient way to send the entire scene (without selecting the IDOCs) to the Job Manager is a single click on the “Send to job manager” button in the Simulation Tools section inside RealFlow:

To monitor the network simulation, open the web-interface and check “Reload every”. This option automatically updates the web-interface and displays the latest status information. You can also set the desired interval. If you have access to the node and server panels, then you can see the simulation running. If you have ever used “RealFlow -nogui” (formerly: Command Line) version, then the node window’s output certainly will be very familiar to

you. From the web-interface you also have some more possibilities, for example changing a job’s priority, stopping or removing jobs, and adding new ones. You’ll also be informed if there are interruptions of the simulation process or path translation problems.

Once the simulation is completed, switch back to RealFlow’s viewport and press Alt + U to update the timeline and see the final results. In case of errors you’ll receive an appropriate message via a window:

Connection refused

After clicking “OK”, another dialogue appears, giving you certain options on how to proceed: “Ignore” stops the execution of the manager plugin and leads you back to RealFlow. With “Retry”, a new connection attempt is performed. This is useful if you forgot to open the Job Manager. Finally, there’s “Remove temporary files” to manually delete all FLW and RFS files created during simulation. Once the files are deleted, you can return to RealFlow.

The final result of this little workshop can be seen below. It’s also worth mentioning that emitters inside a common IDOC can still interact. Only particles from different IDOCs cannot mix.

16.03 path Translation RulesIn homogeneous networks, path information is always written the same way and RealFlow‘s Job Manager will find the simulation files automatically. In networks consisting of different operating systems, the situation is different, because they all have different path notations. To overcome this problem, the Job Manager offers a helper, allowing you to specify certain rules about how path names are treated. You can find it under:

Preferences > Job Manager > Path Translation Rules...

“Prefix” is the beginning of a path you want to translate – it points to the computer, acting as a server node. On this machine you normally have several directories or even volumes where your simulation data are stored. The absolute paths to these locations are entered here, for example on a Mac:

/Volumes/RF/Simulations



Introduction | 239

Under “Linux” you define the translation of paths given under “Prefix”. Using the previous example, the Linux-style translation looks like this:

/mnt/RF/Simulations

“Windows” has the appropriate translations for Microsoft’s operating systems:

\\RF/Simulations

Finally, there’s the Mac column – in this example the translation rule exactly matches the entries under “Prefix”, because the original paths point to a volume or directory under OS X. If your main machine is a Windows-based computer, the entries for “Prefix” and “Windows” would be the same. So, the path would look like this:

/Volumes/RF/Simulations

Of course, it’s also possible to add paths to different directories and it’s not required that all computers share equal folder trees or volume names. The “Add Row” button adds an empty line for a new path translation rule. Please have a close look at the prefix for Windows, because it requires a series of 4 backslahes.

16.04 status Diagrams

On the following two pages you can see diagrams, explaining and visualizing the Job Manager‘s different simulation statuses. The first graph is for the “Current Jobs” section, the second one shows you the message available in the “Nodes” table.

At first glance, the diagrams may look a little confusing, but when you simply follow the arrows, you’ll soon find out which event leads to a particular message.



Introduction | 240

a. “current Jobs” Messages



Introduction | 241

b. “Nodes” Messages



Introduction | 242

17 cURVe eDIToR

Though RealFlow works with dynamically created motion and position data, animation is an essential part, because it’s often necessary to animate parameters, build ramps, control velocities or create regular movements, etc. Traditional key-based animations and expressions are important features and frequently needed. Of course, it’s often better to do complex animations within your 3D software, since you normally have much more sophisticated tools, but there are things that can’t be done externally, like animating an object’s physical or rigid body dynamics parameters, or it’s sometimes simply faster to create various motions directly within RealFlow.

Sequence of an imported ragdoll with motion data

Each node provides a wide variety of parameters and almost all of them can be animated or controlled with an expression. RealFlow does not differentiate whether an object is imported or native, but imported objects are locked by default. This means that you won’t be able to change any of the item’s position, scale, or rotation data. You first have to unlock the settings with:

Node Params > Node > SD <-> Curve

Setting keys is one thing, but in most cases that’s not enough. You often need more options to work on curves, because linear animations normally don’t give the results you’re

looking for. For this purpose RealFlow has a powerful built-in tool to enhance animation curves and adjust them. With RealFlow 5, Next Limit has introduced a wide variety of completely new features. To take an example, it’s now even possible to mix key-based animations with expressions.

The Curve Editor has also been redesigned to give you a better and faster overview of your animation data. It’s also now much easier to select from different animation properties and toggle between them. New functions for copy and paste will also enhance and accelerate your workflow and offer lots of new possibilities.

u On page 243 you can see a screenshot of RealFlow’s Curve Editor with all its elements.

To get a better feeling for the Curve Editor’s functions, it’s indispensable to understand the main concepts behind RealFlow’s animation system. This especially concerns how animation data are handled and structured within the program. An animation value inside RealFlow consists of two parts:

1. The node’s name2. The animated attribute

Both segments are separated by a dot. This notation, which is also similar for Python scripts, is the reason why dots should be avoided in node names. Assuming that you want to animate a standard rocket’s X position, RealFlow internally uses the following notation to identify the curve in the editor:

Rocket01.position_X

The curve editor disassembles this notation into a tree structure that’s visible in the “Curves” section. Normally you don’t have to care about this notation, but it’s important for expressions or if you have multiple animation curves displayed and want to toggle between them, or copy/paste keys from one curve to another. This syntax helps you to identify the individual curves and the animated properties.



Introduction | 243

Toolbar

Menu Bar Information Bar

Curve Tree

Insert Menu

Graph Window

Add Expression To Curve Expression Field Delete Expression



Introduction | 244

17.01 Basic animation Simple key animation inside RealFlow is as easy as in your 3D program:

• Drag the timeline slider to the very first frame of the animation. • Select the attribute/value to be animated, enter a value and right click on it.• From the expansion menu choose “Add key” or double click on a parameter with the

ALT key pressed.• Locate the last frame of the animation.• Enter the end value of the parameter. • Again, right click on the attribute and set another key.

Stylized workflow for basic key animation. The result is shown as a line with dashes.

That’s actually all you have to do. What you have now is a linear animation. Of course, you can add new keys at any other point in time. Instead of entering values, changes can also be made in the viewport with RealFlow’s appropriate tools (“Move”, “Rotate”, “Scale”) to get immediate feedback. Another idea for key animation is to switch on or off certain attributes, such as “Simulation” and “Dynamics”. To have a look at the animation curve it’s necessary to open the Curve Editor. You have two options:

Right-click on an attribute/value > Open curve

Double-click on a name of an attribute, for example “@ mass” or “Friction”

A basic curve for a linear animation could look like this:

17.02 The curve editor ToolbarThe Curve Editor provides a wide variety of functions which are accessible either over a menu bar or a toolbar with several symbols. Since both bars share many contents, it’s often more a matter of taste whether you want to call the actions via the menu or the icons. The menu bar offers a function named “Toolbars”. With this option it’s possible to configure the buttons to your own needs and switch on or off particular icons.

a. Mode

This section consists of three buttons:

Add New Control PointA new control point, or key, can either be added with this button or by simply double-clicking onto an existing curve, or directly into the graph window. Another option is to Ctrl- click. If you want to add keys by using this button, click on it and place the cursor at



Introduction | 245

c. copy/paste

Both buttons provide submenus for advanced copy and paste actions and curve mixing:

The “copy” submenu

Copy Selected KeysThe Curve Editor allows multiple selections of keys and they can be copied with this function – in the following step you’ll be able to paste them, preserving their positions.

Copy CurveIf you want to grab and copy the entire curve, use this function. The convenient thing is that you don’t have to select individual keys first.

The “paste” submenu

Paste CombinedIn this case you’re not simply replacing an existing curve, but mixing keys from the clipboard with keys from the desired curve. The new keys will be placed at exactly the same position they had before.

Paste Combined After TimelineHere you can specify the frame from which the copied keys will be mixed with the curve. You can create an offsets by placing the timeline indicator at a particular postion. Keys will be inserted to the right of the indicator without deleting existing keys.

the desired position – another click draws a control point. This operation can be repeated as often as required. By clicking on the icon again, the insert mode will be deactivated. By default, new keys are added as Tcb, but you can change the standard key mode under Preferences (see page 53). Another alternative to add keys is double-clicking on the curve or somewhere inside the Graph window – the key will be added immediately.

Remove Control PointTo delete a key you simply have to choose this tool, place the cursor on the desired control point and click once. If you want to leave this mode, just click on the icon again. A control point can also be deleted by selecting it with the cursor and pressing the Delete key.

Zoom ToolWith this feature activated it’s possible to draw a rectangular selection inside the graph window for zooming into the curve. Another option is to hold the Alt key while dragging the mouse. This mode allows active zooming: dragging to the right, upwards or diagonally (45°) shows larger parts of the curve, while the opposite directions are used to zoom into the curve, revealing more details. To exit zoom mode, please click on the icon again. If your mouse has a middle wheel, it can be used, too.

b. pan/scale

For navigating through the Graph window, the Curve Editor provides these options:

Pan SelectionThis button is only active with selected keys and opens a window for entering X and Y coordinates. These coordinates are used to shift the selected control points to a new position. The dialogue also offers a button to toggle between frames and seconds, used for the legend of the Graph window’s X axis.

Scale SelectionSimilar to “Pan Selection”, this tool requires an active key selection and opens a window. There you can type in scaling factors for magnifying or minimizing the distance between the keys in X and Y direction.



Introduction | 246

Paste and Replace on Current FrameThe last feature again uses the current position of the timeline slider: the first key of the copied curve will be inserted directly at this specific position overwriting all previously existing control points.

d. Undo/Redo

These buttons work exactly the way you expect them to work, but it’s important to mention that the Curve Editor’s “Undo/Redo” is just a proxy of RealFlow’s global function. So if you clear the undo stack, this action also affects the Curve Editor.

UndoUndo last actions by clicking onto this button as often as required.

RedoTo restore the last actions, you can also click on this icon multiple times.

e. Fit

This section consists of 3 main functions and 2 submenus as shown below. It is used to adjust the Graph window for viewing and fitting certain sections of a curve.

Selected keys are copied and then pasted to the right of the timeline indicator (grey line)

Paste Combined on Current FrameAs you surely have noticed, the timeline and the graph window of the curve editor are linked. This means that you can navigate to a certain frame by simply dragging the timeline slider to the desired position. This position is used to paste and combine the previously copied control points/curves with the active curve.

Paste and ReplaceThis is a convenient tool to transfer complete curves from one node or property to another. First, a curve has to be copied to the clipboard. You should use “Copy Curve” to really get all keys captured – even if the current view doesn’t show them completely.

Paste and Replace After TimelineThis mode can use a timeline-based frame-offset to paste the keys and replace the curve. An example: You have curve A and copy the last three keys – the first key’s frame value is 16. Now you want to transfer these keys to curve B, but not by simply replacing it from the start. In this case you go to frame 67 and use the “Paste and Replace After Timeline” method. The first key from the clipboard is inserted at frame 83 (frame 16 + frame 67) and the eventually following keys of B are replaced by the copied/pasted keys from A.



Introduction | 247

Regarding snapping, there’s another useful keyboard/mouse combination: during dragging a control point to a new position, it’s possible to hold the Alt key pressed. This simple action activates some kind of dynamic snapping, relative to the key’s original positions in horizontal and vertical directions.

The “Toggle snap to Grid” Button

The curve window shows a background grid for better orientation and to give you a rough impression of the adjusted values and their dimensions. If you want to move a key to a new position, you can activate snapping. The final position of the key will be at an intersection point of a vertical and a horizontal grid line.

The “Toggle snap to Grid” submenu

Horizontal SnapOnly the horizontal grid lines will be considered while repositioning a key.

Vertical SnapThis function works exactly as the previous one, but in the vertical direction.

g. Node Type

RealFlow offers a total of 4 different node type settings, which are available from the appropriate buttons.

The “Fit View” submenu

Fit ViewThis option entirely fits the currently selected curve to the Graph window.

Fit Horizontal ViewThis mode is used to stretch or compress the curve in horizontally.

Fit Vertical View Here you can fit the view in vertically.

The “Fit View To selection” submenu

Fit View to SelectionThis function only considers selected keys and curve parts outside your selection won’t be visible any more. To draw a selection simply drag a bounding rectangle around the desired keys. If you want to show the entire curve again, choose “Fit View”.

Fit Horizontal View To SelectionJust like the functions before, this tool is restricted to the horizontal direction and only takes selected keys into account.

Fit Vertical View To SelectionThe functionality is exactly the same as with the previous tool, but limited to vertical views.

The “center View to Timeline” Button

Here you can automatically reposition the vertical axis to the centre of the graph window. This means that you can see the same amount of frames in both negative and positive directions, and the timeline position will be the centre of your view.

f. snap

This section consists of single button: “Toggle Snap to Grid”. The button itself already calls the appropriate function and the little triangle reveals a submenu with two entries. Snapping doesn’t affect the creation of keys, but repositioning them with the mouse.



Introduction | 248

Set Selected Points Type to TCBTCB controllers produce curve-based animations very similar to Bezier controllers. However, they do not use adjustable tangent handles. They use fields to influence “Tension”, “Continuity” and “Bias” (=TCB) of the animation curve. TCB is the standard mode with animation keys – you can learn more about this mode starting on page 250.

Set Selected Points Type to BezierA Bezier curve is modelled using a parametric polynominal technique and they can be defined by a unlimited number of vertices. Each vertex is controlled by two other points (or handles) that control the endpoint tangent vectors. Bezier handles can be manipulated with their tangent helpers: click on the round end of a Bezier tangent helper and drag the mouse to change its curvature.

Set Selected Points Type to LinearThis is the “easiest” mode and does not provide any arguments or tangents. The keys are just connected with straight lines. The curve between linear keys shows edges and peaks, and changes between values might be abrupt. It’s not suited for smooth transitions between several values or ease in and ease out to create delays.

Set Selected Points Type to Stepped“Stepped Node” specifies a stepped tangent to create a curve whose outgoing tangent is a flat curve. The curve segment is flat (horizontal) and the value changes at the key without gradation. To create a stroboscope effect, for example, you would use a step tangent.

u A curve is not restricted to a single type, like TCB, and you can combine them without limitations. TCB might follow a Bezier, several linear keys can be combined or copied/pasted with Bezier types and so on.

h. Tangents

Here you can choose from 3 methods. Please note that these functions only work with Bezier-type keys. The only exception is “Flat tangent” which is also valid for TCB keys. Tangents are important for ease-in and ease-out effects, for example.

Break TangentsIf the tangents of a key are too steep or if there’s a visible peak, then it’s a good idea to break the tangents to achieve a smoother curve. This helps to avoid sudden jumps.

Unify TangentsA key’s tangents can be adjusted individually for each side, but sometimes it’s necessary to use equal settings for gradient, tension, or bias.

Flat TangentsTo flatten out the tangents easily, use this function.

i. other

The last group again consists of three buttons. The last one – “Show Key Properties” – is a special case, because it opens a separate window for fine-tuning keys. For this purpose, the Curve Editor provides a wide range of functions and these settings are treated separately.

Toggle Frames or Time ViewBy default, the graph window’s legend for the horizontal axis shows the current time in frames per second (FPS). With this button you can quickly change between FPS and time.

Show Selected Keys Value as TooltipsThis is another convenient tool, helping you to get fast access to all relevant parameters of selected keys. Both time and dimensions are displayed next to the control points. Of course time is either given in frames per second or seconds, depending on your selection from “Toggle Frames” or “Time View”.

The “selected Key properties” panel

Clicking on this icon opens a panel with comprehensive features and options to shape and adjust selected keys. An interesting feature is the option to specify a key’s pre and post-behaviour to make the curve follow a certain direction. It’s also the place for controlling a TCB key’s properties and achieve various effects.



Introduction | 249

<< >>Each control point carries its index number. By clicking on the arrows you can go through the keys easily, while the current index number is shown in the field.

FrameBy simply entering a new value it’s possible to reposition the selected key in horizontal direction. Please note that negative values are allowed, too. Frame depends on “Toggle Frames” or “Time View”, and therefore either shows frames or seconds.

ValueSimilar to “Frame” you can directly enter a new parameter value and shift the current key in vertical direction. The dimension of this value strongly depends on the attribute and its limitations.

Pre-BehaviourYou can choose between “Zero” and “Constant”. “Zero” means that the currently selected attribute’s value is zero until the first key. With “Constant” the value of the first key is used. Both settings create a line parallel to the X axis. This option only affects the very first key of a curve. The appearance of “Pre-Behaviour” is actually the same as “Post-Behaviour’s” first options, as seen on the right.

Post-BehaviourThis setting only effects the last key and is similar to “Pre-Behaviour”, but you have many more options. “Zero” resets the attribute’s value to 0.0, “Constant” just keeps the last value. With “Loop” you create an endless repetition of the curve segment between the first and the last key. “Loop offset” adds the the key values and creates a growing curve. “Follow tangent” uses the last key’s tangent gradient to continue the curve.

The images on the right show all available “Post-Behaviour” options:1 = Zero, 2 = Constant, 3 = Loop, 4 = Loop offset, 5 = Follow tangent



Introduction | 250

Node Option FieldEach control point can have its own node behaviour that directly influences the curve. It provides 4 types: “Tcb”, “Bezier”, “Linear” and “Stepped”. The way the different types are influencing the curve can be directly seen in the little graph on the right. Except for “Bezier”, all behaviours use three attributes to control the curve: “Tension”, “Continuity” and “Bias”. “Bezier” has values for “Incoming” and “Outgoing” tangents.

Ease To / Ease FromYou should be familiar with these parameters from other animation programs. They’re used to create a smooth and natural acceleration or deceleration, instead of a linear increase/decrease of speed. Both values range between 0.0 and 1.0.

TensionHigher “Tension” settings produce more linear curves, while lower settings give you smooth and rounded curves. “Tension” also has a slight “Ease To” and “Ease From” effect that can be enhanced with the dedicated settings. Minimum and maximum values range between -10.0 and 10.0, and the result of the operation is visible in the graph window.

“Tension” causes an object in motion to slow down, or move a little bit less in each frame as it nears the keyframe, and to accelerate as it passes the keyframe. Without “Tension”, the object would pass through the keyframe position at a constant speed.

ContinuityBy definition, “Continuity” is responsible for the tangential property of the curve at the selected key: higher values produce a curved overshoot on both sides of the key, while lower settings result in curves similar to high tension, but without any ease to or ease from effects. The range of accepted values lies between -10.0 and 10.0. Negative “Continuity” settings are usually used to replicate a sharp change in motion such as that of a falling ball striking a floor and quickly reversing direction. “Continuity” is not available for Bezier-type keys.

BiasAgain, this parameter accepts values between -10.0 and 10.0. High values create a (more or less) linear curve before the key and an exaggerated curve behind it. The result is a kind of hump behind the currently active key. Low values show higher curvature before entering the key and a steeper progression leaving the key. A good example is a race car moving around a bend: it could use either a negative or a positive setting to 1) anticipate the turn with a negative bias, or 2) overshoot the turn with a positive bias. “Bias” is not

available for Bezier-type keys.

Incoming/OutgoingThese parameters are only visible with Bezier-type keys! By default, a keyframe uses one interpolation method, but you can apply two methods: the Incoming method applies to the property value as the current time approaches a keyframe, and the outgoing method applies to the property value as the current time leaves a keyframe.

Unlike other interpolation methods, Bezier interpolation lets you create any combination of curves and straight lines along the motion path. Because the two Bezier direction handles operate independently, a curving motion path can suddenly turn into a sharp corner at a Bezier keyframe.

17.03 The curve editor Menu BarAs mentioned before, most of the curve editor’s functions are accessible via the Toolbar and its icons, but there are a few more elements regarding file operation, key selection and layout.

a. The File Menu

The following entries and functions are only available from this menu – there are no corresponing buttons in the toolbar.

Reset All CurvesThis function deletes all keys and values from all curves in the Curve Editor. The result is a just a list of nodes and their properties, without any of their animation attributes.



Introduction | 251

Reset Selected CurvesThis functions works like “Reset All Curves”, but it’s restricted to a selection of curves.

Load CurveYou can load previously stored curves to the Curve Editor and use them with other nodes. There’s also a shortcut available: Ctrl + L (Windows/Linux) / Cmd + L (OS X). The Curve Editor accepts ASCII and XML files containing the appropriate header and data structure.

Save CurveIt’s also possible to store any curve individually either with this command or with the shortcut Ctrl + S (Windows/Linux) / Cmd + S (OS X). The curves are either stored as XML (.xml) or ASCII (.crv) files and can be opened with any text editor. The XML format is especially important for data exchange with other applications. With appropriate scripts you can also read, change and export the stored data.

b. The edit Menu

The entries of this menu share exactly the same functions and options as their counterparts from the Toolbar, including the appropriate submenus.

u The Edit menu contains all features from the toolbar sections “Undo/Redo”, “Copy/Paste”, Mode”, and “Pan/Scale”.

c. The Keys Menu

Except for “Select All”, “Select None” and “Delete Selected”, the other commands provide the same functionality as the appropriate Toolbar icons. This also implies submenus.

u The Keys menu contains all features from the toolbar sections “Node Type” and “Tangents”. Additionally there are some entries from “Other”.

Select AllIf you want to select all keys from currently active curves, use this feature.

Select NoneThis is an easy and fast way to deselect all keys from different curves without having to go through each and every node.

Delete SelectedTo delete a currently selected control point you can use this function. Removing all keys doesn’t correspond with deleting the entire curve, because in the first case, the node and its animated attribute is still visible in the editor’s curve section. This means that you’re still able to add keys by double-clicking, for example. If you entirely remove the curve, you’ll have to create it again if you need it in the future.



Introduction | 252

d. The View Menu

Like most of the other menus, View also contains many commands, also available from the Toolbar, but there are also a few more entries which help you to customize the Graph window and the Toolbar.

u The View menu contains functions from the Toolbar sections “Fit”, “Snap” and “Other”.

Show TooltipsIt’s often necessary to query basic information about a particular key. “Show tooltips” prints a selected key’s frame or time value and the corresponding parameter’s dimension to the Graph window.

Set RangeThe Graph window’s value range can be adjusted individually and with very high precision. Selecting this function opens a new window for entering your values.

Reset ViewFrom time to time it’s necessary to switch back to the Curve Editor’s default view – this can be done with “Reset View”.

Load ImageIn the same way as with the viewport’s option, you can load any supported image format to the Graph window’s background, either directly from the menu bar or with the Alt + I shortcut. Valid formats are – as always – TGA, JPG, PNG, BMP and TIF.

Clear ImageRemove the picture from the Graph window’s background with this setting.

ToolbarThis entry contains all available categories for processing control points. You can add or remove icon groups from the Toolbar by checking or unchecking the desired category.

17.04 expressionsExpressions are the most convenient way to automate courses of motions and regular or repetitive animations without scripting knowledge. Have you ever tried to model a perfect sine-shaped motion curve? If your answer is “yes” and you had problems, then you’ll love expressions. With them you don’t have to worry about keys, because you simply enter the appropriate function or formula and can immediately see the results. Theoretically, expressions go on for ever because it’s always possible to add another frame to continue



Introduction | 253

the range. You can also make them event-based. This means that you can define a certain condition to switch on a certain feature, e.g. rigid body dynamics. Such a condition could either be a particular frame or the position of a null object, to name but a few.

Expressions were used here for the vertical movement of spheres.

RealFlow provides all common functions, such as sine, cosine, square root, log, tan, etc. Additionally it’s also possible to use operators to perform comparisons and simple calculations, for example <, >, +, *, and others. In this way it’s easy to combine different functions and create complex formulas. Expressions are very flexible and versatile.

RealFlow 5 provides another new feature: the combination of expressions and key-based curves. Though both methods work completely differently, it’s possible to mix them and create a hybrid curve. Combining key-based curves and expressions can help you in many situations: for example, when you want to add some noise to an animation or create secondary motions within a higher-ranking movement. If you think it’s complicated to combine these different curve types, you’re totally wrong! A simple click on the “+” button, next to an expression, will do the job for you! The result is a completely new curve, showing characteristics of the animation and the expression – a hybrid type. For a better impression, the Graph window also shows you the original key-based curve with a less saturated colour.

Expressions are a very fast and reliable method to mimic different kinds of natural behaviour. In nature we rarely see perfect motion or endless expansion of forces, velocities or motion. They are all damped in some way, because everything loses a certain amount of energy over time. This behaviour can be perfectly simulated with expressions.

An example: When you’re working with lights inside your 3D program you probably would usually add a falloff to the light source. This prevents the light rays from strongly illuminating distant objects, as that normally wouldn’t look very realistic. Therefore, with most light sources you would usually be able to restrict the expansion of light with predefined modes, for example inverse, inverse square, or inverse cubic.

Curve Editor representation of various falloff functions.

Another method is to lower forces with an exponential function. This simulates the decline of forces over time. The same is possible for other values, like friction or temperature. With



Introduction | 254

simple functions it’s also no problem to switch certain attributes in constant intervals on and off, or create perfect motions along a certain formula-based path. Another important field of application is randomness. You often need a certain amount of randomness to make things more believable, for example wind direction. Of course, there’s a base direction, where the wind comes from, but always with slight variations – see below:

Expressions have even more advantages:

• Multi-threaded. Expressions make use of all CPUs and cores.• No scripting required. If you’re not familiar with Python, expressions are a perfect

alternative.• Fast to create. You don’t need debugging or many lines of code, because expressions

only consist of a single line.• Use standard maths functions. Basic algebraic operations, like brackets, and a little

trigonometry, are all you need.• Perfect motion. Since expressions are based on mathematical functions they are

physically correct and produce absolutely perfect results.

If you’re familiar with scripting or programming, expressions should be even easier for you to understand.

a. First steps

You don’t need to do very much for to create expressions. First, you need a parameter to be controlled by an expression. You select the desired setting from the Node Params window, right-click on the appropriate value, and select “Open curve”. Now you can see the node and the associated value, but currently no curve, because you don’t have any keys.

Below the curve window you can see a line with a “+” button, an input field, and an “Insert” button. With “+” you can easily merge the expression with an existing curve. The input field contains the expression you have to enter and “Insert” provides the lists with all available functions and variables.

A very important issue concerning expressions is time. In RealFlow, time is either measured in frames or in the standard time code format

hh : mm : ss (hours : minutes : seconds)

By default the time line in the GUI and the curve editor use frames. If you want to use time with expressions then you have to use them in the form of variables. A variable is a placeholder that will be “filled” with values. For frames you have to use the variable “f” and for time code it’s “t”. With expressions, “f” or “t” are replaced with the current frame/time from the timeline. This happens automatically so you don’t have to think about it. You can also create expressions with both frame and time dependency:

sin(t*10)*f/ 0

The result of the given expression sin(t*10)*f/20

With frames the curves show a very important difference: they look jagged and aliased, because frames only recognise integer values and the space between is interpolated by RealFlow. With time dependency, the curves are drawn smoothly. Fortunately it’s not difficult to get rid of these jagged curves. Simply multiply frames by time:

(t*fps)



Introduction | 255

Frame dependencies create stepped curves and time dependencies are used to smooth them.

Expressions are not limited to frames or the time code. You can also use numbers, or even animated attributes from other nodes or properties, for example:

sin(5)

cos(Cube01.rotation_X)

Another example:You want to create a regular up-and-down movement of an object, lets say an emitter. The first thing you have to consider is the appropriate function for this task. By looking at various mathematical functions you’ll see that either the sine or the cosine functions are optimal, because they already show this wave-like behaviour. The sine curve is even better, as it starts with 0.0. All functions like sine, hyperbolic cosine, square root etc. only need one parameter to work correctly. That’s why they are called unary functions.

The next thing you need is a curve from the emitter’s vertical position. Please note that this can either be the Y or the Z axis, depending on your preferences (see page 52). Here, we’ll assume that Y represents the vertical axis. Go to the emitter’s Node Params:

Node Params > Node > Position > Y

Right-click on the value and choose “Open curve”. Now the curve editor is visible, but there’s no curve or graph right now, because we’ve only prepared the emitter’s position attribute so far. Place the cursor into the expression field and enter

sin(t)

Confirm your entry with the Return key and have a look at the Graph window. The expression sin(t) works this way: for each frame, RealFlow calculates the appropriate sine value and applies it automatically to the Y position of the emitter. Nevertheless, the result might not be what you might expected. You surely awaited more “hills and valleys”, didn’t you? What you can see is just the basic sine function in dependency on the current time. With simple operations you’re able to create a denser or wider curve, higher peaks, and a positive or negative offset.

Here are a few example operations to modify the sine curve and the results:

• sin(t*5) Sine curve compressed along the X axis • sin(t/5) Sine curve stretched along the X axis• sin(t+5) Shift the curve 5 units to the right along the X axis (horizontally) • sin(t-5) Shift the curve 5 units to the left along the X axis (horizontally)• sin(t)+5 Shift the curve 5 units up along the Y axis (vertically)• sin(t)-5 Shift the curve 5 units down along the Y axis (vertically)• sin(t)*5 Stretch the curve 5 times along the Y axis (“higher“ curve) • sin(t)/5 Flatten the curve to one fifth in Y direction (“flat“ curve)

It’s also possible to combine functions with each other. There’s no rule that expressions must consist of just a single function – infact anything goes as long as it follows the fundamental mathematical rules:

(sin(t) + cos(t)) / (cos(t) – sin(t))

This means that it’s not possible to perform division by 0 or extract roots from negative numbers, for example. Division and multiplication have a higher priority than addition and subtraction. If you want to reverse this rule, brackets are needed, as you can see from the term above. When you’re working with operations like addition or multiplication, you always need two arguments. These functions are hence called binary functions, as seen here: value1 + value2 or value1 < value2

Now that you’ve entered the expression you’re already done! Close or collapse the curve editor, press the playback button from Timeline Control, and watch the emitter’s perfectly regular motion. Of course it’s possible to create this kind of motion curve by traditional means, but it would be disproportionately difficult. So don’t be afraid of expressions: just experiment a little and you’ll soon find out that they’re flexible, versatile and easy to use.



Introduction | 256

Motion path in vertical direction with sin(t)*cos(t*2).

b. Inverse Functions and Negative Values

Another important feature is the use of invert functions and negative values. You can simply inverse a function by applying

1 / x

“x” being the appropriate variable, term or function you want to use.

Inverse functions are often necessary for falloffs, for example. Any valid function or term can be inverted, but there might be some gaps in the definition of functions, because of divisions by zero. This, for example, happens with the inverse of sine or cosine functions. The cosine of 90° and 270° is 0 and division by 0 is not defined.

With 1/cos(t) the graph shows undefined values, indicated by vertical spikes.

The values around 90° and 270° quickly converge against infinity and become very high. This normally leads to completely exaggerated motions or settings. Before you really apply an inverse function it’s therefore recommended to print it first. This can either be done directly in the editor’s Graph window or an external function plotter. There you can see the values where the expression will cause problems.

Negative values are another typical transformation with functions and expressions. With negative values you can change the direction of a function. Just have a look at the following term:

5 * exp(t)

That’s a nice exponential function converging from 5 against 0. It’s actually an ideal expression for a daemon, slowly losing its strength or force, but there’s one problem: the function plot shows that all the values are on the left side of the origin. This means that you have “negative” time values. With a simple transformation you can change the direction to make the time values positive again:

5 * exp(-t)

This is now an expression you could use for the desired purpose. By changing the initial factor (here: 5) you can shift the starting value. A factor like -t * x will make the curve steeper (if x > 1) or smoother (if 0 < x < 1). You can see an image of the two discussed functions on the next page...

The left graph shows the function 5*exp(t), the right curve represents 5*exp(-t).



Introduction | 257

c. Random Values

Random numbers often play an important role with natural phenomena. Not everything is completely predictable and slight variations care for more realism. For this purpose we can use RealFlow’s built-in random number generator. This tool works exactly as any other of the curve editor’s functions. You can also create random values from the time variables f and t, e.g.

rnd(f) or rnd(t)

As you can see from the image the values are getting bigger and bigger. This has something to do with the random function’s mode of operation. In this case – rnd(f) – RealFlow expressions create random values between 0 and f, so with growing f, the resulting values become larger and larger. If you enter a simple number n then the range will be between 0 and n, as shown here:

The expression used for the previous example is just

rnd(3.0)

The values will be between 0 and 3.0. By adding a random value to a given number you can create jitter or oscillations effects, for example for wind or an emitter’s speed value. Here the y axis of a wind daemon carries an expression:

Wind01.position_Y = 42.5 + rnd(5)

The wind daemon would randomly oscillate between 42.5 and 47.5 degrees. That’s an average of 45 degrees. So we can easily define a main wind direction including slight variations.

A very interesting field of application is the addition of standard functions and random values. Then we can define a kind of base movement with an overlying noise frequency:

sin(f*5) + rnd(0.5)

To restate: with the “+” button left of the expression input field it’s also possible to add any random function to an existing animation curve with keys.

Random numbers are an extremely versatile method to create more realistic and not absolutely perfect motions. Randomness is a principle that can be used for many things and with slight variations simulations often look better. A really helpful method is to combine random functions with keyed animations, using the “+” button again.

d. conditions

Another interesting possibility is the use of conditions with the “if” statement. With this method you’re able to trigger, stop or switch values, settings, and properties. The “if” function always needs three arguments, enclosed in brackets:

if(value1, value2, value3)



Introduction | 258

The first value is a comparison to specify a certain trigger point, e.g. a particular frame or point in time:

if(f<49, value1, value2)

This means that from the moment the timeline reaches frame 50, value1 will be switched to value2. Now you can also perform checks with the equality operator “=”, which is new in RealFlow 5:

if(t=5.0, value1, value2)

Instead you can use values from other objects and nodes for comparisons, like this one:

if(Null01.rotation_X < 180, value1, value2)

An example:You want to create a sine-shaped motion with an overlapping random noise, but with frame 75 the attribute’s value should become 0. Such an expression is no problem with the “if” statement:

if(f<75,cos(t*5)+rnd(1),0)

In other words: When the current reaches 75 then switch the function sin(t*5)+rnd(1) to 0.0. Here’s an image of the condition above:

The condition (f<75,cos(t*5)+rnd(1),0) tells RealFlow to set the value to 0 with frame 75.

Another interesting feature is to switch on rigid body dynamics at a certain moment. Choose the node’s Dynamics parameter, open the curve and enter:

if(f<99,0,1)

With frame 100 rigid body dynamics will be turned on. The notation might appear strange at first glance, but with expressions it’s not possible to use strings, so an expression like this is not valid:

if(f<99,No,Rigid body)

To overcome this limitation, the list entries from the dynamics panel or other properties are numbered:

0 = No1 = Rigid body2 = Soft body

So if you want to A) turn on soft body dynamics at frame 100, or B) switch from rigid to soft body dynamics, the expressions look like these:

A) if(f<99,0,2)B) if(f<99,1,2)

Conditions are an easy, but powerful means of creating all kinds of switches or triggers for applying functions. The best idea is to play a little bit with this useful feature and explore its possibilities. You’ll soon discover that you actually won’t be able to do without conditions, once you’ve understood the concept. In particular, dependencies from other nodes’ attributes can create complex, formula-driven animations.

e. complex Functions

Expressions can also contain complex formulas consisting of a chain of different functions. Just have a look at the following formula:

sin(3*t+exp(t/2))*0.2+sin(3*t-exp(t/1.2))*0.2*exp(t/4)



Introduction | 259

This function creates a curve with a base sine oscillation becoming denser and denser over time. The exponential part creates an overlapping oscillation with growing frequency and amplitude.

The graph of the function, printed above

Of course, such an expression doesn’t come out of the box. To get the desired results and range of values it’s necessary to have an idea of what the individual functions look like. Each part of the above term has its own special graph. Sine, cosine, and the exponential function always show the same curve. Factors can stretch or flatten the graph, or make it steeper, for example. Combinations of the different functions produce complex curves and it’s not always easy to find the appropriate values and factors to limit the results and avoid “exploding” values.

Fortunately the curve editor works like a function plotter making it much easier to optimize and adjust the factors, because you always have some visual feedback on how the curve is eveloving. The best workflow is to start with the basic functions and their combinations, and then add step by step:

1. sin(t+exp(t))2. sin(t+exp(t))+sin(t-exp(t))3. sin(t+exp(t))+sin(t-exp(t))*exp(t)4. sin(3*t+exp(t/2))*0.2+sin(3*t-exp(t/1.2))*0.2*exp(t/4)

This approach helps you to find out which part of the functions might be responsible for very high values and you can immediately limit them by multiplying or dividing with the appropriate value. The only thing you have to watch out for is bracketing, because parentheses have to be set following the basic rules of maths. It certainly takes a little

time and a certain amount of testing to get the desired behaviour, but after a few tries you’ll be able to get along with different functions and their range. It’s a good idea to have a play with the provided functions under

Insert > Unary functions

As you can see it’s not that difficult to use expressions. They’re a very fast and effective way to automatize certain animation tasks. In many cases it’s even better to use expressions instead of scripting, because you’ll benefit from multi-threading and multi-core systems. Even with the simplest script RealFlow will not use more than one processor, because Python is a single-threaded programming language. Please keep in mind that this limitation is Python-specific and has nothing to do with RealFlow’s ability to use more than one processor.



Introduction | 260

18 RealFloW plUG-INs

Plug-ins are a convenient method to extend ReaFlow’s functionality with the help of external add-ins. You surely know the plug-in concept from your own 3D software package or other applications. With RealFlow 5 we have released an appropriate SDK for C++ giving developers the option to write their own programs. A wide variety of ready-to-use examples can be found under RealFlow’s application directory. There you can see two folders named “plugins” and “sdk”. The second one contains a documentation with all available commands, libraries and C++ source code for some examples to get you started.

Installing a plug-in is as easy as adding a node to RealFlow’s viewport. It’s actually just a drag-and-drop action and the “plugins” folder is the place for it. You just have know whether your plug-in is a command, daemon, object, particle source or RealWave object. Once you’ve specified the appropriate type you can “throw” the program into one of the folders and with the next launch of RealFlow you’ll see the plug-in.

u In some cases it’s possible that you cannot see the installed program. The most common reason for this issue is the fact that some plug-ins might require the 64-bit version of RealFlow or they’re only available for a specific operating system.

18.01 Using plug-insDepending on the type of plug-in, it willappear in a different place inside RealFlow. Objects and daemons can be found in the Icon Bar under their menus. RealWave objects appear when you right-click on the RealWave node under the “Add Wave” menu. There you’ll see an entry called “Plugins”. Particle-based plug-ins appear under

Particles > Type

Plug-ins are seamlessly integrated in RealFlow’s user interface and act like any other node. They also have their own individual Node Params panels, providing specific functions and features. Since plug-ins are written in C++, they can make use of multi-threading and perform much faster than Python scripts.

18.02 Developing plug-InsThe development of plug-ins requires knowledge of a programming language, in this case it’s C++. To make use of RealFlow’s capabilities, Next Limits provides access to most of its internal functions. These functions are described and listed in a “Software Development Kit” (SDK). An SDK is more than just a list of descriptions. It also contains certain libraries, information about file formats and details about how to set up your programming environment. The mentioned documentation is, of course, also an essential element, because there you’ll find the functions and commands, needed to establish a connection to RealFlow.

The programming process itself is very similar to Python scripting and both languages share a lot of functions. So, if you’re already familiar with Python scripting, it’ll be much easier for you to find access to Next Limit’s SDK for C++. If you’re a beginner, then it’s a very good idea to have a look at the examples that come with RealFlow 5. We have created a bundle of plug-ins for you with different levels of difficulty, for a perfect introduction. Of course, this bundle cannot replace your own efforts while learning a new programming language, but it will definitely help you to understand the structures and the workflow of developing applications for RealFlow. You can take the examples and play with them, adding new values or changing the formulas. These easy modifications will give you an immediate feeling of success and you’ll soon aim for more complex tasks.

If you’re a programming novice it’s advised to read the introduction into Python scriptingbecause the basics about data types, variables and operators are valid for any language. Additionally, a plug-in is not always a new fluid solver, a complex daemon or a sophisticated modifier for breaking waves. Far from it! Most of the plug-ins you’re going to develop will be used internally and will provide solutions for repetitive tasks or very specific enhancements – for example, the introduction of a new object type.

18.03 provided plug-insOpen RealFlow and have a close look at the Icon Bar’s daemon menu. There you’ll find the “Plugins” section with two entries: CrowdFlow and Morph. These applications have been created by Ole Lemming, a RealFlow developer from Denmark, and they’re perfect examples for what you can achieve with the C++ SDK.



Introduction | 261

u You can find a wide variety of example scenes and video tutorials on RealFlow's resources and tutorials homepages. For more information and downloads, please visit: http://www.realflow.com/rf_support.php.

a. crowdFlow

The purpose of the CrowdFlow daemon is to allow the user to be able to create ”semiintelligent” fluids. The particles are capable of reacting to one another and to detectobstacles. The daemon has 3 modes:

1. Social forces2. Path following3. Obstacle avoidance

Social Forces: Control how the particles react to one another. There are 4 basic forces:

1. Alignment : Particles try to align with the average velocity vector of the neighbour particles

2. Cohesion: Particles try to get to the average position of the neighbour particles3. Separation: Repulsion force, primarily used when dealing with ”Dumb” particles4. Speed: The particles each receive an assigned speed, that they wish to uphold.

There are 2 types of particles; “leaders” and “followers”. The social forces (1, 2 and 3) arenot applied to the leaders.

“Path Following” makes the particles follow a path:

A) The leaders can generate paths that the followers then will follow. Paths can be shared between emitters. This menas the leaders can be in one emitter and the followers in another.

B) An animated object can be used to define a path that the particles will follow.

Obstacle avoidance: Particles detect and react to obstacles.

There are 3 quality settings: “Low”, “Medium” and “High”. This defines in how many directions the particles look when they check for obstacles.

Remarks:

• Obstacle avoidance slows down the simulation.• Decreasing the observation distance – Particles improves simulation speed, but limits

the radius of influence in the social force calculation.

Align Force factor which sets the value of the force returned from the “Align” function. Can be set to negative to create a misaligned force. “Align” is active when the neighbour particles are within the observation distance and the field of view.

Align speedMinimum speed for the align function. Neighbour particles with a speed below this value will be disregarded from the “Align” function.



Introduction | 262

Cohesion Force factor which sets the value of the force returned from the “Cohesion” function. Can be set to negative to create a separation force. “Cohesion” is active when the neighbour particles are within the observation distance and the field of view.

SeparationForce factor which sets the value of the force returned from the “Separation” function. Can be set to negative to create an attraction force. "Separation" is active when the neighbour particles are within one fifth of the observation distance and the field of view.

Speed >= 0: the ”Speed strength” force is applied to both increasing or decreasing speed in order to reach the specified speed.

< 0: the ”Speed strength” force is only applied to decrease the velocity of the particle in order to reach the specified absolute speed, Thereby limiting the max speed, but allowing the particles to slow down.

Speed Variation (0-1)Variation in speed of particles. A unique value is assigned to each particle.

Speed StrengthForce factor which sets the value of the force returned from the speed function, that tries to keep the speed of the particle at the specified value.

Observation Distance - ParticlesViewing distance of the particle for detecting other particles. The entered value must be greater than or equal to 0. Zero means no observation.

Observation Distance - ObstaclesViewing distance of the particle for detecting obstacles and paths. The entered value must be greater than or equal to 0. Zero means no observation.

Field of ViewField of view from the velocity direction. Values can range from 0 to 180. Particles outside this anglular space defined by FOV and Observation radius are disregarded.

Number of LeadersNumber of particles to be set as leaders (>= 0). Leaders are not affected by “Align”, “Cohesion” or “Seperation” functions. Leaders can be used for generating paths.

Leader generated Paths:Specifies whether or not leaders should generate paths, which the followers can follow.

Use Object Path

• “Use Object Path” = “No”: not active• “Use Object path” = “Yes”: uses the path of the named object. With ”Get path from

Object” you can specify a path the particles will follow. It can coexist with leader generated paths.

Get path from ObjectName of object to provide the path. “Scale.X” is used to set the local radius of the path.

Leader StrengthForce factor (>= 0) which sets the value of the force returned from the function that defines the way the leader particles behave. This works in a similar way to the speed function, but disregards the basic social forces and adds a random factor to the direction.

Path Follower StrengthForce factor (>=0) which sets the value of the force returned from the path follow function that applies to the follower particles when aligning to a path.

Path RadiusRadius of the path generated by the leader particles.

Path Radius VariationVariation (between 0 and 1) of the local radius in the paths created by leader particles.

Avoidance Leader StrengthForce factor (>=0) which sets the value of the force, returned from the object’s avoidance function, for seed particles. This function is active when the object is within the ”Observation distance - Obstacles”.



Introduction | 263

Avoidance Follower StrengthForce factor (>=0) which sets the value of the force, returned from the object’s avoidance function for following particles. This function is active when the object is within the ”Observation distance - Obstacles”.

Avoidance Minimum DistanceMinimum distance (>=0) for objects where the maximum avoidance force sets in. Avoidance force gradually increases from the ”Observation distance - Obstacles” until this distance from the object is reached.

Avoidance quality setting“High” looks in 8 semi-random directions one time per frame. “Medium” looks in 4 semi-random directions one time per frame and “Low” looks in 1 semi-random direction one time per frame.

3D“3D” activates 3D ForcesX=0 : X values of forces are set to zero.Y=0 : Y values of forces are set to zero.Z=0 : Z values of forces are set to zero.

b. Morph

The purpose of the morph daemon is to allow the user to be able to create morphing effects without having to resort to various tricks and workarounds, using multiple daemons and scripts. The daemon has two modes: “Approach” and “Cover”. Most of the parameters are only valid for the approach mode.

“Approach mode” controls how the particles approach the target object. Several options are available. The primary choices are ”Branching”, ”Max number of primary targets”, “Approach slope” and “Approach speed”.

“Cover mode” controls how the particles behave once they’ve reached the target object. The primary choice is ”Cover speed” that controls how the particles move around on the surface of the object. The other parameters control how the force normals of the surface are applied to the particles. Think of it as an attraction force.

Limitations:Using a hires object with lots of faces will slow especially the covermode considerably.In this situation it might also be necessary to switch the quality to ”High”, while a qualitysetting of ”Medium” is enough for most simulations. Improvements will follow.

Quality Setting “High” calculates forces once per substep, “Medium” calculates forces once per frame and “Low” calculates forces once every other frame.

Reset to Approach ModeThis mode can be turned on or off. The default setting is "Yes".

Target ObjectName of object to be used as a target for the morphing process. Works both with objects included or excluded from the Global Links list.



Introduction | 264

BranchingAllows branching during the approach mode. You can choose between “Yes” and “No”.

Branching LevelsSpecifies how many times branching is initiated:x = 0: no branching at all.

x > 0: branching is x-times initiated. At each branching a random amount of branches between ”Minimum branches” and ”Maximum branches” is created for each masterbranch. The morph approach is expanding into many branches.

x<0: works the other way around: Going from many branches down to the number of targets specified in ”Max number of primary targets”.

Minimum BranchesThe minimum number of branches created at a branch level for each masterbranch.

Maximum BranchesThe maximum number of branches created at a branch level for each masterbranch.

Approx Frames between BranchingSpecifies the approximate number of frames between each branch level.

Max number of Primary Targets Sets the number of target points in the target pool on the morph object:

x = 0: particles will pick the nearest point on the object.x > 0: the number of targets that is randomly generated on the object. Each particle will pick a target to approach.

When using branching this number specifies the number of primary targets rather than the total amount of targets.

Method of selecting TargetsRandom: particles pick a random target to approach from the target pool.Nearest: particles pick the nearest target from the target pool.By Texture: targets are positoned within the target zones given by white areas of the

texture applied to the target object. Particles pick a random target to appraoch.

Approach SlopeFactor that influences how the particles approaches the target: 0 creates straight path, values >0 create a more curvy path, aligned with the positive side of the surface normal. Values <0 also generate a more curvy path, aligned with the negative side of the surface normal.

Approach Speed:Speed of particle while approaching. If the speed of the target is higher than this, due to the target object being translated, the particles will not reach the target.

Approach Strength:Force factor (>= 0) which sets the value of the force applied for approaching.

Approach Strength – Outer BoundaryOuter boundary (>=0) of the approach force beyond which particles are no longer affected. The force decreases to zero from the inner boundary to the outer boundary. When set to zero, the boundary is infinite.

Approach Strength – Inner BoundaryInner boundary (>=0) of the approach force below which the force is 100 %.

Cover Texture ModeWith “None” the texture is not used to control the cover mode. “Position” uses the texture of the target object that is used for controlling the cover mode. White areas indicate areas where the particles should rest. Particles are not attracted to these areas, while in cover mode, but they can be found by chance. They then slow down to 1/10 of the specified cover speed and try to keep within the areas.

Animated objects with textures are also supported. “Strength” is a multiplier for scaling the texture’s cover strength. White signifies 100% and black signifies 0%. With “Both”, position and strength are controlled by the texture.

Cover Inner LimitDefines the distance from the morph object, within the parallel forces and velocity are 100 % which makes the particle move parallel to the surface. The parallel force and velocity gradually increase from 0 to 100 % between the outer and inner limit. The normal force



Introduction | 265

decreases from 100 % to 0 between the inner limit and the surface.

Cover Outer Limit Must be greater than “Inner Limit” and defines the distance from the object where the particle enter cover mode. For more information, please see ”Cover Inner Limit”

Cover Escape LimitIf the distance from the particle to the surface becomes larger than this value in “Cover” mode, the particle is no longer part of the morphing process and ”drips off”.

Cover Speed Speed of particle traveling across the surface of the target object within the inner limit and is relative to the object:

>=0: the force is applied to both increasing or decreasing speeds in order to reach the specified speed. Or: the force is applied to either increase or decrease the speed, in order to reach the specified speed.< 0: no force is applied and the particles flow freely across the surfaces.

Cover StrengthForce factor (>=0) which sets the value of the force applied for covering the morph object.

Cover Asymmetry0 means no influence, values greater than 0 scale the force on the side of the normal with this value. Values smaller than 0 scale the force on the opposite side of the normal with this value.

Cover Lock Position at Frame Default-1 means there won’t be any lock. Values greater then 0 lock the particles which are in “Cover” mode to the nearest point on the object at the current frame. The particles will then continously try to reach this point afterwards. The location of the point is updated dynamically during the simulation.

1 primary target (number of initial branches), 1 level, 2 branches. Each branch splits into multiple branches at each level.

1 primary target, up to to levels (negative - number 1 and 2), 1 - 2 branches. Branches merge into a smaller number of branches at each level.

1 primary target, 2 levels (number 1 and 2), 1 - 2 branches.

2 primary target, 2 levels (number 1 and 2), 1 - 3 branches.



Introduction | 266

19 RealFloW -NoGUI

So far the entire manual has been based on RealFlow’s graphical user interface, “GUI”, and all parameters were explained with the help of screenshots from the different windows and panels. All this helps you to create your project, but it’s not always necessary for simulation. In fact, RealFlow can be launched in two different ways:

1. In GUI mode, providing the well-known interface. 2. From a terminal application without an interface.

The first question coming to mind is: “Why do I need different versions of the same application?” The answer is easy: “Because of simulation speed.” The graphical representation of particles, objects, meshes and maps can be a heavy computational task, and always uses a certain amount of CPU power. Though RealFlow offers a variety of tools to speed up redrawing or viewport representations, a certain amount of processing power is always needed.The drawing of meshes, for example, can sometimes take longer than the real creation process. But even if you have disabled a mesh’s viewport representation, the user interface takes up resources. Resources you could use much better for increasing simulation speed. We’re not talking about a few seconds, but up to 30%.

Especially for batch simulations, side-by-side comparisons, large projects, different versions and so on, RealFlow’s “-nogui” version is the ultimate tool to get results much faster. You can start this version, for example with a shell or batch script, and simulate various projects overnight. You don’t have to monitor this process or wait until a project is done and start the next one manually. The entire simulation process is done automatically and you don’t have to worry about “FPS output”, “MAX substeps”, number of threads or anything else, because all these parameters can be adjusted individually while preparing your scenes. Then these projects are saved and simulated in RealFlow’s “-nogui” mode. You can also make use of your computer’s 64-bit mode.

u Experienced users know this mode as “Command Line” or “CMD”.

Each full, GUI-based license of RealFlow can be launched in “-nogui” mode and Next Limit also offers“Simulation Node” licenses without an interface. For more information, please visit Next Limit’s RealFlow homepage or contact our sales department.

19.01 starting “RealFlow -nogui”RealFlow’s home directory doesn’t show a particular application for launching the “-nogui” version. As mentioned before, it’s not a separate program, it’s just another way of starting RealFlow. The easiest way is to open a terminal window from your operating sytem (e.g. Bash, Terminal or Window’s command line – “DOS”) and call it from RealFlow’s directory. This is done with the “cd” command:

prompt> cd /Program files/Next Limit/RealFlow 5/

It is possible that your OS expects a certain notation for directories with blanks:

prompt> cd /Applications/"RealFlow 5"

With a “dir” (WIN) or “ls” (Linux/OS X) command you can list the directory’s content:

prompt> dir (or ls)

Now look for the RealFlow application and enter:

prompt/directory> realflow -nogui

prompt/directory> RealFlow.app/Contents/MacOS/realflow -nogui

Now RealFlow welcomes you with a typical message and shows a variety of options that can be used to start RealFlow. By entering “realflow -nogui” you’ve already used such an option, also called “flag”. These flags can be used to customize a simulation without having to alter the original project file. If you want to open RealFlow’s GUI version directly from the terminal, simply omit the “-nogui” flag.

There’s also a possbility to call “RealFlow -nogui” from any directory, such as your home directory. To achieve this, you should define a so-called environment path. In this case you don’t have to go to browse to RealFlow’s home folder and you simply enter:

prompt> realflow -nogui



Introduction | 267

Please check your operating system’s manual or help function about how to set an environment variable. The process of creating it is different for most systems and can therefore not be explained in detail here.

19.02 Using Flags“RealFlow -nogui” provides a wide variety of settings to customize a simulation. The most important option is “scenePath”, because it describes the “way” to a project file. If it isn’t set correctly, RealFlow aborts the simulation process. You have to be especially careful when your file is located on another volume or the folders contain blanks. Folder names with special characters should be avoided under all circumstances, not only in combination with RealFlow.

Under Windows a scene path could look like this:

prompt> realflow -nogui E:/RF5_Simulations/BeachScene_01/BeachScene_01.flw

And under OS X (“RealFlow.app/Contents/MacOS/” is not written here):

prompt> realflow -nogui /Volumes/RF5_Simulations/BeachScene_01/Beach_Scene_01.flw

It’s also often required to change the number of threads:

prompt> realflow -nogui - threads 8 scene path...

Another interesting option is called “mesh”. To use this feature it’s, of course, necessary to have an accordingly prepared scene: You need a complete project including at least one mesh node with appropriate settings and cached simulation data. The “mesh” flag does not create these entities for you, it only tells RealFlow to switch to meshing mode. The usage is the same as before:

prompt> realflow -nogui -mesh scene path...

With a shell or Python script it’s no problem to prepare several “RealFlow -nogui” calls and

batch simulate your scene over night, for example. It's a convenient way to run multiple projects without the need to monitor everything and start each process manually.

This is a list of all available flags:

Flag Arguments

nogui

help

license

mesh

useCache

threads Number of threads

range Start frame and end frame

log Path to the log file

idoc IDOC name

script Path to the desired batch script

The simulation process itself also shows a progress bar in the form of dots, but first the current license status is checked and the scene is initiated. Once the scene is calculated you’ll see a short status after each frame, similar to this example:

>16:35:07: Using 16 threads for this simulation..................................................>16:35:55: Frame 1 finished.

>16:35:55: Elapsed time: (0h0m48s)



Introduction | 268

20 RealFloW scRIpTING

Scripting is a perfect way of extending RealFlow's capabilities or develop your own customized solutions. For this purpose, RealFlow offers a Python interface which provides all necessary commands and functions to control most of the software's nodes, parameters and attributes. The description of such an interface is called Software Development Kit (SDK). There you can find all available commands together with explanations how to use them. RealFlow's Python-SDK is part of the internal Help Viewer and can be used directly within the application.

u “Python” and the Python logos are trademarks or registered trademarks of the Python Software Foundation, used by Next Limit Technologies with permission from the Foundation.

The official Python logo.

Python has many advantages:

• Easy to learn. Python is perfect for beginners, because the source code is easy to read and understand.

• Flexibility. Python is available for all operating systems and there are many free extensions.

• Active community. There are lots of developers who are constantly extending Python with new modules.

• Wide distribution. Python comes with all Unix and Linux operating systems, as well as with OS X. Of course, there’s also an easy-to-install version for Windows.

• Many resources. The web is full of Python resources and there are lots of very good books and publications for all levels of knowledge.

• Quasi-standard. Many 3D packages support Python, making it possible to directly access the data structures of a program. Maya, for example, introduced Python as an alternative to MEL. Over the years, Python has become the standard scripting language for many applications.

• Free license. Python is free, even for commercial projects.

All these advantages are good reasons for an implementation of Python into RealFlow. Python is a full-featured scripting language with support for modern structures, such as object-oriented programming, also called OOP, or hashes for fast search algorithms. It is also possible to establish database connections to store and administrate large amounts of data. Other packages offer functions for numerical calculations, image generation, and OpenGL support. There are also many modules available for 3D graphics and visualization Next Limit introduced a Python interface giving the user the ability to overcome many of the restrictions known from earlier RealFlow versions. With RealFlow 5 the entire Python distribution has been extended to support all the new features.

An often-discussed issue is Python’s inability to use more than one processor, also called multi-threading. Please be aware that:

• Python is single-threaded by default, but RealFlow is not. Python’s limitation has a direct effect on RealFlow’s simulation speed when scripts are involved.

• Executing Python scripts isn’t completely single-threaded. Computers and operating systems always use more than one core or processor, though it’s not possible to address them directly.

• Python provides some libraries for multi-threading support, but they only work on few platforms and in the worst case you have to recompile your Python distribution.

You can speed up Python scripts with effective programming and data structures. Ask yourself:

• Do I always need large lists or can I loop through my objects with a while statement? • Is there a point where I can empty a list and free memory? • Do I really need all global variables?• Is there unnecessary code within my script? • Are there ways to shorten or contract my code and statements?



Introduction | 269

20.01 python and RealFlowThis chapter starts with an obvious disadvantage: you have to learn a programming language to make use of RealFlow’s Python features. The good news is that Python strongly reminds of written English. Another reason for its good readability is the code’s structure – blanks and indents make it easier to follow a program’s listing. Unfortunately, these indents are a very common source of errors, but they're an important concept of Python.

The main question is what does scripting actually mean? Basically, a program or script is a list of instructions that’s executed to achieve a certain result. The instructions have to follow a certain directive, a logical sequence, which is called „syntax“. So what’s the difference between a program and a script? A program has to be translated into a “language” that can be understood by the computer. There are two methods:

1. Translating the code before execution -> Compiling2. Translating the code during execution -> Interpreting

Scripts are interpreted and that’s the main difference between languages like C or Java and packages like Python or Perl.

Since Python was not created for or because of RealFlow, the language does not have functions or instructions for fluid or dynamics simulation by default. The programmers at Next Limit had to develop certain modules and extensions to implement RealFlow’s set of instructions into Python. This is a very complex and heavy task, because the user needs access to almost all of RealFlow’s functions and data structures. The modules can be used to manipulate emitters, create custom force fields, modify rigid body dynamics parameters, work with RealWave surfaces, and control soft body dynamics features.

20.02 script Types and scripting WindowsScripts can handle different tasks and therefore it’s necessary to distinguish a few types. Within RealFlow there are three fundamental types:

1. Batch scripts

2. Event scripts3. Custom node scripts

Each of these types has its own editor window. Even if the windows appear different, they have some important similarities. The visual appearance of the scripting windows is controlled by RealFlow’s preferences, where you can adjust things like font type, syntax colours and folders for storing your programs (detailed information about the settings and their meaning are available on page 49):

Menu bar > File > Preferences > Script (WIN/Linux)

Menu bar > RealFlow > Preferences > Script (OS X)

Syntax highlighting is another important similarity. Whenever RealFlow detects an instruction or known function in your code, it will be coloured. For all scripting windows, RealFlow provides auto completion. This function helps you to complete a statement with the help of a drop-down menu. It appears when parts of a command are recognized and allows you to choose the desired function.

20.03 common settingsRealFlow provides a couple of different scripting windows for all purposes. They share a common menu bar, consisting of four entries. The contents can vary a bit, but the functions outlined below are valid for all script editors.

The mode of operation is also common to all scripting windows. Syntax highlighting and auto completion, as well as the adjusted fonts and colours, are general features and do not depend on a certain script type. The difference lies in how the scripts are executed, when they are executed, and their predefined functions.

u You can customize syntax highlighting under RealFlow's Preferences which are also directly accessible from the File menu (see below).



Introduction | 270

a. The File Menu

This menu provides everything you need for organizing your scripts in terms of opening and saving. RealFlow batch scripts wear the extension RFS ("RealFlow Script"), PY ("Python") or DLL ("Dynamic Link Library"). DLLs are a special case, because it’s possible to load compiled DLLs, but they can’t be executed – only ASCII-style files are allowed.

NewEverything that‘s visible on the editor’s canvas will be cleared and you can start again with a fresh script. If your script hasn’t been saved yet, RealFlow will suggest to save it first. SaveTo save the script to disk, please use this function.

Open...You can easily load and open scripts with the file picker. When RealFlow opens a script, it doesn’t check if the content is plausible or even contains a Python script, because that’s up to you. As long as the file content is readable for RealFlow, it can be loaded in the editor.

Save As...Especially with scripts it’s often required to store intermediate versions or tests. It's also a good idea to make backup copies of your scripts. Batch scripts must always be stored before you decide to close a project, because they're not saved with a scene and must be saved externally. Once you've close the Batch script window, the program is lost. The usage should be familiar: just assign a new name to each version and store it with “Save As...”.

Scripting Preferences...With this entry you can directly go to the appropriate section of RealFlow’s Preferences and adjust things like colours or fonts. There's a detailed description of the various functions with RealFlow's scripting editors on page 49.

b. The edit Menu

“Edit” provides everything you need for a fast workflow while writing scripts. Nevertheless you should be a little careful when pasting scripts from other sources, because of indents and leading spaces. You can also see powerful functions for finding and replacing words or phrases here.

Undo/RedoBoth actions exactly work as usual.

Cut/Copy/PasteThese three commands are available with all programs and operating systems, and shouldn’t need further explanation.

DeleteTo use this function it’s necessary to mark a section of a script first. Once you have selected the appropriate paragraph, you can remove it with “Delete”.

Select AllIf you want to mark the entire script without exception, then please use this function.

Find...This is actually a “find-and-replace” function. Calling “Find...” opens a new window with several options to search for certain word or phrases and you can replace them with a



Introduction | 271

single click, as you can see from the image below:

Find nextYou can look for the next appearance of a word without having to open and use the “Find...” option again.

ReplaceA marked section in your script can be replaced with a certain phrase or word, located under “Replace with” from the “Find...” window.

Shift Right Text/Shift Left TextIndents and leading spaces are very important concepts in Python. The first option works similar to the Tab key on your keyboard, the second one removes a tab.

c. The script Menu

This menu gives you some basic tools to check and execute the currently loaded script, and is especially useful for debugging.

ClearThis function works similar to “New” from the File menu, but without asking you whether you want to store the script. You cannot undo this action.

Show SuggestionsTo show commands that could match the currently entered phrase, choose this option. Normally, this is done automatically, but if you’ve turned off the auto completion function, you can still call it manually from here.

RunStart your script with this command and watch it working...

Check SyntaxThis is a very important feature for debugging. Before the script is executed you can check if there are any errors or undefined variables. Especially copied/pasted scripts from other sources should go through a syntax check.

d. The Help Menu

RealFlow also offers an extense help system for Python scripting, offering a complete reference for all commands, as well as individual help for single keywords.

Show RealFlow Scripting Reference...This function calls RealFlow’s Help Viewer and directly branches to the built-in Python reference, where you can find out more about all commands available.

Show Selected Keyword InfoTo make use of this convenient function it’s not necessary to mark an entire word, because RealFlow automatically detects start and stop. So you only have to place the cursor somewhere “inside” a command and choose this feature to display the available information.

20.04 Batch scriptsBatch scripts are perfect for all kinds of automated processes. Whether you want to run



Introduction | 272

part that’s only executed at the beginning of the simulation and another one that’s applied at each simulation step. These types of “split” scripts are often used to initialize a scene or reset values to defaults, and then perform the actual calculation.

Menu Bar > Layout > Simulation Events (Ctrl + F2)

The first impression shows a split window. The upper part consists of a tree with 3 higher-ranking entries:

1. SimulationPre2. Frames3. SimulationPost

“Frames” also carries a little “+” or “-” symbol, indicating that this menu can be expanded or collapsed. The branches of the tree are where you can place your own scripts and directly determine when they’ll be executed. This tree also represents the internal hierarchy:

several scenes over night, automatically create scenes complete with emitters, daemons, and objects, randomly modify dynamics parameters of large amounts of objects, or run through all existing nodes and change names or export properties – in all these cases batch scripts are the adequate choice. For this purpose, RealFlow even provides a specific window reserved exclusively for batch type scripts:

Menu Bar > Layout > Batch Script (F10)

The new window can be attached to your own layout. Please note that batch scripts are not saved with the current project and you always have to store them separately on your hard disk. It’s a good idea to either find a common place for all batch scripts or create special directories under the project’s file and folder structure.

20.05 simulation eventsEvents scripts are always connected to a certain project and stored directly with the scene. They can also be saved as individual files and used for other scenes, but in this case they normally have to be adapted. Events are start and end of a simulation or the beginning of a new time step or frame. Scripts are not limited to one of these events. You can write one



Introduction | 273

A. Simulation > B. Frame > C. Step

Simulation events can carry more than one script. It’s possible to add one or more scripts for any event that wears a “Pre” or “Post” suffix. The scripts can be appended by choosing the desired event, e.g. FramesPre, and right-clicking on it. This action opens a context menu with some entries:

The first menu in the previous image shows the entries without any attached scripts. The second menu also provides a “Remove” function to delete existing scripts from the tree. By clicking on “Add Script” a new editor window is opened and a new entry becomes visible in the pipeline, similar to the ones in the image on the right.

This name is generated automatically and has a successive ID. Of course, it’s possible to change this name to a more project-related label. To do so, close the script editor and double click on the name to make it editable. You can now enter a new description. With this pipeline you always have an overview of which scripts are called at a certain event, but that’s not the only advantage: You also no longer need very long and extended scripts, because you have the possibility to put each function into an individual script and reuse it somewhere else. Another strong feature is that it’s possible to shift script nodes from one event to another. In situations where it’s better to start a calculation after a frame has been finished instead of executing it before, you don’t need to copy and paste the scripts. You can simply drag the desired script from “FramePre” to “FramePost” and that’s it.

To work with the selected script, either double-click on its name or use the editor below. If you want to delete a script, simply click on “Remove”. Please note that a removed script is not stored, unless you have saved it manually before from the script editor. The script editor itself provides a few basic operations under its menu bar. Detailed explanations for these functions can be found on page 270 and after.

To run a simulation without a certain script, it’s not necessary to delete it. You can just set it to inactive by unticking the appropriate checkbox.

RealFlow's tree for events scripts.

Once a script has been stored, it can be used again and again. You can also load a script from another source, e.g. RealFlow’s scripting homepage. With “Add Script From File” a script can be imported. Please keep in mind that external scripts usually have to be adjusted to your needs and nodes. A completely new function is the “Add From Plugin” option. With this method it’s possible to choose a custom plug-in from the Command Plugins manager–, where you’ll find all available plug-ins. The “Expand All” button simply expands all branches from the scripts pipeline marked with the “+” symbol.

The lower part of the events window shows a “Master” tab together with a menu bar, consisting of four entries. These menus are exactly the same as described on page 269 “Common Settings”. This section was added for compatibility reasons, because Python scripts from RealFlow 4 used a different structure with predefined functions. You can still use the “Master” section in RealFlow 5, but it’s recommended to write and organize scripts with the new tools. Next to “Master” there’s another tab containing an empty editor. By default it’s named “None Selected”, but when you choose a script from the tree, you can edit it there, instead of constantly opening and closing separate windows.

The execution of a simulation events script can be very time consuming, depending on the complexity of your script and the performed calculations. You’ll also see a significant drop in simulation speed with scripts, mainly with events scripts (Python is single-threaded).



Introduction | 274

20.06 scripted NodesWhen you have a close look at the available emitters (page 100), daemons (page 140), and RealWave modifier (page 213), you’ll notice options like “Custom” or “Scripted”. This means that you have the option to write your own fluid emitters, apply your own forces, and calculate your own RealWave surface displacements.

Emitter > Node Params > Particles > Type > Custom

Available daemons > ScriptedRealWave node > Right mouse button menu > Add Wave > Scripted

These different nodes have one thing in common: the “Edit” button. By clicking on this button, a new script editor will be opened which contains specific functions for each node type - it’s not possible to mix or change these functions. For example, the “updateWave( vertices, initPositions )” function should not be used inside a scripted daemon’s editor and vice versa.

Wave sequence, generated from displacement maps.

With the custom particle type you’ll be able to define your own fluid emitter and its behaviour. The function calculates the forces between the individual particles and applies them to the fluid. For this purpose there is the “computeInternalForces( emitter )” function.

The scripted emitter is not a type of its own, like scripted daemons. It’s a special particle type that’s available with any emitter. You can choose from “Gas”, “Dumb”, “Elastic”, “Liquid” – and “Custom”:

Node Params > Particles > Type > Custom

This implementation is much more convenient than completely customised emitters, because you don’t have to create a certain shape for the particles to be generated from. You can use any available emitter type and shape, and only change the particle type.

Since forces between particles only affect the fluid and nothing else, this option is strictly limited to emitters. Scripted daemons, on the other hand, can either affect particles and rigid bodies. The difference is that you’re going to introduce external forces which can act like RealFlow’s standard forces, for example gravity. With a scripted daemon you can model your own force fields, such as vortices or falloffs. The great advantage with this type is that they can be treated like any other daemon. In other words: you can make them exclusive to certain nodes or (de-)activate them at a certain point in time, for example. Scripted RealWave modifiers are also possible and with RealFlow 5 an important change has been introduced. In former versions it was only possible to calculate vertex displacement along the surface’s height axis. This limitation has been removed, so you’re now free to perform calculations for all three axes. This extension helps you to create completely customised wave types, for example breaking waves, with Python scripting. One of the best applications of scripted waves is the translation of an image’s grey scale values into height information. With this method you’re able to create wave simulations out of a sequence of images. There’s a detailed explanation for this kind of script on page 319 and a series of pictures can be found on the left.

The number of scripted nodes is not restricted and the only limitation affects RealWave, because you can only have one object per scene, but you can (at least theoretically) apply as many scripted modifiers as you want to the surface. Scripted emitters will work and interact with all the other solvers and particles. They can also be affected by both scripted and built-in daemons.

20.07 “Hello World”Programming novices often feel like they don’t know where to start. Basically there are two ways to get started. Firstly, you can take pre-existing RealFlow scripts and deconstruct them. With this method it’s possible to learn many things about the mode of operation of certain functions and how they work in more or less complex environments. The other method is to start with the fundamentals of a programming language and learn the basic rules. With this method it’s much easier to write your own scripts very fast, because you have a deep understanding of the correlations between the various elements of a script.



Introduction | 275

You will probably already be familiar with the famous “Hello World” script from other languages. This program is often used to give the new programmer a feeling of success. With Python for RealFlow this approach isn’t really suitable, because it only deals with the output of some text and does not affect any of the special features of fluids or objects. However, it’s probably worth using the good old “Hello World” tradition anyway, so let’s start by applying this script:

1. Open a batch script window with F10 or from the Layout menu2. Enter the following lines of code:

text = "Hello World!"

scene.message(text)

3. Execute the script with Script > Run4. Open the message window and look for the output

The result most probably looks very similar to this image:

u Please note that the scene.message() statement only works inside RealFlow. If you’re programming with the standard Python interpreter, you have to use the print() command.

As you might have noticed, it wasn’t necessary to start a simulation and you didn’t need any objects. The reason is pretty obvious - you didn’t manipulate any nodes, but just created a text output and sent it to the message window. Though this example is very simple, it already shows important concepts of a programming language – the usage of variables. It also gives you an important insight: with batch scripts it’s not necessary to start a simulation.

Before you start writing your own programs it’s recommended to adjust RealFlow’s scripting preferences. A complete and detailed explanation of all settings can be found on page 49. You can change preferences here:

Preferences > Script

The most common source of errors with Python script is incorrect tabbing. The Python standard makes it clear: the Tabstop size must be always 8, but such a big tab size is virtually impossible to use, so you will most probably end up with Tabstop sizes of 2 or 4. The “Expand Tabs” under Preferences will let you forget about this mess as long as you don’t care about tabs being replaced by blank spaces. Since blanks and indents are an important feature of Python, it makes a great difference whether you’re writing your code like this:

emitter = scene.getEmitter("Circle01")

particle = emitter.getFirstParticle()

while (particle):

mass = particle.getMass()

density = particle.getDensity()

scene.message("Mass: "+str(mass)+" :: "+"Density: "+str(density))

particle = particle.getNextParticle()

or this way:



while (particle):


density = particle.getDensity()

scene.message("Mass: "+str(mass)+" :: "+"Density: "+str(density) )


The second code snippet won’t work at all, because the leading indents are not correct. It’s also important which type of blank or tab you’re using, and you’re not allowed to mix spaces and tabs. You should always use the tab key and never the space bar! Only with tabs can you be certain that you’re always using the same method and number of blanks.



Introduction | 276

When you load scripts from other sources, for example forums, you have to be especially careful. In 3rd party scripts some of the tabs are often converted to blanks. This has to be fixed before the program is executed. Another issue that can be come up is an empty line with a tab or a few blanks at the end of scripts. This line must be removed, because it always leads to syntax errors. Following this rule is an easy method to avoid and eliminate many of the common problems.

20.08 scalar Variables u The following examples can be executed directly within RealFlow’s batch script

editor. The results will be written to the Messages window. To execute a script choose Script > Run from the batch window’s menu.

If you take a closer look at the “Hello World” example, you can see that the “text” object is highlighted in red. This object is also called a variable. A variable is a placeholder and this special case is called a scalar. A scalar can only store one value. Please have look at this line again:

text = "Hello World"

The variable’s name is “text” and the value is “Hello World”. The quotation marks indicate that the value is a string – a series of characters. Everything inside the quotation marks is treated as a single value, though it may consist of more than one word. So here, the scalar condition that only one value can be assigned is fulfilled. If you want to assign a number as a value, then no quotation marks are needed, e.g.

number_value = 25

You can also define the number as a series of characters without its numerical meaning:

number_string = "25"

With such a variable it’s not possible to perform mathematical calculations. An example:

number1 = "25"

number2 = 25

result = number1 + number2

scene.message(result)

The output in RealFlow’s Messages window:

>WARNING: Script error: “cannot concatenate ‘str’ and ‘int’ objects” at line number 3.

As a result you would normally expect “50”, but here you receive a syntax error, telling you that it’s not possible to calculate a meaningful result from a word and a number. It’s like trying to solve this equation:

Steve + 25 = ?

Such a calculation simply makes no sense, but in the example above that’s exactly what the script tries to do. Therefore you'll get an error. Anyway it's possible to connect numbers and characters, for example to print out a result. This is called concatenation (see p. 258).

It’s also very important to know that values have to be assigned and introduced before they can be used. A script like this one won’t work, because the variable is used before a value has been assigned:

scene.message(text)

text = "Hello World"

It’s also possible to assign a blank or zero value to a variable just to introduce it:

initial_mass = 0

name = ""

Another issue with variables is naming. A variable’s name should only be used once, unless you want to overwrite the previously assigned value, because only the latest assigned value will be used.



Introduction | 277

This example changes the previous value and writes out 0.05:

friction = 0.01

friction = 0.05

scene.message(friction)

Naming does not only include double names, it’s also about using significant names and descriptions. The first issue is the range of available or allowed characters. You should never use any special characters like %, &, §, ä, Å, É or similar glyphs. These characters are not correctly interpreted and only lead to trouble or errors. The situation gets even worse with conversion between different operating systems. The best method to avoid these problems is to restrict variable names to a limited set of characters:

[ A - Z ], [ a - z ], [ 0 - 9 ], the hyphen [ - ] and the underscore character [ _ ]

Another issue is that variables are case sensitive. In Python “friction” is not the same as “Friction”. A variable must keep its name over the entire script and must not be changed. Lastly you have to avoid using full stops (periods) with names under all circumstances. Dots are an element of the Python scripting language, so you can‘t use them with variable names. You’ve already seen the dot with the message statement:

scene.message("Hello World")

Now have a look at this example:

a = "Mauritius"

b = "Pineapple"

c = 1200

d = 3.99

Formally that’s absolutely correct, because there’s no rule that a variable must have more than 1 character, but it’s not really clear what all these values should express. It’s much better to use meaningful names. Imagine a script with dozens of variables – with a notation like the one above it’s not easy to find out their sense. Even if you’re the author

of the script, you’ll probably have trouble indentifiying the variables after a few weeks or even months.

This example is much clearer:

origin = "Mauritius"

fruit = "Pineapple"

weight_in_g = 1200

price = 3.99

20.09 list VariablesScalars can only store a single value, but there are many cases where this is simply not enough. For this purpose, Python offers another type of variable that’s comparable to a container: lists. Lists can contain a series of different mixed values. “Mixed” means that it’s possible to store numbers and strings within a single list. Dependeing on the number of entries, a list allocates much more memory than a scalar. The important thing with lists is that entries are ordered. Each value has a fixed place that’s connected to the number, representing its position. The position itself is up to you and you’re free to determine the order, but once you’re referring to a certain element in the list, the order should not be changed anymore! Regarding naming you should follow exactly the same rules as with scalars.

An empty list is introduced with a single statement. First, you have to find a variable name:

my_first_list = [ ]

If you want to fill the list with entries, it’s necessary to differentiate between numbers and strings again. Strings are written within quotation marks, while numbers are just typed in as they are:

fruits = ["Pineapple","Mango","Banana","Papaya","Orange“,"Coconut"]

prices = [3.99 , 1.50 , 2.00 , 1.20 , 0.49 , 2.60]



Introduction | 278

To achieve direct access to the elements of the list, you simply count through the entries starting with 0. It’s important to keep this mind, otherwise you’ll always get the wrong result. To extract a single element in the list you have to use the following syntax:

fruits = ["Pineapple","Mango","Banana","Papaya","Orange","Coconut"]

my_favourite_fruit = fruits[4]

scene.message(my_favourite_fruit)

In the case the result is “Orange”

Python internally assigns the following values: Pineapple = 0, Mango = 1, Banana = 2, and so on. So the list’s third element is “Banana”. But it’s not only possible to find elements by their index, you can also search through the list to find a certain element by its value:


my_favourite_fruit = "Papaya"

if (my_favourite_fruit in fruits):

scene.message("Your favourite fruit is in stock")

else:

scene.message("Sorry. Your favourite fruit is not available")

A list is not a static structure that’s fixed, once it’s created. You can append and delete certain entries with simple instructions:


new_fruit = "Kiwi"

fruits.append(new_fruit)

And the code for deleting an entry:


out_of_stock = "Mango"

fruits.remove(out_of_stock)

Something that’s often used with Python and RealFlow is the number of elements within a list. In many cases you have to check whether or not there are already list entries to execute a certain function, and Python has a solution for this. Here the result is 6:


number_of_entries = len(fruits)

scene.message(str(number_of_entries))

You can see a new instruction in the example above: “str”. This operation translates the numerical value into a string, so it can be printed to the message window. When there are numbers inside a list, it’s possible to extract certain values, assign them as variables, and perform calculations with them:

prices = [3.99 , 1.50 , 2.00 , 0.49 , 1.20 , 2.60]

price_a = prices[2]

price_b = prices[5]

price_total = price_a + price_b

scene.message(str(price_total))

Result: 4.6

20.10 Dictionary VariablesDictionaries are another way to store multiple values, but they work differently from lists. With dictionaries you always store a key-value pair. This makes it possible to store the elements without a certain order. In other programming languages this structure is also called hash or associative array. Inside RealFlow, dictionaries are rather rarely used, but there might be some applications where you have to use them - for example when you want to find a certain object by its mass. To identify an element it’s no longer necessary to find a certain index, it’s enough to identify them with the key:



Introduction | 279

my_first_dictionary = {"Pineapple":3.99,"Mango":1.50,"Orange":0.49,"Coconut":2.60}

To find a price for a certain fruit you can use this instruction:

fruits = {"Pineapple":3.99,"Mango":1.50,"Orange":0.49,"Coconut":2.60}

price = fruits["Coconut"]

scene.message(str(price))

Result = 2.6

It’s also possible to append elements to a dictionary:

fruits = {"Pineapple":3.99,"Mango":1.50,"Orange":0.49,"Coconut":2.60}

new_fruit = "Banana"

new_price = 2.00

fruits[new_fruit] = new_price

With the “len(variable)” statement it’s again possible to read out the number of entries. Please note that this operation prints out the total number of key-value pairs, not the entire number of individual elements.

20.11 Global and local VariablesModern programming languages differentiate between two fundamental types of variables: Global and local. The difference lies in the way the variables are stored within your script. Local variables, as the name indicates, only actlocally inside a function. (To read more about about the definition of functions, please go to page 296, “Custom Functions”.). A function always starts with a def statement and can be considered as a closed code segment. With simulation events scripts, these functions are not directly visible, because you cannot see any predefined functions in the editor, as with scripted emitters or daemons. The editors for emitters, waves and daemons all show an initializing function, e.g.

• def setInternalForce( emitter )• def updateWave( vertices, initPositions ):• def setExternalForce( emitter )• def setExternalForce( body )

Directly below this statement your code begins. Whenever you’re writing a variable to such a section it’ll be treated as local. This means that it cannot be transferred to other functions. The variable is only stored and used within the actual function. You don’t have to mark or tag a variable as local – Python automatically treats a variable as local, independent of it’s type. So all the variables from the previous examples and code snippets are local variables. With global variables it’s different. They can be used over the entire script, multiple functions and even different script types, such as daemons.

Since they have to be stored permanently, global variables also allocate more memory. A local variable is used and forgotten, once the function has been executed and the memory freed up. To distinguish global variables from local ones, they have to be introduced with a special form:

scene.setGlobalVariableValue(string, any)

The string is substituted for the variables' name and has to be written within quotation marks. The second argument is the variable’s value, which can be any type, e.g. an integer or a vector. When there’s a set command then there has to be a get instruction, too. As always with get statements, the value has to be stored with a variable. So a complete constructor for global variables could look like this:

velocity_vector = Vector.new(1.0, 1.0, 1.0)

scene.setGlobalVariableValue("velocity", velocity_vector)

new_velocity = scene.getGlobalVariableValue("velocity")

new_velocity_y = new_velocity.getY()

scene.message(str(new_velocity_y))

Another way to use velocity_vector with a global variable is to write it directly to the definition without introducing a local variable first:



Introduction | 280

scene.setGlobalVariableValue("velocity", Vector.new(1.0, 1.0, 1.0))

Of course, lists are also allowed:

scene.setGlobalVariableValue("nodes", ["Sphere01","Circle01","Camera01"])

With very long lists it’s better to define them separately:

node_list = scene.getSelectedNodes()

scene.setGlobalVariableValue("selected_nodes", node_list)

The definition and assigning of global might appear a little bit cumbersome, but it’s an effective method. The only thing is that you have to do is to keep track of the global values, because it’s not allowed to define a local or another global variable with the same name somewhere else. You've already heard that variables must always be unique, except if you want to overwrite the previously assigned value(s). Another important issue is the circumstance in which the value of a global variable turns local, once it’s called with scene.getGlobalVariableValue(). In this case the global value is stored as a new variable, as you can see from the example above:

new_velocity = scene.getGlobalVariableValue("velocity")

Here, “new_velocity” is local, while "velocity" is still global and can be used elsewhere.

It’s also possible to perform calculations with global variables and store them again globally:

scene.setGlobalVariableValue("age", 24)

age = scene.getGlobalVariableValue("age")

age = age + 1

scene.setGlobalVariableValue("age", age)

In this example, the age value is overwritten with a new value and the result is stored back to global variable again.

Global variables are a very effective way to share values with other parts of a script and make use of them without needing to assign the variables again and again. With very large lists stored in global variables we recommend that you check whether a global definition is really needed, to reduce the amount of allocated memory. In Python tutorials you’ll also often find a certain notation:

global rigidbody_mass

This way of introducing global variables is also valid, but it’s better to stay with RealFlow’s internal method, because it’s tailored to its special requirements.

20.12 operatorsOperators are needed to perform calculations and comparisons. We can distinguish between four basic types in RealFlow. Without operators it wouldn’t be possible to make additions or multiplications, or compare different velocities, for example. The standard operators are

Addition 15 + 17 = 32Subtraction 64 - 30 = 34Multiplication 10 * 12 = 120Division 80 / 10 = 8Exponentiation 12 ** 2 = 144Modulus 28 % 7 = 0String concatenation “John” + “Doe” = JohnDoeString repetition “Hi” * 3 = HiHiHi

The next group of operators are used for comparisons:

Less than <Greater than >Less than or equal <=Greater than or equal >= Equal ==Not equal !=



Introduction | 281

Equality is tested with “ ==”. The single “=” is just used for assignment, e.g. in variable names, as shown many times before.

if (current_position_y >= 2.2):

do something

A third group is called Boolean operators:

and or not

They are mostly used to perform multiple comparisons, e.g.:

if (mass >= 100 and friction == 0.001):

do something

if (velocity >= 5.0 or velocity <= 10.0):

do something

The last class are augmented operators. This is a very special class and mostly used for cases where you have to sum up values. There are instructions like this one:

while (particles):

particle_mass = particles.getMass()

total_mass = total_mass + particle_mass

In this example, the script loops through all particles and sums up their individual masses to get a total mass value. With an augmented operator this could also be written as:

while (particles):

particle_mass = particles.getMass()

total_mass += particle_mass

The most common augmented operators are:

+= -= /= *= **= %=

Python knows a few more operator types, but they’re not often used with RealFlow scripts. As you can see, operators work exactly as you know from school. They resemble basic operations, and you’ll definitely need to use them frequently. You also might have noticed that operators do not contain mathematical functions, such as sine, square root or tangent. These functions are part of another class and treated separately.

20.13 Data TypesData types are a sort of classification, helping you to subdivide values into groups. They can also be seen as a data storage format containing a specific type or range of values. These types can be numbers – with or without a floating point, vectors or strings, for example. When computer programs store data in variables, each variable must be assigned a specific data type. Some programming languages can automatically assign a variable’s data type when the initial data is entered into the variable. Python is one of these languages.

a. Integer

Data types are another important concept. When you’re writing your own scripts you’ll soon see that there are many different types, for example strings, integers, vectors. Having a look at the Python online reference you’ll constantly come across these types with descriptions of functions:

• setFps(int)• getDaemon(string)• getNeighvors(float)• getEulerAngles(vector)

The terms between brackets are the data types. This means that setFps(int), for example, only works with an integer number and is not allowed to work with other data types, like strings. A string in combination with frames per second wouldn’t make any sense:



Introduction | 282

setFps("Circle Emitter")

Instead you have to use a number and it has to be an integer, because there are no half or quarter frames. A frame is always a “complete” number:

setFps(24)

Integers are surely the easiest data type, as they only consist of numbers – no fractions like ¾ or ½, or things like 3.14159. Since integers can be very large, Python offers three different types:

1. The 32-bit integer (int) ranges between ± 2,147,483,6482. The 64-bit integer (int) ranges between ± 9,223,372,036,854,775,8083. The long integer (long) has infinite precision

b. Float

Floats are similar to integers, but they can also include decimal fractions. Float means that the numbers always have a decimal part separated by a dot. The number of decimals is also called precision, e.g.

5.8656345-332.8463463463753646

Normally you don’t need very high precisions for your calculations and two or three decimals will be enough in 99% of all cases. Floats and integers can be used together and the result is always a floating number:

value1 = 5

value2 = 3.6222

result = value1 – value2

scene.message(str(result))

Result: 1.3778

If an instruction expects a floating number and you want to enter a value of exactly 2, for example, then you really have to type in a floating number, not an integer:

getNeighbors(2.0)

Floating numbers can be translated into integers and vice versa, but there might be a problem with precision, because the decimals will be truncated, leaving only the integer part:

int(7.57634) = 7 or int(6.99999) = 6

c. Boolean

Some RealFlow instructions can only work with a Boolean type. In combination with RealFlow there are only two possibilities: True and False. This data type is comparable to a switch. Such a switch can either be on (true) or off (false). There are no other states between, and that’s exactly the way Boolean types work:

setAddToGlobalLinks(true) or setAddToGlobalLinks(false)

d. Vector

This is certainly the most difficult data type, because a vector consists of more than on value. The individual compontents can be integers or floats. In 2D space a vector is represented by two values:

vector = (X, Y)

TThese values are actually nothing more than coordinates, but the most obvious problem is surely how to calculate with such a data type? Before this question is answered, it’s a good idea to clarify the term “vector” first. A vector can be seen as an arrow, pointing in a certain direction. To describe a vector’s direction, we‘ll need at least two dimensions: X and Y. By drawing a vector into a coordinate system, we get the main properties: Direction and magnitude. The direction tells you which way the vector is pointing, while the magnitude is the length of the arrow.



Introduction | 283

If you consider gravity as a vector, the direction would be vertical and its magnitude or length would be the strength of gravity at a certain point. Since gravity is not constant, you’d have to draw a new arrow or vector at each measuring point. The result is a so-called vector field.

2D vectors with different length and orientation.

The graphical illustration is useful to get an idea of what a vector is, but currently it doesn’t seem to tell us very much about how to calculate with vectors. How can we perform operations with arrows? Well, the first thing is to tell you a few things about notations. RealFlow is a 3D program, so we have to introduce a third coordinate and instead of “vector”, we’re just using letters. The letter is the variable in this case! Each 3D vector consists of X, Y and Z coordinates. These coordinates can be any positive or negative number, including zero. So a complete vector could be written as:

a = (X, Y, Z)

That’s basically enough, but with more vectors we have to index the X, Y and Z coordinates somehow. So a better notation would be:

a = (ax, ay, az)b = (bx, by, bz)

Each coordinate ax, ay, az is called a scalar. Vector calculations can be performed by either using the individual scalars or the vector’s magnitude (or length). There are some basic operations you should know.

Vector addition

c = a + b(cx, cy, cz) = (ax, ay, az) + (bx, by, bz)(cx, cy, cz) = (ax + bx, ay + by, az + bz)

In this case all a components are added individually with their b counterpart and the result is again a triplet of scalars, resulting in vector c.

Vector subtraction

c = a - b(cx, cy, cz) = (ax, ay, az) - (bx, by, bz)(cx, cy, cz) = (ax - bx, ay - by, az - bz)

This operation is the same as the previously discussed vector addition. Again, you receive a vector c consisting of three scalars.

scalar product or Dot product

c = a * bc = (ax, ay, az) * (bx, by, bz)c = (ax * bx + ay * by + az * bz)

This operation can be considered as the multiplication of vectors. As with the previous examples, all components are multiplied individually with their appropriate counterpart, but here the coordinates are also added. The result is again a scalar, not a vector.

A special case is the square of a vector:

c = ax2 + ay2 + az2

By extracting the square root, “sqrt”, you’ll get the magnitude or length of a vector, which is a scalar:

m = sqrt(ax2 + ay2 + az2)



Introduction | 284

Multiplication With a scalar

c = a * s(cx, cy, cz) = (ax, ay, az) * s(cx, cy, cz) = (ax * s, ay * s, az * s)

In this case there’s only a single value, a scalar, that’s simply multiplied with each coordinate as factor. The scalar s can be any positive floating or integer number, including 0.

cross product

c = a x bcx = ay * bz - az * by cy = az * bx - ax * bz cz = ax * by - ay * bxc = (cx, cy, cz)

This operation is more complex and therefore split into three lines for the individual components of the resulting vector. The cross product is very common with physical formulas dealing with natural phenomena. Many forces, for example the Lorentz force in magnetic fields, are calculated with the cross product.

Vector Division

The division of two vectors like c = a : b is actually not defined and therefore not possible by default. But you can divide a vector by a scalar, in just the same way you’ve seen before under “Multiplication with a Scalar”.

c = a / s(cx, cy, cz) = (ax, ay, az) / s(cx, cy, cz) = (ax / s, ay / s, az / s)

or:

c = a * 1 / s(cx, cy, cz) = (ax, ay, az) * 1 / s(cx, cy, cz) = (ax * 1 / s, ay * 1 / s, az * 1 / s)

RealFlow provides a method for dividing two vectors, but the result does not always make sense and is not really suitable for calculating certain forces.

Since some vector calculations are rather time-consuming to write and often lead to unwanted mistakes, RealFlow offers ready-to-use implementations of these rules. With them it’s possible to perform vector calculations like any other algebraic operation. These are the vector operators:

• Addition a + b• Subtraction a - b• Dot product a * b• Multiplication with a scalar a * s• Magnitude a.module()• Cross product a.cross(b)• Division a / b

20.14 accessing RealFlow NodesEach node inside RealFlow, regardless of whether it’s imported or native, can be accessed with scripting. The nodes are stored in variables to make their attributes accessible. That’s the only way in which parameters and settings can be altered using scripting. From such an object, stored in a variable, it’s possible to call selected attributes. These attributes are the ones you can find under a node’s Node Params window. It’s important to bear in mind that all objects and properties follow a certain hierarchy that’s part of Python’s notation. The highest ranking element is the RealFlow scene. Once an object has been added to a scene, it’s considered as a part of it, for example a circle emitter. The next thing is that each node has an individual name - in this case it would be “Circle01”. With a so-called “get” method we can access the emitter:


This could be read as: “Get the Circle01 node from the current scene and store it in the emitter variable”. In this case, the emitter variable is a scalar, because there’s only one value stored. RealFlow provides special get methods for each basic node. You can see them on the following page.



Introduction | 285

object = scene.getObject("object name")

daemon = scene.getDaemon("daemon name")

camera = scene.getCamera("camera name")

mesh = scene.getMesh("mesh name")

wave = scene.getRealwave("wave name")

The names are simply the particular names from the node window. If the name inside the brackets and the affected node name are not identical, a syntax error will occur. Please note that they always have to stand within quotation marks, unless you’re using a variable to define the name:

object_name = "Vase01"

object = scene.getObject(object_name)

or

object = scene.getObject("Vase01")

It’s not possible to get emitters with “getObject()” or meshes with “getRealwave()”, and so on. Each method is restricted to a certain object type. From the notation above you can see that the emitter “Circle01” is part of the scene. Following this idea, one could also say that the parameters are part of the emitter, for example position:


position = emitter.getParameter("Position")

With this construction you can access the position of the object that’s stored under emitter: “Circle01”. If you take alook at the position parameter, you can see that it consists of three coordinates X, Y and Z. A variable with three coordinates or scalars is called a vector (see page 289). If you want to read out or manipulate the individual values of the position vector, you have to follow the known concept:



position_x = position.getX()

position_y = position.getY()

position_z = position.getZ()

Now the X, Y and Z position values are stored in individual variables and they’re ready to be used for further calculations and manipulation. This concept is valid for all the other node types in RealFlow, e.g. cameras or objects.

20.15 accessing particlesEmitters represent a special case, because they’re actually nothing more than a container or source for particles. Since there’s normally more than one particle, a list is required to store them. Scalar variables are not able to catch all the different values. A particle can be seen as an element of an emitter and the idea is to gather all particles first. With an adequate method it’s possible to go through the particles and access their attributes. Such a method is called a loop:



while (particle):

do something here, e.g. read out the current particle’s position


So what’s happening here? First, the emitter is picked from the scene, then the script starts with the first particle. As long as there are particles in the scene, RealFlow loops through them. After the calculation of the current particle is completed, the script goes on with the next particle and the while-loop starts again.

The particles themselves also have certain attributes – each particle has a particular velocity, mass or position, for example. These properties are very special and that’s the reason why they have their own methods to access them. If you remember the position



Introduction | 286

query of an emitter object, then you’ll see that you had to write this:


With particles it’s different:



while (particle):

position = particle.getPosition()


You could now, for example, print out the position of each particle with the scene.message command. In this case, you have to type the script’s code to an simulation events’ script window, for example under the FramesPost function:



while (particle):


scene.message(str(position))


The result is a little bit strange, because we have to deal with a vector. In the messages window you can see something like this:

<RealFlow Vector object at 0xf74218><RealFlow Vector object at 0xf74140><RealFlow Vector object at 0xf74218>

Vectors are coded within RealFlow and if you want to print out the scalars you have to determine the values individually as seen on the right.



while (particle):


position_x = position.getX()

position_y = position.getY()

position_z = position.getZ()

scene.message(str(position_x)+" / "+str(position_y)+" / "+str(position_z))


Now the output is clearly readable:

0.320292592049 / 0.439999759197 / 0.2396094650030.250641554594 / 0.439999759197 / 0.311735242605

u The position of the “particle.getNextParticle()” statement is of special importance. If it’s not inserted correctly, the loop won’t stop and will RealFlow freeze.

Another concept of accessing and looping through an emitter’s particles is the “for ... in“ method. In this case the currently existing particles are written to a list. With a continuous stream of particles this list grows larger with every frame and allocates more memory. Because of the higher memory demand the “for … in” method is often restricted to a certain number of particles. One of the most common approaches is to detect particles colliding with objects. A loop with “for … in” with an events script may look like this:


all_particles = emitter.getParticles()

for single_particle in all_particles:

do something here

The “all_particles” list contains a 1:1 copy of all currently existing particles in your scene and you can loop through them. But sometimes you will only want to restrict operations to a certain amount of particles, maybe the first 1,000 particles. For this purpose, it’s possible



Introduction | 287

to set a certain range with a start, stop and step value.


all_particles = emitter.getParticles()

for single_particle in range(0,999,1):

current_particle = all_particles[single_particle]

do something here

This structure reads out the first 1,000 particle (0-999) from the all_particles list. As you have learned before, particles in a list always have an index. Each entry has its own number assigned and these numbers can be accessed. The loop goes through numbers from 0 to 999 successively in steps of 1. This number is then used to create an index addressing the list, e.g.

current_particle = all_particles[7] or

current_particle = all_particles[749]

The “for … in” and “for … in range” methods are not limited to particles. A list object doesn’t care whether there are particles, objects or vertices stored inside. So these loops can be used with any node, polygon, result and anything else you have inside a list.

Loops are one of the most important methods with RealFlow scripts, especially when you have to deal with particles. There’s always a situation where you have to go through all of, or a certain amount of, the particles or objects. For this reason it’s highly recommended to become familiar with all different kinds of loops.

20.16 conditionsIn daily life we always have to make decisions and most often we don’t really think about them. Making a decision means that there’s always at least one alternative we could have chosen instead. The entire process is based on certain factors or parameters we have to evaluate to make the final decision. With programming the process is just the same. You have to distinguish between different conditions, which will influence the way the script

finally goes. For this purpose, programming languages recognise a construction called “if and else“. You know this from your own daily experience:

“If the weather is fine, I go out for a walk, if not I’ll stay at home and read a book.”

That’s exactly the way “if-else” works. If a certain condition is fulfilled, the script follows a given route to achieve a desired result. If the condition is not satisfied, the program has to follow another path. A very nice example for this type of decision-making is planning a holiday trip. This is something where you really have to consider many things, because holidays depend on so many factors: your partner, money, destination, time, personal preferences, the hotel, airline and so on.

The first question is whether you can afford a certain destination or not:

my_money = 1500.00

accommodation = 930.00

flight = 410.00

leisure = 200.00

if (accommodation + flight + leisure <= my_money):

destination = "Norway"

else:

destination = "Ireland"

scene.message(destination)

In this example you have to find a total price. This can be done by adding up the individual entries with a “+“ operator. Then we have to compare the result against the available amount of money with a “<=” operator. If the total amount is smaller than the available amount of money, the destination will be Norway. Since Norway’s too expensive (930.00 + 410.00 + 200.00 = 1540.00), it’ll be Ireland.

It’s also possible to make a comparison like the follwoing:



Introduction | 288

my_money = 1500.00

birthday_gift = 200.00

total_costs = 1555.00

if (total_costs <= my_money + vacation_benefit)

or vice versa:

if (my_money + birthday_gift >= total_costs)

With Boolean operators we can make decisions based on more than one factor. Boolean operators, as we already mentioned, being “and”, “or”, “not”. Please have a look at this example:

total_money = 1700.00

favourite_hotel = "Holiday Inn Stockholm"

total_costs = 1540.00

if ((total_costs <= total_money) and (available_hotel == favourite_hotel)):

destination = "Sweden"

else:

destination = "Belgium"

The little script above tests for two parameters. If both conditions are fulfilled the destination will be Sweden.

The nice thing with “if” and “else” is that you can compare against variables, values and calculations. This property makes them very flexible and versatile, and you’ll soon find out that if and else constructions are very often needed. There’s almost always a case where you have to differentiate and follow a new path. But sometimes it’s not enough to define these simple “if-else” constructions and you need more options.

Lets assume you want to choose a destination based on a certain month. You just typed in a certain number representing a month and the script chooses the appropriate country for you:

if (input == 4):

destination = "Italy"

elif ((input >= 5) and (input < 8)):

destination = "Hungary"

elif ((input >= 8) and (input <= 10)):

destination = "Cyprus"

else:

destination = "Oh no! I have to stay at home..."

scene.message(destination)

The “elif” statement means “else if” and can be used as often as required, while “if” and “else” can only be used once within a “if-else” construction. But, of course, you’re able to place as many if-else conditions in your script as you want. Another issue is that it’s mandatory to use an “if” condition, but “else” and “elif” are optional. This code snippet is a correct and complete instruction:

input = 3

if ((airline == "National Airways") and (flight_price >= 750.00)):

available_destinations = ["Finland","France","Germany","Poland","Spain"]

selection = available_destinations[input]

scene.message(selection)

It’s also allowed to build nested “if-else” constructions for even more differentiations. In such a case it's a good idea to make appropriate comments to keep the overview.



Introduction | 289

if (my_money >= total_costs):

if (airline == "National Airways"):

destination = "Slovenia"

elif (airline == "Best Fly"):

destination = "Austria"

else:

destination = "Switzerland"

else:

destination = "I obviously have to stay at home!"

With “if-else” conditions it’s possible to cover any situation and case, go to a certain routine or calculation, call a new function, or even exit a script. You can differentiate between various values and results, and make the desired decision to achieve a certain result.

20.17 Building VectorsIn RealFlow vectors are an important data type. All parameters with three values can be considered and described as vectors – even RGB colours. They also consist of a trio of values and therefore each RGB colour can be treated as vector. The most important vectors in RealFlow are:

• Velocity• Position• Rotation• Forces

If you want to manipulate the individual X, Y and Z values you first have to deconstruct the original vector. The instruction for this operation is “get[axis]()” and is appended to the appropriate vector as seen before on page 285. With this operation a vector is split into its scalar components and can now be used for further vector calculations, e.g. multiplication a scalar:

new_velocity_x = velocity_x * 0.5

new_velocity_y = velocity_y * 1.3

new_velocity_z = velocity_z * 0.7

To use these values again, e.g. for setting the new velocity, they have to be assembled to a completely new vector. This vector should also be stored into a variable:

new_velocity_vector = Vector.new(new_velocity_x, new_velocity_y, new_velocity_z)

The key instruction is:

Vector.new(float, float, float)

It expects three floating numbers (called an argument) and these values are represented by the “new_velocity_[axis]” variables. RealFlow puts everything together to create a new vector that can be applied to the particle in the next step. You’ll soon learn how to set and apply such a vector or other new parameters to a particle or node. A vector doesn’t necessarily need three completely new values and you can also mix different types. The following example contains a fixed float, a new result, and an existing vector from the particle’s original velocity.

new_velocity = Vector.new(1.0, new_velocity_y, velocity_z)

You’re also able to perform calculations directly within the new vector’s argument. That’s a very good method to shorten your scripts, unless you have to use the new_velocity_[axis] values somewhere else in your program. With this notation you can skip the assignment of three variables and save memory.

new_velocity = Vector.new(velocity_x * 0.5, velocity_y / 2, velocity_z + 1.4)

A RealFlow vector always consists of three values, regardless whether you need them for your calculations or not. If there are components you don’t need, you can set the appropriate value(s) to 0.0:

new_height = Vector.new(0.0, height * 2.5, 0.0)



Introduction | 290

20.18 changing attributesSo far, we have been talking about standard data types, how to build loops and call individual particles, and the way you can differentiate between options with if and else. You’ve also learned how to create a new vector and heard something about the “get” statement. With “get” you’re able to directly access certain values and parameters, such as position, rotation, mass, friction or even particle-based properties, like density or velocity. That’s an interesting feature, because you can read out the values, store them in lists, vectors or scalars, and perform different kinds of calculations with them. But that’s only one half of the story, because there has to be a way to assign the new values back to the relevant object or particle. For this purpose, RealFlow knows the set statement. “Get” and “set” often appear together, but they’re not necessarily linked. Some of the “get” statements you’ve seen so far are:

• string getEmitter()• string getObject()• string getParameter()• vector getPosition()• vector getVelocity()

The syntax of “set” is pretty much the same as with get statements. The list of get instructions is relatively long, but fortunately the concept behind this function is rather easy and for some statements there’s a counterpart with “set”:

float getDensity() -> setDensity(float)

vector getVelocity() -> setVelocity(vector)

int getFps() -> setFps(int)

Regarding the “getParameter()” and “setParameter()” instructions, the concept is a little bit different, though. The parameters are exactly the ones you can find under Node Params (see page 23) and written as an argument – this means that it will be enclosed within the brackets. Just prepare an easy scene with an emitter and an internal object, and open the object’s Particle Fluid Interaction panel (see page 149). There you can find many of the object’s properties and they can easily be translated into get and set statements, because you simply have to use the property’s name.

An example:You want to read out an item’s particle friction and increase it with each frame. The best idea is to first read out the initial value. Lets say you have added a vase here. The script you are using is a simulation events type and located under FramesPost.

increment = 0.001

vase = scene.getObject("Vase01")

particle_friction = vase.getParameter("Particle friction")

new_particle_friction = particle_friction + increment

vase.setParameter("Particle friction", new_particle_friction)

scene.message(str(new_particle_friction))

As you can see it’s not necessary to introduce any counters or loops for increasing the parameter. This is done automatically with each new frame. Another thing you will surely have noticed is a fundamental difference between the “get” and “set” statement:

1. With get you always have to store the result in a variable (new_particle_friction).2. With set you don’t need this construction, but you have to use another argument:

("Particle friction", new_particle_friction)

The first argument, “Particle friction”, is the affected parameter and “new_particle_friction” is the value the script should apply. The Particle Fluid Interaction window is updated with each frame and shows the new rounded value, the exact result is printed to the Messages window.

Of course, the parameters are not restricted to Particle Fluid Interaction panel – you can choose them from any section under Node Params. The code from above is nothing more than an example. You can change almost any of RealFlow’s parameters with scripting. It’s not only possible to write new values as numbers (integers, vectors or floats), you can also use strings or Boolean values. That’s mostly necessary for parameters which are not numbers, for example the dynamics feature under Node. Even this parameter can be influenced with scripting. In the following code segment, “Dynamics” is set from “No” to



Introduction | 291

“Rigid body” at the beginning of the simulation (SimulationPre):

obj = scene.getObject("Vase01")

obj.setParameter("Dynamics", "Rigid body")

With Boolean values it’s a bit different, because they don’t need any quotation marks. You can toggle between true and false:

obj.setParameter("Visible", False)

A very important issue concerns vector parameters and compatibility with RealFlow 4. Whenever you have to deal with individual components of a vector, a certain notation is required which is new to RealFlow 5. As already mentioned, a vector always conists of a trio of values:

Position = [ 5.0, 2.3, 1.6 ]

In case you want to set the values with an appropriate attribute, you have to use the following syntax in RealFlow 5

node.setParameter("Position.X", 5.0)

node.setParameter("Position.Y", 2.3)

node.setParameter("Position.Z", 1.6)

The interesting thing is the dot “.” between attribute and component - that’s the main difference to RealFlow 4. There, a dot wasn’t necessary, soif you want to use older scripts, this notation has to be adapted, otherwise you’ll receive an error message.

20.19 changing particle attributes When you’re working with particles, the get and set instructions are slightly different. A node’s parameters are always called with the getParameter(string) command, but particles don’t have attributes like friction, rotation, or roughness. They are described with density,

position, velocity, viscosity, and so on. To distinguish these settings from a node’s basic properties, the attributes can be accessed directly with appropriate functions:

vector getVelocity() -> setVelocity(vector)

With particles you don’t need an introducing argument specifying the desired parameter, because that’s already implemented in the statement and you only have to hand over the value with the correct data type. Some properties, like velocity, normals or positions, are not only valid for particles. The “getVelocity(vector)” statement can be used for objects and vertices, for example, but it’s not possible to apply “setVelocity(vector)” to an object.

By using "get" you can read out a lot of values and attributes, but the corresponding list of set instructions is rather short. Most of a particle’s attributes either directly influence the solver’s stability, or it simply makes no sense to change them on a per-particle base. These are the four attributes you can directly change with “set” instructions:

setExternalForce(vector)

setPosition(vector)

setUV(vector)

setVelocity(vector)

The “get” commands, such as “getDensity(float)!” or “getNeighbors(float)”, are actually only used for comparisons or to trigger other functions and routines:

# Write this part to Simulation Events > Frames > FramesPre

frame = scene.getCurrentFrame()


if (frame == 125):

emitter.setParameter("Speed", 0.0)

# Write this part to Simulation Events > Steps > StepsPre



Introduction | 292

total_mass = 0.0



while (particle):

pressure = particle.getPressure()


total_mass = total_mass + mass

if((pressure >= 50) and (total_mass >= 2000)):

new_velocity = Vector.new(0.0, 0.0, 0.0)

particle.setVelocity(new_velocity)

else:

pass


The particles in this case behave a little bit like liquid wax that’s cooling down and the zero velocity statement gives you an interesting effect.

20.20 custom attributesAnother exciting and very useful feature is the definition of particular attributes, created by the user. There are many cases where it’s necessary to add an attribute that’s not part of RealFlow’s Python interface by default. To make use of this function, RealFlow offers a couple of new instructions, exclusively valid for emitters and particles:

• Emitters: createParticlesAttribute, destroyParticlesAttribute, queryParticlesAtrribute• Particles: setAttribute, getAttribute, queryAttribute

The first step is to create a particle attribute and this action requires two arguments. The first one is a unique “name” in form of an integer, the other one’s the expected data type.

Allowed types are:

PARTICLE_ATTR_TYPE_DOUBLE, PARTICLE_ATTR_TYPE_INT, PARTICLE_ATTR_TYPE_BOOL and PARTICLE_ATTR_TYPE_VECTOR

So, first of all it’s necessary to create an attribute for an emitter which will then be applied to a particle:

# Write this part to SimulationPre


emitter.createParticlesAttribute(100, PARTICLE_ATTR_TYPE_DOUBLE)

emitter.createParticlesAttribute(101, PARTICLE_ATTR_TYPE_INT)

emitter.createParticlesAttribute(102, PARTICLE_ATTR_TYPE_BOOL)

emitter.createParticlesAttribute(103, PARTICLE_ATTR_TYPE_VECTOR)

# Write this part to FramePre


particleList = emitter.getParticles()

for particle in particleList:

particle.setAttribute(100, 3.14159)

particle.setAttribute(101, 5)

particle.setAttribute(102, True)

particle.setAttribute(103, Vector.new(1.0,0.0,1.0))

During simulation you won’t recognize any effect, but it’s possible to call these attributes and use them for further calculations or conditions. The advantage is that you can either leave the attribute’s value untouched or assign a new one with each frame or simulation step – that’s up to you.



Introduction | 293

To request an attribute, simply use the following construction:

for particle in particleList:

pi = particle.getAttribute(100)

scene.message(str(pi))

You can also remove an emitter’s ability to carry attributes with a destructor. Please note that this is not possible for single particles, but for certain attributes:


if (frame == 50):

emitter.destroyParticlesAttribute(102)

Finally, there’s the query instruction. With these commands it’s possible to check whether a attribute is set or not, and the result is a Boolean value: “True” or “False”. To start a query for an emitter, this syntax is used:


flag = emitter.queryParticlesAttribute(102)

if (flag):

scene.message("This attribute exists!")

For a requesting a particle’s attribute, everthing has to be inside a loop again. In this example it’s a while-loop:



while (particle):

if (particle.queryAttribute(100)):

scene.message ("This attribute exists!")


20.21 affecting particles With DaemonsScripted daemons are a very powerful means to affect particles or introduce custom forces. The scripted types work the same way as their native equivalents. The only restriction is that they cannot be bounded with an appropriate switch. Boundaries have to be programmed to your own specific requirements. On the other hand it’s no problem to make them exclusive to certain nodes or combine them with other built-in daemons. Scripted daemons have their own scripting window with special predefined functions to either affect particles or bodies, or remove particles from the solver without losing stability.Introducing a force that acts on particles or bodies requires a certain statement. This function expect a force vector consisting of three floating numbers – just like any other vector in RealFlow:

setExternalForce(vector)

The following example creates a daemon with an exponential falloff dependent on the particles’ age and velocity to decelerate them over time. The main part includes the exponential function, which is not part of the default Python distribution. All these functions, such as sine, cosine, square root and so on, are implemented in a external module that has to be imported. The module is called “math” and can be called with

import math

To make use of the available functions, a well-known notation is used, as shown here. The “(int, float)” statement tells you that both integer and floating values are accepted:

math.sin(int, float)

math.cos(int, float)

Another thing to consider is axis setup. The deceleration should only affect the particles along the vertical axis, but since different software packages use different axes for height, it’s necessary to distinguish between the preferences. To evaluate the currently used axis setup, RealFlow provides a function:

getAxisSetup()



Introduction | 294

The result of this function is an integer between 1 and 3. 1 stands for YXZ (Lightwave and Cinema 4D), 2 represents ZXY (3D StudioMax and Maya) and 3 indicates YZX (XSI, Maya and Houdini). With a simple if-else construction it’s no problem to find out the correct direction.

To apply the program, a scripted daemon is needed:

Menu bar > Edit > Add > Daemon > Scripted

Toolbar > Daemon > Scripted

Right-click menu (Viewport/Nodes) > Add Daemon > Scripted

Once the daemon has been added click on

Node Params > Edit

The new window contains a predefined function called “applyForceToEmitter( emitter )”. This function applies the forces introduced by the script to all emitters without defining them separately. Here’s the script:

def applyForceToEmitter(emitter):

import math

strength = 1.5

daemon = scene.getDaemon("Scripted01")

axis_system = scene.getAxisSetup()


while(particle):

age = particle.getAge()

vel = particle.getVelocity().module()

falloff = (math.exp(-age * vel)) * strength

if (axis_system == 1):

force_vector = Vector.new(0.0, falloff, 0.0)

else:

force_vector = Vector.new(0.0, 0.0, falloff)

particle.setExternalForce(force_vector)


The strength variable in this little script works like a drag force. By extending the script for X and Z (or X and Y), you’ll also able to create deceleration in all three dimension – even with different strength settings for each axis. The value is simply multiplied with the exponential falloff. The new force vector is – as already mentioned – dependent on the adjusted axis setup. The script affects all particles in the scene and you don’t have to declare them separately with a “scene.getEmitter(string)” command. That’s one of the basic principles with scripted daemons and also valid for objects, grid fluids or mist particles, but in this case the code has to be located under the appropriate function, e.g.

def applyForceToBody(body)

There are also some other functions you can see under a scripted daemon’s editor. These functions are called before, during or after a simulation, and help you to initialize a scene or define global variables, without having to use an additional simulation events script.

20.22 shifting particlesOne effect that’s based on get statements is particle shifting. This method is widely used for all kinds of effects, for example foam generation from traditional emitters. With grid fluids this special way of creating spray is obsolete, because it’s already implemented through various emitter types (see page 76 and the following).

The idea behind particle shifting is to find a certain condition when particles will be shifted from emitter A to emitter B. This makes it possible to render one emitter as a fluid and the second one as spray, to give an example. The advantage is that the shift is completely seamless and there are no visible gaps between the particles. The transaction is normally



Introduction | 295

triggered by comparing a parameter against a threshold value. It’s very important that both emitters share equal resolutions, otherwise the particles might explode. Another prerequesite is that the receiving emitter’s speed is 0.0, since it should not produce any new particles.

u Particle shifting can also be done with the new container emitter and filter daemon. With this built-in and ready-to-use combination you can achieve the same effect, but sometimes it’s better to implement the transition from one emitter to another with a script. The container emitter is explained on page 113.

# Type this part to Simulation Events > Scene > ScenePre

# Initialize the container emitter before starting the simulation

source_emitter = scene.getEmitter("Source")

source_resolution = source_emitter.getParameter("Resolution")

container_emitter = scene.getEmitter("Container")

container_emitter.setParameter("Interpolation", "Local")

container_emitter.setParameter("Resolution",source_resolution)

container_emitter.setParameter("Speed", 0.0)

# Write this part to Simulation Events > Steps > StepsPre

velocity_threshold = 3.0

source_emitter = scene.getEmitter("Source")

container_emitter = scene.getEmitter("Container")

source_particle = source_emitter.getFirstParticle()

while (source_particle):

source_particle_vel = source_particle.getVelocity()

source_particle_magnitude = source_particle_vel.module()

source_particle_id = source_particle.getId()

if (source_particle_magnitude >= velocity_threshold):

source_particle_pos = source_particle.getPosition()

container_emitter.addParticle(source_particle_pos,source_particle_vel)

source_emitter.removeParticle(source_particle_id)

source_particle = source_particle.getNextParticle()

Now, what’s going on here? The basic structure and syntax should already be familiar, though there are few new functions. The very first part initializes the container emitter. You may remember that it’s crucial that both emitters share equal resolution and the container’s speed must be 0.0. Equalizing the resolution is a pretty easy task, but it’s recommended to change interpolation to local, as you perform a change of resolution. The script just reads out the resolution value from the source emitter and uses the result for the container. Resetting speed to 0.0 is even simpler, because you just have to set the parameter to the desired value. Here it would also be possible to insert an “if”-condition:

container_emitter_speed = container_emitter.getParameter("Speed")

if (container_emitter_speed != 0.0):

container_emitter.setParameter("Speed", 0.0)

This means that if the container emitter’s speed is not 0.0 then you need to reset it. This query is not really necessary here, but similar constructions might be useful for other tasks where you have to reset speed or other parameters, or limit them to a certain value. The second part of the script is executed during a time step. First you have to find a certain threshold value. This threshold triggers the particle’s transition to the container emitter. The next step is a basic loop through all of the source emitter’s particles. As long as there are particles, the script constantly checks whether the velocity_threshold value is exceeded or not. For this purpose the script does not check against each individual value of the velocity vector, because this wouldn’t lead to reasonable results.



Introduction | 296

Here, the magnitude of the velocity vector is used. The magnitude is not a vector, but a single floating number, which is much easier to handle and can be extracted with:

source_particle_velocity = source_particle.getVelocity()

source_velocity_magnitude = source_particle_velocity.module()

The vector’s magnitude is then compared with the threshold value and, if the condition is true, the script reads out the affected particle’s ID to identify it. Another important parameter is the particle’s position here, because it’s necessary to restore it to the same position when the particle has been shifted to the container. In the next step, the script removes the particle with the appropriate ID and applies it to the second emitter with the original position and velocity. That’s necessary to keep the fluid stable.

Foam simulation with an advanced multi-state particle shifting method.

The threshold value could also be any other parameter, even a value from a third emitter, or even the velocity of an object - you can establish any dependency.

20.23 custom FunctionsCustom functions are a very convenient way to enhance the readability of your code and introduce independent code sections for executing certain parts of a script. You may remember the predefined functions from scripted daemons:

def setExternalForce( emitter ):

Such a definition of functions is not limited to RealFlow’s internal structures. You can also create your own functions and call them. A function can be seen as closed code segment that will be executed on demand. It consists of four elements:

1. The “def” statement. This tells Python that there’s an executable code segment.2. The functions name, e.g. “force_calculation” or “node_creation” etc.3. The argument “()”. The argument can consist of one or more variables handed over

from other functions, but in many cases it'll be empty.4. The function’s Python code.

If you don’t want to hand over argument variables then you can also make use of global variables. Without these methods, variables will only work on a local level and won’t be stored when jumping to another code section. A “def” statement also acts like a jump label. It’s possible, for example, to link the execution of different functions to a GUI window’s input. Just create a list you can choose from and jump to the appropriate function based on the user’s choice. If you want to read more about the creation of GUIs, please go to page 298.

options = ["Emitter","Camera","RealWave"]

window = GUIFormDialog.new()

window.addListField("Add to scene", options, 0)

your_choice = window.getFieldValue("Add to scene")

if (your_choice == 0): createEmitter()

if (your_choice == 1): createCamera()

if (your_choice == 2): createRealWave()

def createEmitter():

do something here...

def createCamera():




Introduction | 297

def createRealWave():


Another important field of application is to outsource repeating parts of a program. Just imagine a script where you have to open a file for reading and writing at different positions of your script. Instead of adding the code for opening the file again and again, it’s much more efficient to pack everything into a function and call it on demand. With a “return()” statement at the end of the function you can directly jump back to the last position. Similar to a function's argument, the return statement's brackets can also contain variables you want to hand over to the calling section of the script, but you can also introduce global variables instead.


# call the function

openFile()

go on doing with doing something...

def openFile():

do something new here...

return()

One of the most often used custom functions can be seen with batch scripts. It’s used to execute a batch script properly, especially when it’s called from the Scripts Bar. The main function can be seen as a self-reference to run the batch script and it’s aways a good idea to enclose batch scripts within this function, even if it’s the only one.

def main():

execute your code here

if __name__ == "RealFlow":

main()

20.24 Using ModulesA module is an external extension that can be loaded to a script. It can be seen as a plug-in. Many of them already come with the official Python distribution; others have to be loaded and installed manually. For Python, there are many modules available for all purposes, but how is it possible to find out what has already been installed? The easiest way is to directly call the Python interpreter from a terminal. Linux and OS X have easy access via Bash or the Terminal application. Open a shell editor, e.g. Bash, and type:

prompt> python

A message shows you the currently installed version of Python and a >>> prompt. At the prompt just enter “help(‘modules’)”:

Screenshot from a terminal application with listed modules under OS X.

It takes a little time, but then you can look for “random” and “math”. These two are probably the most often used modules.



Introduction | 298

Python makes it very easy to load a module to a scene. Within your script you only have to type “import” and the name of the appropriate module:

import random

“Random” has a lot of features to generate different kinds of random numbers, strings or even ranges and the functions can be used in Python’s typical notation:

random.random() Creates a float between 0 and 1.random.randint(a, b) Creates a random integer between a and b.random.uniform(a, b) Creates a random float between a and b.random.choice([list]) Picks a random number/element from a list.random.randrange(start, stop, step) Creates a random range between start and stop.

The other important module is math. Python isn’t capable of using functions like sine, cosine or square root. They’re all provided by this extension and have to be imported:

import.math

Similar to the random module, the “math” prefix has to be written to a function before it can be executed:

math.sin() math.cos() math.sqrt() math.exp()math.tan() math.sinh() math.cosh() math.log()

The math module doesn't only provide trigonometric and power or logarithmic functions. There are also functions for angular conversions and the constants Pi and e included. For complex numbers you can call

import cmath

If you have to load more than one module simply import them one after the other. With the PYTHONPATH environment variable it’s also possible to specifiy additional search paths. This is useful for 3rd party Python modules, because they don’t have to be installed under Python’s default directory, but can be anywhere on your harddisk. The creation/modifiaction of environment variables is different for each operating system, so please have a look at your system’s help documents.

20.25 creating Graphical User Interfaces (GUIs)RealFlow’s Python implementation provides a series of instructions to create your own windows with menus and options. These windows can be used to enter your own settings or leave default values. The settings are then passed to a script which is able to process these data and feed the formulas. The advantage is that you don’t have to change the script each time you want to alter one or more values, because everything can easily be done inside a custom tailored window.

To apply a customised window you have to follow some global methods and rules. Once you’ve understood the basic concepts, the creation process for GUIs and windows is always the same, and should become routine with growing experience. One of these rules concerns data types. They’re really essential for this purpose and you should consider reading the appropriate section on page 281. In “normal” scripts, RealFlow was always able to automatically detect the data type and there was no need to introduce them separately, like

int number_of_entries = 10

float friction = 0.005

With GUIs and windows the situation is completely different, because you have to specify the correct data type now, and then RealFlow will check the entered data for plausibility. The reason is that Python/RealFlow always expects particular data types for certain functions. It’s simply not possible to fill a vector’s individual scalars with strings. Such kind of vector creation is invalid and directly leads to an error message. You can either enter integers or floating numbers – and that’s it. A notation like this isn't possible:

Vector.new("red", "orange", "blue")

RealFlow GUI’s are not only capable of opening a window, you can also create your own error messages and make use of file and node pickers. The most common application is definitely to enter custom values and this requires three steps:

1. Setting up the GUI window with all input fields and the definition of various data types2. Transferring the data from the window to variables3. Assigning the variables



Introduction | 299

A GUI can be opened either from a batch script or a simulation events script. In the latter case the GUI can only be started at the beginning of a simulation, not during a running process.

a. Initializing a GUI

This chapter deals with the first step described above. To create a window, RealFlow needs a certain statement to initialize a new GUI window. All the other statements are always related to this instruction:


The type of window you’ll get with this instruction is what is known as amodal window. Modal windows always have the operating system’s focus. This means that it’s not possible to access other windows, menus or functions of RealFlow as long as the GUI window is open. The next step is to define the appropriate data type. You can use as many input fields as you want, but adding a field obeys some basic rules, too. Each field requires two arguments: the field’s individual name and the default value. If the user doesn’t want to make entries, RealFlow has to know which setting will be used for the following script.

These are the constructors for the different data types and input fields:

window.addIntField(string, int)

window.addFloatField(string, float)

window.addVectorField(string, float, float, float)

window.addStringField(string, string)

window.addBoolField(string, boolean)

window.addListField(string, string, int)

The common thing with all fields is the first string statement within the brackets. Here you can enter an arbitrary name that will be displayed in the GUI window. Most field definitions expect two arguments, but addVectorField requires four, the addListField three entries. The meaning of the vector field’s arguments should be pretty clear now, because a vector always consists of three floating numbers. With list fields it’s a little bit different. The

second string determines a predefined list variable with appropriate entries:

objects = [Sphere","Cube","Vase","Torus","Rocket"]

The corresponding list field could look like this

window.addListField("Object selection", objects, 2]

In this case, the field’s name is “Object selection” and in the GUI window you’ll see all the entries from object lists you’ve defined before. The object’s variable in the list field’s arguments is substituted by the elements of the objects list. The integer is the option that’s selected by default and directly refers to the list’s order of elements. The default selection is “Vase” here, because lists always start with 0 and counting through the entries gives you 0 – Sphere, 1 – Cube, 2 – Vase, 3 – Torus, 4 – Rocket.

The first string variable is the field’s individual name, which must be unique, because RealFlow later identifies the entered values by using exactly the same name. A window definition like this is not valid:

window.addFloatField("Friction", 0.001)

window.addFloatField("Friction", 0.005)

A correct construction would be:

window.addFloatField("Particle Friction", 0.001)

window.addFloatField("Object Friction", 0.005)

A good example for the definition of a GUI window is a script-based creation of an emitter. You can write the following code to a batch script window:


emitter_types = ["Circle","Square","Sphere","Linear","Cylinder"]

particle_types = ["Liquid","Dumb","Elastics"]



Introduction | 300

nodes, GUI functions also offer the get statement:

getFieldValue(string)

Here you don’t have to think about data types any more, because they’ve already been determined with the initialization of the GUI. The string stands for the appropriate field’s unique name. So the code for processing the entered values is written this way:

if (window.show() == GUI_DIALOG_ACCEPTED):

emitter_type = window.getFieldValue("Emitter Type")

particle_type = window.getFieldValue("Particle Type")

resolution = window.getFieldValue("Resolution")

density = window.getFieldValue("Density")

intpres = window.getFieldValue("Int Pressure")

extpres = window.getFieldValue("Ext Pressure")

viscosity = window.getFieldValue("Viscosity")

tension = window.getFieldValue("Surface Tension")

name = window.getFieldValue("Name")

else:

scene.message("The emitter was not created.")

Please keep in mind that the names in brackets have to match the names from the previous field definition exactly, but without the default value:

window.addFloatField("Density", 1000.0) -> window.getFieldValue("Density")

If you want to share the values over different functions or even scripts, then it’s necessary to define them as global variables.

window.addListField("Emitter Type", emitter_types, 0)

window.addListField("Particle Type", particle_types, 0)

window.addFloatField("Resolution", 1.0)

window.addFloatField("Density", 1000.0)

window.addFloatField("Int Pressure", 1.0)

window.addFloatField("Ext Pressure", 1.0)

window.addFloatField("Viscosity", 3.0)

window.addFloatField("Surface Tension", 1.0)

window.addStringField("Name", "Emitter")

The fields represent the most important physical parameters of an emitter. If you have often-used settings, you can change the defaults to your needs, e.g. higher resolution:

window.addFloatField("Resolution", 5.0)

This is the first part of GUI creation, and so far the script doesn’t work, because some important elements and definitions are still missing.

b. processing The Values

This part translates the entered values into variables that can be used to create the emitter and adjust its physical properties. To trigger this process, the script has to check first whether the entered values have been accepted or not. That’s necessary, because each window shows an “OK” and a “Cancel” button. By confirming with “OK”, you tell RealFlow that the values have been accepted and should be used to feed the script. This query is done with the “show()” function:

int show()

The statement returns an integer specifying the button you have pressed. 1 stands for “OK” and 2 indicates that the operation has been aborted with “Cancel” or the ESC key. The query itself is packed into an if-condition to start with the translation of the values. Similar to the “get” instruction with parameters, where you can read out values from



Introduction | 301

if (particle_type != 2):

standard_emitter.setParameter("Int Pressure", intpres)

standard_emitter.setParameter("Ext Pressure", extpres)

standard_emitter.setParameter("Viscosity", viscosity)

standard_emitter.setParameter("Surface Tension", tension)

This code section needs some further explanation. The first issue concerns the results from the list fields and you can see a certain notation there in the argument:

(emitter_types[emitter_type])

The reason is that the corresponding field from GUI hands over an integer instead of a string, for example “Circle” or “Cylinder”. This selected emitter type is translated into a number and then used to find the corresponding entry in the “emitter_types” list. With “particle_types” it’s exactly the same mode of operation.

Finally, you can see this if-condition:

if (particle_type != 2):

It became necessary to introduce this differentation, because elastic particles don’t provide parameters, like “Int Pressure”, “Ext Pressure”, “Viscosity” and “Surface Tension”. These settings are now only changed for non-elastic fluid types. The “!=” operator means

“if particle_type is not 2”

With the execution of the last statement, the emitter appears under Nodes with all previously defined settings and the script is finished. A program like that is perfectly suited for the batch scripts window. Another idea would be to add it to RealFlow’s scripts toolbar with a nice icon (see page 34). From there it can be launched with a single mouse click.

d. File and Node pickers

RealFlow’s interface provides several tools for opening files from your local or network

Now it’s already possible to execute the script and check the GUI for plausibility. As you can see from the image on the right, RealFlow takes the field definitions and directly lists them in the order you’ve specified. That’s new, because in previous program versions the fields were added alphabetically and you had to add a suffix, for example an enumeration to create a certain order. In case you want to use older scripts you can remove the prefix now.

The GUI so far with the defined fields.

c. Using The Variables

In the second stage all the entered or default values are translated into individual variables and can now be treated as any other variable and used for further calculations. Here, the emitter is created with a series of setParameter() statements.

standard_emitter = scene.addEmitter(emitter_types[emitter_type])

standard_emitter.setParameter("Type", particle_types[particle_type])

standard_emitter.setParameter("Resolution", resolution)

standard_emitter.setParameter("Density", density)

standard_emitter.setName(name)



Introduction | 302

hard disks, and also allows you to select various nodes from a list. These tools can also be used for your own GUI windows. You have full access to these pickers and they offer full functionality, like filtering certain file or node types. There’s a fixed code structure for opening the file picker dialogue:

files = GUIFilePickerDialog.new()

path = files.show(FILE_PICKER_LOAD, "PATH", "*.tif;*.tga", "Load Maps")

The “files.show()” statement contains a series of arguments. The first statement, “FILE_PICKER_LOAD”, opens the file loader. If you want to save files, replace it with “FILE_PICKER_SAVE”. The next part specifies the path of directory that will be opened. This path has to be adjusted to your own needs, of course. With the next argument it’s possible to restrict the file list to a certain type. In this case only TIFFs and TGAs are displayed. If you want to show all files, use the *.* notation. Finally you can apply a name to your window. It’s just entered between quotation marks, like any other string.

The calling of a node picker is pretty similar to the file picker. First, the window has to be initialized and then you can specify the desired options to filter the available nodes:

dialog = GUINodesPickerDialog.new()

nodes = dialog.show( TYPE_EMITTER | TYPE_DAEMON )

for single_node in nodes:

scene.message(single_node.getName())

With “TYPE_NODE” it’s possible to restrict the displayed nodes to a certain type:

TYPE_CAMERATYPE_DAEMONTYPE_OBJECT TYPE_PB_EMITTERTYPE_EMITTERTYPE_STANDARD_MESH (or: TYPE_MESH)TYPE_MESH TYPE_JOINTTYPE_GROUP

TYPE_REALWAVE TYPE_MIST TYPE_IDOC TYPE_GRID_MESH TYPE_GRID_DOMAIN TYPE_RENDERKIT_MESH TYPE_GB_EMITTERTYPE_MULTIBODY ALL_TYPES

The individual types are separated with a pipe character, which can be added by pressing AltGr + > (WIN/Linux) and Alt + 7 (OS X).

The result of the node picker script.

20.26 Final NotesScripting with Python and RealFlow is a powerful means to develop your own behaviours, batch actions and many other things. It’s definitely not easy to learn a programming



Introduction | 303

language, make up your mind about syntax and find a way through all the different functions. RealFlow also provides an extensive instruction set to access almost any parameter or node. For many beginners this tremendous diversity seems overwhelming at first. While this manual gives you a basic introduction, and points you to the most important and most common methods to use, it can only be a starting point.

Learning a programming language requires a little patience, willingness to experiment and test out many different things. You also should think about other resources, like books or online tutorials. These external resources can give you a very good overview about the principles of programming and syntax – and that’s absolutely necessary for successful programming. Another common misjudgment is that programs have to be “temples” with object-orientation and sophisticated routines. Of course, it’s always a good idea to optimize a script, but that’s generally one of the last steps. It’s much more important to find out how things work and to create a workflow for a script. So it’s definitely worthwhile gathering your thoughts and taking all preliminary considerations into account before you start with a script. The more experience you get, the less time you’ll need and short scripts can be created on the fly.

Another really important issue is a feeling of success. The presented scripts and following examples try to give you this impression. Please bear in mind that you might experience days or even weeks without a reasonable result when you’re writing long and complex scripts. But really, it’s no harder than conquering fluid dynamics and fluid sculpting. The main thing is that you don’t lose patience and that you keep trying. No one is born a master!



Introduction | 304

21 scRIpTING – exaMples aND IDeas

Aside from theoretical considerations, practical exercises are the best way to learn something new – learning by doing is also a valid concept for programming languages. All the following examples include the rules and ideas from the previous chapters to show you how these things work in practice. You’ll loop through emitter particles, grab objects and their vertices, reposition nodes, create GUIs, extract velocities and many more. All this is done with the help of the discussed data structures, e.g. scalars and lists. “If-else” conditions also play a very important role. They’re always needed to branch to different parts of script, distinguish between certain states and to create the desired results.

A result from “Objects2Vertices” – one of the scripts discussed in this chapter.

The first scripts are mainly simple examples to give an idea of what’s happening while the code is executed. In the beginning there are not always visible results in your viewport, just long lists of numbers in the Messages window. When you have to deal with scripting, this window will soon become a very close friend, because there you’ll find all the results, warnings and errors. Whenever you have to check the plausibility of your script’s calculations and results, there should be an output to the messages window. The process of erasing errors is called debugging. RealFlow does not offer a complete visual

programming environment, such as Visual C/C++, but has basic debugging functions with a specification of the affected line of code. Please remember that tabbing is a very important issue with Python. The indents and spaces in front of a line are not only for making your script more readable and more clearly arranged; they’re also part of the syntax. You should always use the Tab key to create the indents, never the space bar. Scripts from external resources, in particular, might give you syntax errors because of wrongly input spaces. You should always check the indents.

u All scripts are created with scale 1.0 (geometry and forces scales) and axis setup is always ZXY (3DS, Maya). Unless an axis check is performed within the scripts, the height coordinate should be adjusted to your specific preferences (Z -> Y).

21.01 placing objectsThis very first script is explained and commented on in detail to give you an idea of how to write a script. While creating a program, it’s absolutely important to have a plan and a concept, because without theseyou’ll hardly ever get the desired result, especially as a beginner. With growing experience and short scripts it’s not always to necessary to create a complete syntax structure, but for more complex programs it’s mandatory.

Name Objects2Vertices.rfs

Type Batch script

Description This script reads out the vertices of all objects in the scene and writes them into a list. The position data are then used to place a certain object at the vertices location. These objects will be created automatically.

What the script should do:

1. Detect all objects inside the current scene2. Loop through the objects, collect the vertices, and store them inside a list3. Get the position data4. Add the clone object which is placed at the source node’s vertices5. Find the name of the cloned objects to reposition them6. Transfer the vertex positions to the objects and scale them



Introduction | 305

For getting the objects in a scene, RealFlow provides several options. If you want to get all objects, there’s the statement:

getObjects()

It reads everything that consists of vertices and polygons. If you want to restrict the script to a certain selection you’ve made in the Nodes window, then you have to use

getSelectedNodes()

In this case it’s recommended to check whether the chosen item really is an object, and not an emitter or a daemon. Both methods are a property of the scene class, so the complete notation is:

scene.getObjects()

scene.getSelectedNodes()

So far, so good, but currently the nodes aren’t stored and can’t be used for further manipulation. You have to assign a variable to store the elements. The statements tell Python that there can be more than one object and this means that everything’s written to a list (see page 277). Lists are able to store more than one value and each entry can be identified by its position inside the list - the index starts at 0. RealFlow automatically detects if a list variable is required, but there are also many situations where you have to introduce a variable manually to initialize it. In such a case it’s up to you which data type is needed. RealFlow’s help shows the required data type for each known statement and instruction:

Object[] getObjects()

Node[] getSelectedNodes()

This notation indicates that “getObjects()” will only catch true objects and write them to a list, which is represented with square brackets. “getSelectedNodes()” doesn’t distinguish between node types - all nodes are written to the list and it’s up to you to sort out which one you can use. Just a tip: The “getType()” instruction will help you out here.Since this script should only use true objects, the getObjects() statement is the best

choice. Whenever there is more than one element inside a list you have to create a loop to make them accessible. The “for … in” loop will perfectly serve your needs, but before it can be executed, a counter variable has to be introduced and finally incremented (see page 271, “Augmented Operators”):

counter = 1

scene_objects = scene.getObjects()

for single_object in scene_objects:


counter += 1

The next step is to get the vertices from each “single_object” and the individual positions. Again there’s more than one element, so the next variable will be a list, too:

Vertices[] getVertices()

Of course, it again requires a loop to read the individual positions from each vertex, so the entire construction for this purpose is:

counter = 1

objectList = scene.getObjects()

for single_object in objectList:

vertexList = single_object.getVertices()

for single_vertex in vertexList:

vertex_position = single_vertex.getPosition()

The result from this second loop is “vertex_position” , which is a vector - what you receive from “getPosition()” is a trio of three values for the X, Y and Z coordinates, which is considered a “vector” in RealFlow. This vector will then be used as a reference for the clone objects. To proceed, an object is needed for each vertex – here it’s a sphere, but you can choose any other object. Creating objects is a little bit different from adding emitters or daemons, because each object has its own statement:



Introduction | 306

addSphere()

If you want to add another object type, you can write: “addCube()”, “addTorus()”, “addRocket()” and so on. Once it is created, RealFlow assigns a new name to it, for example “Sphere01”, “Sphere23”, “Sphere175” etc.

The task now is to automatically find a pattern to read this name, because it must be used to clearly identify the appropriate object. Otherwise it’s not found by RealFlow and you receive a syntax error. In this example it’s not too difficult, because each object starts with “Sphere” followed by an index. Since the enumeration is not 1, 2, 3, 4,.., but 01, 02, 03, 04,... a differentiation is needed, and that’s why a counter has been introduced at the beginning of the script. Here’s the function:

scene.addSphere()

if (counter < 10):

cloneObject_name= "Sphere0"+str(counter)

else:

cloneObject_name = "Sphere"+str(counter)

cloneObject = scene.getObject(cloneObject_name)

counter += 1

Unless the counter has reached 10, the name should be written as 01, 02, 03, 04 and so on. For this purpose the leading 0 is used and then combined with the string value of the counter: “str(counter)”. With the “+” operator (see page 280) both elements are assembled together. Once 10 has been reached, the name just corresponds with the counter. Now the appropriate clone object can be identified. Finally it’s necessary to translate the current vertex positions to a clone object and rescale it:

cloneObject.setParameter("Position", vertex_position)

scaleVector = Vector.new(0.2, 0.2, 0.2)

cloneObject.setParameter("Scale", scaleVector)

The last two lines can also be written as:

cloneObject.setParameter("Scale", Vector.new(0.2, 0.2, 0.2))

And that's all. To run this script, add one or more objects to your scene, open a batch script window (see page 271), and copy/paste (mind tabs and indents!) or re-type the code to this window and choose:

Script > Run

You now can see how the clone objects are created and distributed to the vertices of the existing objects. The images below show examples. The cubes on the right were dyed with a little script, adding random colours to the nodes. You should already be able to write this extension.

Here’s the entire listing:

# Batch script

counter = 1




Introduction | 307

for single_object in objectList:

vertexList = single_object.getVertices()

for single_vertex in vertexList:

vertex_position = single_vertex.getPosition()

scene.addSphere()

if (counter < 10):

cloneObject_name= "Sphere0"+str(counter)

else:

cloneObject_name = "Sphere"+str(counter)

cloneObject = scene.getObject(cloneObject_name)

cloneObject.setParameter("Position", vertex_position)

cloneObject.setParameter("Scale", Vector.new(0.2, 0.2, 0.2))

counter += 1

21.02 placing particlesThe result from the previous script is a kind of “voxelized” representation of the objects in your scene, but the basic script has some annoying limitations regarding names. So here’s an idea: what if it was possible to attach particles to the vertices instead of objects? These particles could then be meshed with the “Clone obj” method (see page 193). This workflow would directly solve our problems without complex name checks.

Name Particles2Vertices.rfs

Type Batch script

Description This script reads out the vertices of all objects in the scene and writes them into a list. The position data are then used to add and place particles at the object’s vertex location.


1. Detect all objects inside the current scene2. Loop through the objects, collect the vertices and store them inside a list3. Get the position data4. Add the particles5. Transfer the vertex positions to the particles

First of all an empty emitter is needed. It makes no difference which type of emitter you’re going to use, but maybe a container serves best here. To prevent other emitter types from generating particles, both “Speed” and “Volume” have to be set to 0.0.

To create a particle RealFlow offers a certain instruction:

addParticle(position_vector, velocity_vector)

As you can see this statement needs two arguments. Here you have to determine a particle’s position and velocity. This is necessary information for a complete definition of a particle; without these values it’s not possible to properly add a particle.

The position is again derived from the vertices of the objects, but speed seems to be a problem. In fact, it isn’t really, because you can define a new velocity vector any time. Since the particles should not move at all, it’d be nice to make them all stationary:

null_velocity = Vector.new(0, 0, 0)

This script draws particles to all vertices in your scene:

nullVelocity = Vector.new(0, 0, 0)

emitter = scene.getEmitter(“Container01”)


for singleObject in objectList:

vertexList = singleObject.getVertices()



Introduction | 308

for singleVertex in vertexList:

vertexPos = singleVertex.getPosition()

emitter.addParticle(vertexPos, nullVelocity)

Evolution of a tree model, translated into more than 48,700 particles.

The particles here behave like particles from any other emitter. They can be affected by daemons, interact with objects and collide with other particles. Of course, they can be exported to a BIN file. To make this work, the emitter has to be active under Export Central (see page 58). Now you can store the particles into a single BIN file without simulating the scene. Just add a final statement at the end of the script without any leading tabs or spaces:

emitter.export()

21.03 Batch simulationsWith fluid and object dynamics it’s often necessary to run several simulations to find the best solution. Wouldn’t it be convenient if you were able to complete all these different

setups overnight without the need for manual intervention, like loading, resetting, and simulating the scene? A batch script can help you to automatize this process.

Name BatchSimulator.rfs

Type Batch script

Description The script can be used to automatically load and calculate various projects ready to simulate. The results will be stored under the appropriate project folders. Export resources have to be determined manually before under Export Central.


1. Use a given root path where all the simulations are stored2. Append the various project names to the root path3. Load and simulate the specified scenes

The very first thing you have to do is to find the path to the common folder, where all simulations are stored. This is not really necessary, because you can also specify custom paths to different locations, but it’s much better to have everything stored in one place. If you’re using the same path as specified under

Preferences > General > Scenes Folder

you can directly copy and paste it, as it already points to the correct directory. If you have them stored under a different location you have to find out manually. The most convenient and reliable way is to use an absolute path. As you can see it’s not necessary to use the Windows-specific backslash for the path:

projectRoot = “E:/RF Projects/Batch Simulations/DensityTest/”

Under OS X the directory delimiter is a colon ( : ), but it can also be substituted by a slash:

projectRoot = “/Users/Next Limit/Batch Simulations/DensityTest/”

The next task is to determine the different project names. As in the previous examples, you have to store multiple values and this requires an appropriate data structure: a list.



Introduction | 309

You simply have to write the different files names to the list and loop through it.

projectList = ["Density_0750","Density_1000","Density_1100","Density_1300"]

You can append as many projects as needed: there’s virtually no limit. The advantage is that the names do not have to share a common prefix or suffix, and it’s possible to enter any desired name. Now you have to go through the individual elements of the previously created list and load the files. RealFlow always establishes the same structure:

project name/project name.flw

With the concatenation operator “+” the elements can be joined together.

for projectFile in projectList:

scene.load(projectRoot+"/"+projectFile+"/"+projectFile+".flw")

scene.reset()

scene.simulate(0, 200)

With “scene.simulate(start, stop)” you’re able to specify the simulation range. In many cases the ranges are not the same for each project, and this will be an addition for this script. Assuming that the start frame is not subject to change, it’s only a matter of different end frames. For this purpose another list is created containing all the stop frames. A counter is needed, too:

stopFrameList = [50,100,150,200]

counter = 0

projectRoot = "E:/RF Projects/Batch Simulations/Various/"

projectList = ["Splash","filling_a_glass","rbd test_01","GridFluid_BeachScene"]

for projectFile in projectList:

scene.load(projectRoot+"/"+projectFile+"/"+projectFile+".flw")

scene.reset()

stopFrame = stopFrameList[counter]

scene.simulate(0, stopFrame)

counter += 1

The statement “stopFrameList[counter]” is the important element here. Since the counter is incremented with each frame, you can read out the stop frames from the list. The counter is used as an index for each list entry. If you need different start frames, you have to create another list. To save the assignment of extra start/stop variables, the scene. The “simulate()” statement can then also be written as:

scene.simulate(startFrameList[counter], stopFrameList[counter])

To speed up the entire simulation process you should consider using "RealFlow -nogui" instead of the GUI application. The script has to be saved externally and can then be called with the “-script” flag.

21.04 particle shifting Using a GUIRealFlow 5 provides a very easy and reliable method for transferring particles from one emitter to another. The combination of a container emitter and filter daemon can be used for this purpose. Container and filter are, of course, a convenient alternative, because you can achieve stunning effects without a single line of Python code. Nevertheless it’s sometimes necessary to do this within a Python script. Particle shifting can be considered as one of the core concepts with scripting, as it is a versatile and often used method. Particle shifting can be based on several particle properties, like velocity, pressure, age, collision and many more.

Name GUIParticleShift .rfs

Type Batch and Simulation Events

Description This script finds particles meeting a certain given criteria and shifts them to a second emitter. Target and source emitters can be meshed and finally rendered separately. Most of the initial settings are made via a custom GUI.



Introduction | 310


1. Initialize colours and get all exisiting emitters2. Create the GUI3. Assign the variables4. Determine the source and target emitters, make the settings5. Define the trigger condition, e.g a velocity above a given value with a random tolerance6. Loop through the particles, identify the ones with the desired pressure7. Shift the particles from the source to the target emitter8. Delete the appropriate particles from the source to avoid stability problems

The graphical user interface will query a couple of parameters: source and target emitter, property (age, pressure, etc), trigger value, colour for the target emitter. These values are then stored in variables and finally used to feed the particle shift routine. Additionally the emitters are equalised to prevent stability problems. The GUI part should be executed as a batch script.

The very first step is to define a range of different colours which will be used to dye the target emitter’s particles – source particles keep their default colour. Additionally, the script creates a list from all currently available emitters in your scene. This list is then used to generate a selection in the GUI. The code looks like this:

emitterList = []

colourList = ["Red","Orange","Purple","White","Yellow"]

rgbList = ((200,0,25),(255,150,0),(180,0,180),(255,255,255),(255,225,0))

emitters = scene.getEmitters()

for emitter in emitters:

emitterList.append(emitter.getName())

Except for the “rgbList()” statement, everything should already be familiar to you. The notation of the “rgbList()” list entries is different, because each element consists of three values enclosed in parenthesis. This is an exciting feature, because you can nest lists inside a list. The three values here are also called tuples. They are necessary because the RGB model always needs three values to define a certain colour. Since the tuples are lists,

it’s possible to call the individual elements through their indices, too. That’s the complete set of instructions for assembling a colour:

colour = guiForm.getFieldValue("Colour")

e_colour = rgbList[colour]

rgb = Vector.new(e_colour[0], e_colour[1], e_colour[2])

The selection from the GUI is translated into a variable called colour. Since all selections and choices are translated into numbers, you can directly extract the chosen colour from “rgbList[]”. The result of this operation is again a list object, containing the three values for R, G and B. Each element of this list has a fixed position and can be accessed via the index. The individual entries are then used to create the colour “vector”.

The next part is just basic GUI programming:

guiForm = GUIFormDialog.new()

guiForm.addListField("Source Emitter", emitterList, 0)

guiForm.addListField("Target Emitter", emitterList, 1)

guiForm.addListField("Colour", colourList, 3)

guiForm.addFloatField("Threshold Value", 2.0)

guiForm.addFloatField("Tolerance", 1.0)

guiForm.addFloatField("Speed", 2.0)

if (guiForm.show() == GUI_DIALOG_ACCEPTED):

emitter1 = guiForm.getFieldValue("Source Emitter")

emitter2 = guiForm.getFieldValue("Target Emitter")


threshold = guiForm.getFieldValue("Threshold Value")

tolerance = guiForm.getFieldValue("Tolerance")

speed = guiForm.getFieldValue("Speed")



Introduction | 311

Finally the emitters are equalized with “getParameter()” and “setParameter()” to avoid problems. The most important physical settings are read from the source emitter and then transferred to the target.

# Get the source emitter’s physical attributes and set speed to the given value

source = scene.getEmitter(emitterList[emitter1])

s_resolution = source.getParameter("Resolution")

source.setParameter("Speed", speed)

source.setParameter("Color", Vector.new(128,128,128))

# Attach colour, parameters and set Speed/Volume to 0.0



target = scene.getEmitter(emitterList[emitter2])

target.setParameter("Color", rgb)

target.setParameter("Resolution", s_resolution)

target.setParameter("Speed", 0.0)

target.setParameter("Volume", 0.0)

All the variables defined so far are local. This means that they cannot be transferred to other parts of the script, for example from batch to simulation events. Nevertheless some of the values have to be transferred to the simulation events section. For this purpose, global variables must be introduced, and you first have to find out which values are shared. For “threshold” and “tolerance” it’s pretty straight forward, but for the emitters it’s slightly different. With “emitterList[emitter1]” and “emitterList[emitter2]” it’s possible to find out the particular names, for example “Circle01” and “Circle01”. These names are stored in global variables and transferred to the simulation events section.

# Define the global variables

scene.setGlobalVariableValue("source", emitterList[emitter1])

scene.setGlobalVariableValue("target", emitterList[emitter2])

scene.setGlobalVariableValue("threshold", threshold)

scene.setGlobalVariableValue("tolerance", tolerance)

# Reset and start the simulation automatically, abort with ESC!

scene.reset()

scene.simulate(0,200)

This initial part is finished with the assignment of the global variables. The second task is to find the particles meeting the previously entered velocity threshold. “tolerance” is a random value that will be added or subtracted to get a more natural look. Since “tolerance” works in both directions, only half of the original value will be used. Everything is located under simulation events:

Simulation > Steps > StepsPre > Right click > Add script...

For this script a tolerance value has to be determined. With a given “tolerance” value of 0.5, for example, the final number lies between -0.25 and +0.25:

rndValue = random.uniform(-tolerance/2, tolerance/2)

The result is a float number that can be added to the entered “threshold” and then compared against the current particle’s velocity:

if (particle.getVelocity().module() >= threshold + rndValue):

add the particle to the target emitter

delete the particle from the source emitter



Introduction | 312

The process of shifting particles between emitters should be familiar to you by now, because this technique has already been introduced and discussed on page 294, “Shifting Particles”. The only new thing here is the call of global values from the batch script section. With these values it’s possible to identify the source and target emitter, and make use of “threshold” and “tolerance”. Type this part to

Simulation Events > Scene > ScenePre

import random

# Get the global values from batch script

source_name = scene.getGlobalVariableValue("source")

target_name = scene.getGlobalVariableValue("target")

threshold = scene.getGlobalVariableValue("threshold")

tolerance = scene.getGlobalVariableValue("tolerance")


source = scene.getEmitter(source_name)

target = scene.getEmitter(target_name)

# Loop through the particles, compare velocity and shift them to target

particle = source.getFirstParticle()

while (particle):


pos = particle.getPosition()

vel = particle.getVelocity()

pid = particle.getId()

target.addParticle(pos,vel)

source.removeParticle(pid)


If you added the GUI part to a batch window, the simulation starts automatically. This program uses many of the concepts you’ve read about so far. As you can see from this example it’s not only important to be careful with your indents and leading tabs, but also to consider readability. The entire script is grouped and subdivided into functional blocks. This helps you to keep a clear view about the used variables and values. It’s also recommended to insert comments about what’s currently going on.

u You can see the complete listing of GUIParticleShift.rfs on page 323.

21.05 Recording animation KeysRealFlow is a dynamic simulation tool, which means that animations are automatically calculated based on physical properties. This process doesn’t require any keys, but sometimes it’s necessary to store the movement within an animation curve, because you want to transfer it to a different object or export the keys. Another idea is to process the keys to create more sophisticated animations with ease-in and ease-out effects.

With the new functions of the Curve Editor you’ll benefit from even more advantages when dynamic animations are baked. It’s now possible to combine the recorded curves with expressions, copy certain areas or selected keys, and transfer them to other curves. And you can change a key’s behaviour to “Tcb”, “Linear”, “Bezier” or “Stepped” and save everything for future use.

Name KeyRecorder .rfs

Type Simulation Events

Description Record the individual position data for a selected node at each frame and write them to the Curve Editor with interpolation method Bezier.



Introduction | 313


1. Initialize the needed variables before the simulation starts2. Get time and position data for each axis, and write them to lists during simulation3. Create and write the keys for each frame and set interpolation type to “Bezier” after

stimulation

The workflow above indicates that three separate scripts are needed and the recorded information has to be shared between these parts. Such a process calls for global variables (see page 279). Nevertheless the script’s structure should already be clear, so the main issue is to find out where the individual parts are located and how to add an key to property’s animation curve.

At the time the simulations starts there has to be a global definition of the lists for both position and time data. It’s not possible to do this at another time, for example during the simulation, because in this case the contents would be overwritten with each frame and the result would be a single value.

# Simulation Pre

object = scene.getObject("Sphere01")

name = object.getName()

scene.setGlobalVariableValue("objName", name)

scene.setGlobalVariableValue("posList", [])

scene.setGlobalVariableValue("timeList", [])

The next step is to read the desired data and write everything to the previously initialized lists. There some of the global variables are needed.

# FramesPost

objName = scene.getGlobalVariableValue("objName")

posList = scene.getGlobalVariableValue("posList")

timeList = scene.getGlobalVariableValue("timeList")

currentTime = scene.getCurrentTime()

recObject = scene.getObject(objName)

pos = recObject.getParameter("Position")

posList.append(pos)

timeList.append(currentTime)

As you can see the current position is added to the list with each frame, as well as the current time. That‘s necessary because after the simulation you don’t have any time information and so everything has to be stored temporarily. Time is needed to properly set a key. The rest is pretty straightforward.

The motion path of a sphere will be translated into animation keys.

All keys will be written after the simulation, because this has some advantages: imagine you have to write out the position data to a file. This could slow down RealFlow, since the script has to open the output file, write the data and close the file for every single frame! With the method outlined here, everything is written in one pass after the last simulated frame. In the last part you can find the functions for setting the keys and assigning the information from the different lists. Everything has to be done for each component of the position vectors: X, Y and Z. The code snippet here shows the process for a single axis. A counter is needed to read out the stored time information by the list’s index:



Introduction | 314

An enlarged section of the recorded curves shows individual keys.

21.06 Tracking particlesTracing and tracking specific particles produces interesting results, especially when they become meshed later or when a particular object is applied. With this method it’s possible to create trails from selected particles and display them either with the help of objects or new particles.

Name ParticleTracker .rfs

Type Simulation Events

Description The script records the position data from one or more particles and makes them visible with the help of new particles or Null objects. Particles are shifted to a new emitter, Nulls are added at the end of the simulation and automatically grouped.


1. Initialize the needed variables and define the particles to be tracked2. Loop through the particles and find the ones to track3. Record the position data and transfer them to A) new particles or B) null nodes4. Group the objects and rename them, perform final adjustments

# SimulationPost

index = 0




object = scene.getObject(objName)

curvePosX = object.getParameterCurve("Position.X")

for posVector in posList:

newKeyX = Key.new()

simTime = timeList[index]

index += 1

newKeyX.time = simTime

newKeyX.value = posVector.getX()

newKeyX.type = KEY_TYPE_BEZIER

curvePosX.addKey(newKeyX)

The final statement prints a key which will be visible in the Curve Editor. Each statement with an axis-dependent variable has to be repeated for each of the position vector’s component to record the entire movement. Instead of “KEY_TYPE_BEZIER” you can, of course, use other types: “KEY_TYPE_TCB”, “KEY_TYPE_LINEAR” or “KEY_TYPE_STEPPED”. Another thing you should be careful with is this notation:

curvePosX = object.getParameterCurve("Position.X")

Please mind the dot between “Position” and “X”!

u You can find the complete listing of KeyRecorder.rfs on page 324



Introduction | 315

The entire script is executed with each frame. If you want to track specific particles it’s a good idea to use their IDs. An ID is unique for each particle and can be read easily. You can even make the ID visible by activating the Particle Tooltip option:

Menu bar > Tools > Particle Tooltip

The only issue with this function is that you have to simulate first before you can see the appropriate ID. A better option is to use a defined volume, instead of a constant particle stream. If you already know which particles you want to track, it’s a good idea to store them in a list:

idList = [1,56,145,354,508,722,1032,1195,1482,1648,2000]

Now it shouldn’t be a problem anymore to go through the particles and compare the current particle’s ID with the list entires. Once the ID was found, you can read out the particle’s position and transfer it to a new particle or an object, maybe a Null. If you’re thinking about new particles, they should be added to a second emitter that’s not linked with the other scene elements (= exclusive). Otherwise the particles will be part of the simulation process and may falsify the results.

If you want to track particles with an object we recommendthat you limit the process to a single particle, otherwise you might end up with several thousand new nodes. When using objects, they should be grouped to keep the Nodes window clear.

The following example shows both methods, but as separate scripts. A good exercise would be to join both methods to one script that’s controlled with a GUI. You could, for example, define custom functions (see page 296) for each part and call them through the GUI.

# FramesPost

emitter = scene.getEmitter("Square01")

tracker = scene.getEmitter("Tracker")

idList = [1,56,145,354,508,722,1032,1195,1482,1648,2000]

nullVec = Vector.new(0,0,0)

e_particle = emitter.getFirstParticle()

while (e_particle):

currentId = e_particle.getId()

if (currentId in idList):

pos = e_particle.getPosition()

tracker.addParticle(pos, nullVec)

e_particle = e_particle.getNextParticle()

t_particle = tracker.getFirstParticle()

while (t_particle):

t_particle.freeze()

t_particle = t_particle.getNextParticle()

As you can see, the current position is only extracted when the ID is identified as an entry of “idList”. This helps to save resources, because it’s not necessary to get each and every position when just a few selected particles are tracked. It’s important to have a look at these apparently small issues, because with lots of particles you will notice an increase in simulation speed.

Result of the particle tracker script from different views.



Introduction | 316

The second part is necessary to stop the tracker particles completely. Though a null vector is added to each particle’s velocity, they still have a certain amount of motion energy which could lead to unwanted results. To get rid of this motion, the script goes through the tracker’s particles and freezes them with

t_particle.freeze()

The other method uses an object to visualize the particle’s way through the environment. In this case, you can trackjust one particle with a Null; but it’s also possible to track more than one particle, resulting in many more objects. The created Nulls are added to a group automatically and renamed using a certain pattern. Finally, all nodes except the Nulls and daemons are made invisible so that only the position trail is visible in the viewport. Additionally the Nulls are coloured and reduced in size. This drawing of position markers can either be executed during the simulation or as a post process at the end of the simulation range. Then all markers are drawn from a previously stored position list. This method illustrates how to deal with lists and how to extend them. But that’s not all: the script also uses global variables, since some of the stored information has to be transferred to different parts and functions.

The first part is the definition of the particle’s position list. This list will later contain the entire recorded position data which will be read out at the end of the simulation. Now it’s nothing more than an empty container, but it must be a global variable. In this case it’s not possible to initialize the list during the simulation steps, because it would be dumped with each frame losing the previous data.

# SimulationPre


That’s already everything you need. During the simulation the position data are recorded and added to the previously introduced pos_list variable. You also have to specify the desired ID. In this case there’s really only one ID tracked. If you want to track more particles another data structure is required to identify the position values and the related particle: a perfect task for a dictionary (see page 278)!

The code structure for this section is almost the same as in the example above, but even easier, as you don’t have to go through a list object. Here you need just a scalar and of course the global variable pos_list:

# FramesPost

# A. Fetch the global variable and make it local / B. Specify a particle ID


id_to_track = 30



while (particle):

current_id = particle.getId()

if (current_id == id_to_track):


# Append the current position of the particle to the position list

posList.append(pos)


# Translate the local variable with the positions into a global variable again

scene.setGlobalVariableValue("posList", posList)

The position list is finally used at the end of simulation. There, all data will be read out and transferred to a Null object – one Null for each position. This mode of operation calls for another loop. During this loop the Nulls are renamed following a certain pattern to create a uniform notation. Additionally all position markers are added to a group. If you want to delete the trackers and create a new simulation, then it can be done with a single click and you don’t have to select and erase hundreds of nodes individually.

First of all it’s necessary to make everything invisible. Here, we’ll leave the daemons still



Introduction | 317

visible. This isn’t really important, but it’s a useful way to illustrate how to filter certain node types. Maybe there’ll be a situation where you have to separate emitters from the rest of the nodes in the scene. With this little piece of code it’s no problem – please note that all of the following Python snippets have to be inserted under “SimulationPost”:

nodes = scene.getNodes()

for node in nodes:

if (node.getType() != TYPE_DAEMON):

node.setParameter("Visible", False)

This loop tells RealFlow that only non-daemons should be set to invisible. The != operator means: If the current node of the list is not (!=) a daemon then hide it to the user.

The next task is to create the group where all Null nodes are finally added to. Here a very fast and convenient method is introduced helping you to avoid more complex routines for detecting certain nodes. You’ll see a little later how easy it is to work with this method. It directly converts a freshly added node, object or whatever into a variable:

nulls = scene.addGroup()

nulls.setName("NullTracker")

This easy notation replaces a slightly longer form:

scene.addGroup()

nulls = scene.getGroup("Group01")

nulls.setName("NullTracker")

This doesn’t look very sophisticated, but in fact it is! Imagine several simulations with a different group name each time. With this short version you don’t have to keep track of the group’s name, because everything’s directly stored with the variable. That’s very convenient for lots of objects and important when you rename the Nulls – which happens in the next step. Before you can add the Nulls it’s necessary to create a new name for each item. The naming pattern should contain leading 0 characters to allow easy and correct sorting:

Tracker0001 -> Tracker0010 -> Tracker0100 -> Tracker1000+

This kind of naming can be done with a counter and few simple if-conditions which are already familiar from the first example “Placing Object” in this manual:

counter = 1

for entry in pos_list:

if (counter < 10):

suffix = "000"+str(counter)

elif (counter >= 10 and counter < 100):

suffix = "00" + str(counter)



else:

suffix = counter

new_name = "Tracker"+str(suffix)

# Add the Null and convert it into a variable for immediate renaming.

current_null = scene.addNull()

current_null.setName(new_name)

counter += 1

This construction allows you to specify your own “file padding”. The “str(variable)” instruction is used to mix a given string with the content of variables. This doesn’t work with vectors, because they’re stored in a hexadecimal format, but here only simple scalars are used. Finally a few basic operations are done to rescale and dye the Null nodes and add them to the group. This should be basic stuff now, except adding the new items to the appropriate group. Another new feature that’s introduced here is to prevent the Nulls from being exported to disk. Although that’s more important for a script version where the Nulls



Introduction | 318

are created during the simulation process, it’s still worth showing you how to manipulate Export Central with Python. The notation is:

current_null.activeExportResource(1, False)

The integer argument is a fixed ID and specifies the file type that’s available for object nodes under Export Central. Following this list you can see that the Boolean data type “False” disables the export function for the individual SD files and the soft body BINs:

1 = Animation (.sd)2 = Geometry (.obj)4 = Wetmap texture (*)

A tracked particle a) with fluid and b) without particles.

Here’s the complete listing for the last part of the tracking script:

# SimulationPost

nodes = scene.getNodes()

for node in nodes:

if (node.getType() != TYPE_DAEMON):

node.setParameter("Visible", False)

nullGroup = scene.addGroup()

nullGroup.setName("NullTracker")


counter = 1

for entry in posList:

if (counter < 10):

suffix = "000"+str(counter)





else:

suffix = counter

new_name = "Tracker"+str(suffix)

currentNull = scene.addNull()

currentNull.setName(new_name)

currentNull.setParameter("Position", entry)

currentNull.setParameter("Color", Vector.new(180,22,33))

currentNull.setParameter("Scale", Vector.new(0.2,0.2,0.2))

currentNull.activeExportResource(1,False)

currentNull.activeExportResource(3,False)

nullGroup.add(new_name)

counter += 1



Introduction | 319

The particle tracker script contains a lot of methods and features which are important for your daily scripting tasks. You have to filter out certain node types, define and call global variables, change all kinds of parameters, loop through particles and objects, record data, transfer or manipulate them, set export resources, and rename scene objects. All these fundamental principles are applied within a single script.

21.07 RealWave Displacement MapsRealFlow now supports the highly requested statistical wave type. With this wave type it’s possible to create cresting waves – something that was only partially possible before RealFlow 5. The only solution to apply real statistical waves on a RealWave surface in RealFlow 4 was by importing displacement maps from other sources. Though cresting waves are available now there might be situations where it still makes sense to use displacement maps. Importing those maps is a typical task for a scripted RealWave modifier. Applying a scripted modifier works exactly like applying one or more of the ready-made waves types. The only difference is that you don’t have any settings regarding wave speed, height or other attributes. All these characteristics are defined by your script, respectively by your image sequence . To launch the RealWave scripting editor, simply click on “Edit”. A new window appears with a standard function:

def updateWave( vertices, initPositions ):

The procedure is exactly the same as with scripted daemons or custom functions. The code is just added below the function and has to be indented.

Name DisplacementWave.rfs (original script by Á. Tena, Next Limit Technologies)

Type Scripted RealWave modifier

Description Create a vertical displacement of the RealWave vertices by translating pixel colour values from a given image sequence into height information. The script loops through all vertices each frame, grabs the UV texture information, and applies the corresponding pixel value to the vertex.


1. Specify the path to the image sequence and find a common pattern that can be replaced with the current frame

2. Open the image and get its size3. Loop through the vertices and get the UV coordinates in X/Z direction based on the

image size4. Get the pixel’s colour value and apply it as height information to the Y position

The most important step is to find the correct file path. Without this path it’s impossible for the script to get the pixel values and you’ll receive an error. Another requirement is that all image maps are stored under one common directory. With appropriate “if-else” conditions it’d be possible to gather images from various sources, of course, but this script doesn’t take this into consideration. Getting the file path might take a little effort on different operation systems, because of different rules how the directories are separated, and whether you want to use relative or absolute paths.

Another task is to find a common pattern that can be used to loop through a sequence of images automatically without the need to load each picture manually each frame. Fortunately Python provides tools and functions to automatize this process. Therefore it’s important to analyse the file name and change it if necessary. Programs normally write out image sequences following a certain pattern, e.g.

image_00000.tga map001.tif dsplcmnt_01_0001.jpgimage_00001.tga map002.tif dsplcmnt_01_0002.jpgimage_00002.tga map003.tif dsplcmnt_01_0003.jpg

As you can see from the examples above all file names share two common things: they have begin with a “0”, followed by the frame number and a common extension indicating the file type. The differences lie in the prefix and the number of initial “0” characters. Since “0” is repeated, everything can be written in Python as 05d (=5 x 0), 03d (=3 x 0), 04d (=4 x 0). The next task is to replace this pattern with the current frame. Using the complete file name from the first example the syntax for this operation is

"image_%(#)05d.tga" % {"#" : frame }

This syntax means: “Replace all parts of the file name with five consecutive 0 characters with the current frame. The replacement “variable” is #.” The complete file path also contains the appropriate directories. The following lines are just example for Windows and OS X and have to be adapted to your own situation:



Introduction | 320

filePath = "D:/RF/RealWave/OceanSequence/pict/image_%(#)05d.tga" % {"#" : frame}

filePath = "/Users/mymac/RF/RW Projects/maps/image_%(#)05d.tga" % {"#" : frame}

Once the file path has been specified it’s time to open the images:

pict = Image.new()

pict.open(filePath)

pictWidth = pict.size[0]

pictHeight = pict.size[1]

“Image.new()” is a constructor that’s needed to allocate resources for the image and read out its dimensions. Finally a loop is introduced, merging the vertices’ UVs with the picture’s dimensions and defining the pixel’s colour value (0 - 255):

for i in range(0, len(vertices)):

pixelPosX = (pictWidth – 1.0) * vertices[i].uvw.x

pixelPosZ = (pictHeight – 1.0) * vertices[i].uvw.z

pixel = pict.getPixel(pixelPosX, pixelPosZ)

initPosition = initPositions[i]

height = (pixel[0] / 255.0)

vertices[i] = Vertex.new(initPosition - Vector.new( 0.0, height, 0.0))

Here’s the complete listing:

def updateVertices(vertices, initPositions):


filePath = "Enter your path here/image_%(#)05d.tga" % {"#" : frame}

vel = Vector.new(0.0, 1.0, 0.0)

pict = Image.new()

pict.open(filePath)

pictWidth = pict.size[0]

pictHeight = pict.size[1]

for i in range(0, len(vertices)):

pixelPosX = (pictWidth – 1.0) * vertices[i].uvw.x

pixelPosZ = (pictHeight – 1.0) * vertices[i].uvw.z

pixel = pict.getPixel(pixelPosX, pixelPosZ)

initPosition = initPositions[i]

height = (pixel[0] / 255.0)

vertices[i] = Vertex.new(initPosition - Vector.new(0.0, height, 0.0))

vertices[i].setVelocity(vel)

21.08 Random Mass changeWith rigid body dynamics, it’s often necessary to slightly change physical properties of an object. Good examples are random differences in mass or elasticity. Though the variations are sometimes very subtle it’s a good idea to think about this possibility, because it adds some extra realism to a simulation. Changing the properties for a few dozens or even hundreds of nodes is not a fun job. Doing it once is already a hassle, but what if you have to present several simulations with different values? Here a script is the only solution!

Name ChangeRBDMass.rfs

Type Batch script

Description This program automatically activates the rigid body property for a custom selection of nodes and randomly changes the @ mass parameter.



Introduction | 321


1. Detect the user’s selection from the Nodes window and loop through the objects2. Activate rigid body dynamics for all objects or skip this process if it’s already turned on3. Access the “@ mass” parameter, read it out and create a random percentage variation4. Insert the calculated value5. Write out a message when the process is finished, together with the elapsed time

The user selection is an easy but powerful way to limit the execution of the script to certain nodes. As shown previously, RealFlow’s Python engine can recognise an instruction to detect such a selection and store it within a list:

userSelection = scene.getSelectedNodes()

Now it’s easy to loop through the individual elements of “userSelection”. A simple “for … in …” loop will do the job. The process of checking whether rigid body dynamics is already activated or not shouldn’t be difficult, as it’s simply an if-condition. Reading out the current “@ mass” value is also no mystery and was already discussed on page 290 (“Changing Attributes”). So the body of the script could look like this:


for node in userSelection:

rbdState = node.getParameter("Dynamics")

if (rbdState != "Rigid body"):

node.setParameter("Dynamics", "Rigid body")

currentMass = node.getParameter("@ mass")

The core function of this script is to apply a certain amount of randomness. This value should be within a given range based on the original “@ mass” setting, e.g. vary the current mass within 10% of the current value. Let’s say the initial mass is 100 for each object. This means that the new mass should be somewhere between 95 and 105. The statement for this operation uses the random module and actually the code should already look familiar to you:

import random

percentVariation = 10

range = (currentMass / 100) * (percentVariation / 2)

randomValue = random.uniform(-range, range)

newMass = currentMass + randomValue

u Please note that the operation above might fail for very small mass settings!

The last action is to print out a little message together with the time the script needed for applying the new mass value. Since this little program is a batch script it’s not possible to use RealFlow’s simulation time. The “scene.getCurrentTime()” statements has no effect here, but fortunately Python provides a module called “time”. This module comes with Python’s standard distribution and should be installed by default. To access the specific “clock()” function a new notation is required:

from time import *

Here you can see a different notation for the "import" command. If you would like to learn more about advanced techniques to load modules, we suggest that you do some research online. The “clock()” function from this module simply measures and stores the current time during function call. Keeping this in mind it’s easy to create a time difference:

from time import *

startTime = clock()

... go through the selected nodes and calculate the new mass values here

stopTime = clock()

diffTime = stopTime – startTime

scene.message("Elapsed time: "+str(diffTime)+" seconds")

The final message should also print out a little note that the process is finished. To make everything more appealing, a formatting operator is introduced:

scene.message("\nAction completed...\nElapsed time: "+str(diffTime)+" seconds")



Introduction | 322

The “\n” operator introduces a new line, called “escape sequence”. As you can see it’s not necessary to include any separators, because Python automatically recognizes these sequences and translates them.

So the entire script looks like this:

from time import *

import random

startTime = clock()

percentVariation = 10


for node in userSelection:

rbdState = node.getParameter("Dynamics")

if (rbdState != "Rigid body"):

node.setParameter("Dynamics", "Rigid body")

currentMass = node.getParameter("@ mass")

range = (currentMass / 100) * (percentVariation / 2)

randomValue = random.uniform(-range, range)

newMass = currentMass + randomValue

node.setParameter(“@ mass”, newMass)

endTime = clock()

diffTime = endTime - startTime

scene.message("\nProcess finshed...\nElapsed time: "+str(diffTime)+" seconds")

You can extend this script to perform more than one parameter change or add a nice little GUI. With ChangeRBDMass.rfs, a simulation looks much better, because the different masses cause “instabilities”, forcing the bodies to act in a different way and the result looks moch more vivid. The example below shows a fixed mass of 1,000, the second uses a “percentVariation” value of 25.

21.09 listingsSome scripts introduced in the last chapters are simply too long to print directly within the explanatory texts. To provide a coherent view on these programs, you’ll find two longer listings on the following pages.



Introduction | 323

a. GUIparticleshift.rfs

# I. Batch Script

emitterList = []

colourList = ["Red","Orange","Purple","White","Yellow"]

rgbList = ((200,0,25),(255,150,0),(180,0,180),(255,255,255),(255,225,0))

emitters = scene.getEmitters()

for emitter in emitters:

emitterList.append(emitter.getName())

guiForm = GUIFormDialog.new()

guiForm.addListField("Source Emitter", emitterList, 0)

guiForm.addListField("Target Emitter", emitterList, 1)

guiForm.addListField("Colour", colourList, 3)

guiForm.addFloatField("Threshold Value", 2.0)

guiForm.addFloatField("Tolerance", 1.0)

guiForm.addFloatField("Speed", 2.0)

if (guiForm.show() == GUI_DIALOG_ACCEPTED):

emitter1 = guiForm.getFieldValue("Source Emitter")

emitter2 = guiForm.getFieldValue("Target Emitter")


threshold = guiForm.getFieldValue("Threshold Value")

tolerance = guiForm.getFieldValue("Tolerance")

speed = guiForm.getFieldValue("Speed")

# Process the source emitter’s properties and set speed to the given value

source = scene.getEmitter(emitterList[emitter1])

s_resolution = source.getParameter("Resolution")

source.setParameter("Speed", speed)

source.setParameter("Color", Vector.new(128,128,128))

# Attach colour, parameters and set speed/volume to 0.0



target = scene.getEmitter(emitterList[emitter2])

target.setParameter("Color", rgb)

target.setParameter("Resolution", s_resolution)

target.setParameter("Speed", 0.0)

target.setParameter("Volume", 0.0)

# Define the global variables

scene.setGlobalVariableValue("source", emitterList[emitter1])

scene.setGlobalVariableValue("target", emitterList[emitter2])

scene.setGlobalVariableValue("threshold", threshold)

scene.setGlobalVariableValue("tolerance", tolerance)



Introduction | 324

# Reset and start the simulation automatically, abort with ESC!

scene.reset()

scene.simulate(0,200)

# II. Simulation Events > Scene > ScenePre

import random

# Get the global values from batch script

source_name = scene.getGlobalVariableValue("source")

target_name = scene.getGlobalVariableValue("target")

threshold = scene.getGlobalVariableValue("threshold")

tolerance = scene.getGlobalVariableValue("tolerance")


source = scene.getEmitter(source_name)

target = scene.getEmitter(target_name)

# Go through all particles, compare velocity and shift them to the target emitter

particle = source.getFirstParticle()

while (particle):



vel = particle.getVelocity()

pid = particle.getId()

target.addParticle(pos,vel)

source.removeParticle(pid)


b. KeyRecorder.rfs

# I. SimulationPre

object = scene.getObject("Sphere01")

name = object.getName()

scene.setGlobalVariableValue("objName", name)


scene.setGlobalVariableValue("timeList", [])

# II. FramesPost




currentTime = scene.getCurrentTime()

recObject = scene.getObject(objName)

pos = recObject.getParameter("Position")

posList.append(pos)



Introduction | 325

timeList.append(currentTime)

# III. SimulationPost

index = 0




object = scene.getObject(objName)

curvePosX = object.getParameterCurve("Position X")

curvePosY = object.getParameterCurve("Position Y")

curvePosZ = object.getParameterCurve("Position Z")

for posVector in posList:

newKeyX = Key.new()

newKeyY = Key.new()

newKeyZ = Key.new()

simTime = timeList[index]

index += 1

# Record X positions

newKeyX.time = simTime

newKeyX.value = posVector.getX()

newKeyX.type = KEY_TYPE_BEZIER

curvePosX.addKey(newKeyX)

# Record Y positions

newKeyY.time = simTime

newKeyY.value = posVector.getY()

newKeyY.type = KEY_TYPE_BEZIER

curvePosY.addKey(newKeyY)

# Record Z positions

newKeyZ.time = simTime

newKeyZ.value = posVector.getZ()

newKeyZ.type = KEY_TYPE_BEZIER

curvePosZ.addKey(newKeyZ)



Introduction | 326

22 TaBles aND ValUes

This chapter provides values of some important substances and gravitational accelerations of the celestial bodies of our solar system. You can use them directly within RealFlow, but it’s sometimes necessary to adjust everything to your individual needs.

22.01 DensityDensity is not a fixed a value, because it strongly depends on external influences, for example temperature (T) or pressure (P). There are also compound substances with varying ingredients, such as crude oil or honey. Gases also have a strongly varying density. For all these reasons it’s important to be aware of the standard conditions for the different densities. For compound substances, there’s only an average.

a. solid substances (T = 25°c, p = 1,013 hpa)

Substance Density [ kg · m-3 ] Substance Density [ kg · m-3 ]

Styrofoam 20 - 60 Concrete 1,800 - 2,450

Cork 150 - 500 Aluminium 2,710

Potassium 680 Chrome 7,200

Inkjet paper 800 Iron 7,860

Paraffin 860 - 930 Brass 8,100 - 8,700

Wax 900 - 980 Copper 8,940

Ice (0°C) 917 Silver 10,490

Acyrlic glass 1,190 Lead 11,340

Black coal 1,350 Uranium 19,050

Magnesium 1,733 Gold 19,302

b. liquid substances (T = 25°c, p = 1,013 hpa)


Benzine 750 (average) Salt water 1,025 (average)

Ethanol 789 Milk 1,030 (average)

Aceton 790 Acetic acid 1,049

Methanol 790 Glycerine 1,260

Petroleum 800 Milk chocolate 1,280 (average)

Diesel 830 Honey 1,400 (average)

Crude oil 860 (average) Nitric acid 1,512

Benzol 879 Sulfuric acid 1,834

Olive oil 910 (average) Bromine 3,119

Pure water (4°C) 1,000 Mercury (0°C) 13,595

c. Gaseous substances (Dry gases, T = 0°c, p = 1,013 hpa)


Hydrogen 9 Oxygen 1,429

Helium 178 Fluorine 1,695

Methane 717 Argon 1,784

Ammonia 771 Carbon dioxide 1,977

Neon 840 Propane 2,019

Steam 880 Ozone 2,220

Acetylene 1,171 Sulfuric dioxide 2,926

Air (20°C) 1,293 Chlorine 3,119

Carbon monoxide 1,250 Krypton 3,479

Nitrogene 1,251 Xenon 5,897



Introduction | 327

22.02 Gravitational accelerationThis parameter is also known as “g” and is different for any location, because it strongly depends on a body’s mass. Even here on Earth, gravitational acceleration differs greatly from place to place. Hence the give values are only averages.

Celestial body g [ m/s-2 ] Celeatial body g [ m/s-2 ]

Sun 274.0 Jupiter 24.9

Mercure 3.70 Saturn 11.1

Venus 8.87 Uranus 9.0

Earth 9.81 Neptune 11.4

Moon 1.62 Pluto 0.17

Mars 3.37 Ceres 0.27

22.03 RealFlow objectsFinally, here’s a table containing RealFlow’s objects and their most common attributes. The values are valid for scale 1.00.

Object Surface [ m2 ] Volume [ l ] Mass [ kg ] Coll. distance

Sphere 3.08 505.88 505.88 0.02

Hemisphere 1.49 36.80 36.80 0.01

Cube 6.00 1,000.00 1,000.00 0.02

Cylinder 4.56 734.73 734.73 0.02

Vase 5.87 285.34 285.34 0.02

Cone 2.45 244.91 244.91 0.02

Plane 100.00 N/A 55,555.56 0.02

Torus 19.22 4,540.89 4,540.89 0.02

Object Surface [ m2 ] Volume [ l ] Mass [ kg ] Coll. distance

Rocket 3.99 375.04 375.04 0.02

Capsule 1.52 151.11 151.11 0.01

Cross 30.00 7,000.00 7,000.00 0.06

Null N/A N/A N/A N/A

© Copyright 2010 Next Limit SL

RealFlow a registered trademark of Next Limit SL

All trademarks included in this catalogue belong to their respective owners

All images in this book have been reproduced with the knowledge and prior consent of the artists concerned and no responsibility is accepted by producer, publisher, or printer for any infringement of copyright or otherwise, arising from the contents of this publication. Every effort has been made to ensure that credits accurately comply with information supplied.

Documents

Realflow Manual