Tutorial01


	Tutorial 3: Play Catch -- Daemons, Objects and Expressions

Objectives

This tutorial follows on from Tutorial 2 (waterdrop). If you're a beginner, this project will take your ability to control fluids with daemons to a new level.

We’re going to create an animation broadly similar to the Phantom Dance sequence in Next Limit's video gallery. Here however, we're going to turn up the challenge a little and "play catch" with a blob of viscous fluid, throwing it between moving objects. The objects have an imposed animation and so we have to work to a rigidly-set timing, equivalent to the requirements of a real production.

As usual there are a variety of ways to resolve the scene. We will do it using dspline and object daemons, and by animating a variety of parameters. Besides learning more about daemons, this tutorial introduces the use of objects in RF3, and gets us deeper into RF3's animation capabilities in terms of both keyframing and expressions.

The tutorial is designed for intermediate users, who have at least done some work with RealFlow3 -- beginners can easily handle the content but basic directions are omitted to keep length and repetition to a minimum. Those not familiar with RF3 should do at least a beginner's level tutorial first to avoid confusion over the interface.

At the end, there is an extended Tips section that goes into some detail on building useful expressions, which users at any level may find useful.

This tutorial is the first of 3 with a strong focus on the use of objects in RF3.

Introduction

In RF3, daemons allow you to exert control over fluids, but you first need to know what effects each daemon will have, in order to understand how to achieve the effect you want. Also, it is easy to go too far and achieve an effect that looks too artificial, and defeat the purpose of having a physics-based application like RF3. The key is bending the physical rules rather than smashing them to bits.

The work here will focus on "throwing" a ball of fluid back and forth between two moving points, a little like playing ping-pong with mercury in outer space. The result doesn't relate to any common real-world phenomenon, except possibly oil-in-water motions. Still, similar effects are commonly seen in commercial work as well as science fiction t.v. and feature film. In this case, you need to imagine that you've been handed a 30-second animation of 2 characters playing "catch", and been told by the CGI Supervisor to create a viscous fluid ball moving between the players. In this case, we aren't going to use object-fluid collisions, instead the goal is to make the fluid look like it is being controlled by magic-like forces.

The tutorial will not touch on meshing, waves, rigid body dynamics, constraints, other types of fluids besides liquid, transferring data between RF3 and 3D applications, and rendering.

The structure is designed for quick navigation depending on your level of experience with RealFlow, and your level of learning interest:

- For those wanting to quickly cover the basics and like to learn by doing and experimenting rather than get into details, just follow the bold steps giving simple instructions. Or, download the project files and examine them, running tests simulations and tweaking parameters.

- For more experienced users who feel they know how to do this kind of project, but want to gain a better understanding of aspects of RealFlow, scan the bold instructions to look for new approaches, and then check out the Tips section at the end, covering more details of building expressions.

If you want additional help during the tutorial or are looking for other tutorials afterward, there are a lot of resources available to you. Under Help>contents… you’ll find the online manual that is packed with information, and is a good place to start (if you’re a total beginner, check the Getting Started section). Second, check the Next Limit website for more, as well as example scenes that are great for learning. Third, there are a lot of very good user tutorials accessible from Next Limit’s RF3 forum, in the tutorial section. These tutorials have been checked over and rated by experts, and a good place to start is in the index of tutorials in that part of the forum. Finally, take advantage of the user community in the forum to ask questions and gain a variety of insights. While working in RF3, use the tooltip-style help when you need reminding or definitions of functions: hover the cursor over an interface element and hit F1 to get a popup giving you info on that element. If the element is a sub-panel tab, RMB-click over it for information. For more shortcuts, check go to Help>Key Shortcuts…

Before we start, let’s define some common abbreviations:

RF3 = RealFlow version 3.x

UI = user interface

LMB / MMB / RMB = left, middle and right mouse button, respectively

Ctrl = the control button on your keyboard

Alt = the alt button on your keyboard

Shift = the shift button on your keyboard

1,2,3,4,Q,W,E,R = those buttons on your keyboard (e.g., W = the W button on your keyboard)

OK, time to play ball!

1 – Initial setup:

Start up RealFlow, create a new project called “playcatch”. Download the animation of the objects playing catch (in RF3's SD format) here, and uncompress the files in the project's objects directory. Also set up the workspace using File>Preferences…, to give the view setup you want, and add some Summary Info.

If you want your view to look like those below, select the 3-view window and otherwise keep everything at the default values. In the options tab, set the end frame to 900 and the FPS output to 30, for a 30-second animation.

Finally, you may wish to add some file information by going to File>Summary Info...

You also need the animated objects for this project. Get them via this compressed zip file. Once downloaded, decompress the zip to your project's objects directory.

The zip archive contains the scene data file (.SD) for a sphere and a cube that were animated in a game of catch. The SD file was generated by exporting using the Next Limit plugins that are free from the Next Limit website, in the downloads section.

The archive also contains 3 other objects, in Wavefront .obj format, that we'll use for this work. More on that below.

2. Import the SD data and view the object animation.

Import the mocap.sd file and play the scene to get a feel for the motion.

We first want to get a feel for the task at hand, so bring the animated objects into the scene to check out the animation:

Go to the objects tab (F5) and LMB-click on the folder icon below the display panel. Or, go to file>Import...>Import SD scene. In the objects directory, open the mocap.sd file. The motions were captured with simple motion capture methods, hence the name.

You'll now see the sphere and cube in the viewport windows. If you hit play (or spacebar) you can watch the animation. You can see that there are 9 throws between the objects, or about 1 per 100 seconds. This is the time scale over which the blob of fluid has to launch from the throwing object, travel in a nice arc between them, and be caught and held in the vicinity of the catching object.

Remember that the objects themselves are not meant to directly interact with the fluid, they are just being used to mark locations in space. The fluid will be thrown and caught by "force fields". For this reason we don't have to worry about all the object settings relating to particle interaction and dynamics. That will be covered in the next couple of tutorials.

3. Add a dspline daemon and emitter, and test the basic motion.

Add a sphere emitter to introduce particles in a blob shape. Link it to the sphere object, set the resolution to 0.1 and place it in fill mode. Add a dspline emitter, rotate about the z-axis by 90 degrees, set its y-scale to 10 to reach between the objects, and move it so its ends lie on the objects. Using just axial force, run some tests at different values to see what strength will move the particles between the objects in the time for the throw-catch cycle of about 30 frames. Use a cosine expression to find a good starting magnitude for the axial strength.

If we attempt to just use an attractor linked on each object to push and pull the particles, we will have trouble keeping control of the fluid - this is worth trying to get a feel for it. A better approach would be to animate the motion of an attractor passing between the objects. This should work well but we want to get more interesting motion during the flight of the thrown blob, so will be using a dspline to guide the fluid motion.

The dspline is an interesting daemon because it can be used to get anything from twisting and turning pipe flow to spinning tornado motion. It allows you to apply forces to particles along a spline, and to control the radial, axial and vortex forces at each spline control point (CP).

First, add a source of particles -- we want to start with a blob of fluid being held near the sphere object, so let's start with a sphere of fluid particles. Go to the emitters tab (F2) and add a sphere emitter.

Using the emitter's Node subpanel, link it to the sphere. It should now be at the sphere location.

In the sphere subpanel switch the Fill sphere setting to yes, so that we start with a spherical group of particles filling the sphere rather than emit particles continuously from the sphere emitter's surface.

During our testing stage, we don't want to wait around for simulations so reduce the resolution to 0.1, and after resetting you should have 393 particles.

Now go to the daemons tab (F4) and add a Dspline daemon.

The Dspline starts off with 3 control points (CPs), which is enough for us in this project (2 ends and a middle).

Rotate the dspline about its z-axis by 90 degrees, so it is now horizontal. We want the end points to reach between the objects, so increase its y-scale to 10 to stretch it out, and move it horizontally so the end points lie on the two objects.

In the dspline sub-panel, you'll see the settings for the daemon that you will get to know well by the end of this tutorial. In the top part are the 3 strengths: vortex, axial and radial. These set scales for the strengths for the entire daemon, which means the strength at any CP is this global strength multiplied by the CP's strength value. For example, at CP 1, if the CP axial value is 0.5 and the global value is 50, then the axial force at CP 1 is 25. If the global values are all 0, the dspline is essentially disabled.

The vortex force causes particles to turn around the axis of the spline (positive values for clockwise looking along the spline from CP 1 to 3). The axial force pushes particles along the spline parallel to the axis (positive to move from CP 1 to 3). The radial force moves particles normal to the axis (positive values to pull toward the axis).

We want to run some simple tests to check the behaviour and see what sorts of values of strength we'll be talking about, to get the fluid to move at the speeds we need. Check in the Scene Tree and you'll see the dspline has been added automatically to the emitter. Don't add the objects to the emitter, as we don't want them to actually interact in this scene.

Try some values, both negative and positive, for the axial strength and run the simulation. Note that the first throw and catch from the sphere to the cube happens from about frame 60 to 90, so you may want to run the simulation starting at frame 60 by playing the timeline to that point, then hitting Action. You'll see that for positive values in the tens (30-70) the particles move across in the right sort of time, but they also blast right past the cube. To make them stop, when they reach the halfway point you need the axial strength to reverse to a negative value.

To get this reversal to be smooth and easy, we'll use an expression for the axial strength. For the axial strength parameter, access the Curve Editor and in the expression tab, enter the following:

10*cos(2*3.14*0.4*t)

A cosine function starts out positive, and cycles smoothly between positive and negative.

The expression above is built that way because for cosine (and also sine), we know we have:

A*cos(2*pi*f*t)

where A is the amplitude of the wave, pi is the constant 3.1415..., f is frequency of the wave (cycles per second), and t is time. The value 2*pi is the period of the cosine function, and f*t is the number of wavelengths -- so 2*pi*f*t measures the total number of periods at time t.

In the expression we just added to the scene, we made the axial strength maximum 10 (amplitude), and the frequency 0.4 which works out to the cosine going from positive to negative over about 30 frames. The tips section at the end has more on expressions.

Running the simulation now, you can see the fluid doesn't get very far in 30 frames before being pushed back. Increasing the amplitude to make the maximum force greater and push the fluid faster, you can find what sort of values are needed: at an amplitude value of about 60, the fluid blob oscillates neatly between the ends of the dspline. This makes a good starting magnitude for the axial strength.

It's likely that this value will change as we make the end points of the spline move with the objects and also make the fluid move in more interesting ways. Unfortunately, because the throws and catches are not perfectly timed, we won't be able to count on using the cosine expression to control the fluid. But it's worth keeping in mind this possibility in case you can use it in future, as it's faster than keyframing.

4. Add center object and link objects to dpline

Add the Centercube object at the center of the dspline, and link the CPs to the objects in the scene. Animate the Centercube by averaging the end positions and adding 2 meters of height to make it an arc. Animate the z-axis motion of the ends using sums of sine functions (pseudo-noise).

We're going to work toward the final animation of the dspline, since we need to work with this motion and make the fluid move to its pace. After finalizing the dspline's motion, we can figure out what other daemons we might need or want, their parameter values and finally their animation.

First, we will want to control the position of the center CP of the dspline (CP 2). The easiest way to control the CP positions is by linking them to objects. We have the end objects for this, but not the center so let's bring in another object for this purpose.

Import from the objects directory the Centercube.obj, which is just a cube object in .obj format. Objects can be imported in groups from SD files, but then you cannot delete single objects of that group from the RF3 project. You can only work with individual objects if they are in .obj format.

After importing the Centercube, go to the daemons tab, change the dspline's y-scale back to 1 (not needed to be 10 anymore), and in the dspline's dspline subpanel, LMB-click on the EDIT button to activate access to the CPs. In the viewport, you will see as you alter the CP index from 1 to 3 that the selected CP is highlighted.

Switch to CP 1, and use the CP link button to link it to the sphere object. Link CP 2 to the Centercube, and CP 3 to the cube.

Now hit the play button and you should see the spline end points animated with the objects. The center point is static since the Centercube is not animated yet.

We could painstakingly keyframe the Centercube so it has motion that suits the throw and catch motions of the sphere and cube, but there's an easier way for this scene. Basically, all we want to make sure of is that the center of the fluid's trajectory gives it a nice arc relative to the end points, and that it is always between the end points. We can handle this with expressions: average the end positions to make sure the Centercube is always between the ends, and add a few meters to the height to make an arc.

First, we want to be able to access the Node values of the animated objects in the Curve Editor, so we need to transfer their scene data values to the Curve Editor. All animated objects imported in SD format initially have baked, un-alterable Node values. For each object, you can make their Node values accessible in RF3 by hitting the SD<->Curve button in their Node subpanel. Do that now for both the sphere and cube. You'll see their Node parameters go from being grayed-out to being white like all other editable parameters. If you haven't noticed previously, you'll also see that they are only animated in the x and y directions. We'll add in z-direction animation a little later.

Let's start work with the Centercube. Add the x, y and z position parameters for the Centercube to the Curve Editor (RMB-click on each parameter, selecting open curve). For each one, go to the expression tab and use the D vars pulldown menu to set the following (you can cut and paste these if you want) :

x-position: (cube.position_x+sphere.position_x)/2

y-position: (cube.position_y+sphere.position_y)/2

z-position: (cube.position_z+sphere.position_z)/2

These are just averages of each of the position values, so the center cube stays in the middle at all times.

Now add 2 meters to the y-position expression, making it:

2+(cube.position_y+sphere.position_y)/2

You should now see the dspline forming a nice arc. Play the animation to check the behaviour looks right.

NOTE: Dsplines can sometimes show the quirky behaviour of having their CPs apparently not correctly rotated relative to their linked objects. If you notice the end CP rings in this scene not facing along the spline toward the Centercube, you are seeing this effect. To get the CPs to snap back to the right position, select the problem CP and then in the Node subpanel alter one of the position values slightly. You should see the CP's ring snap to the right relative rotation. Change the position value back to 0 and you are done.

Now we'll add animation to the z-direction of the end points, and because of the expressions we've just added the Centercube will have it's animation in the z-direction driven as well.

The sphere and cube came with only x and y direction animation, but we want the end motions to look natural and so not just constrained to the x-y plane. We haven't got much to go by except wanting a realistic, smooth, but noisy and natural looking motion. The other thing we have is the natural pacing of the scene, with a throw to catch time of about 30 frames and a period between 2 throws of about 100 frames. We can again use expressions to get something to fit this.

Bring up the Curve Editor and add the z-position parameters for both the sphere and cube. For one of these, go to the expressions tab and paste in or type this:

2*(sin(2*3.14*0.2*t)+0.7*sin(2*3.14*0.4*t)+0.4*sin(2*3.14*0.8*t)+0.2*sin(2*3.14*1.6*t))

Although this looks a little complicated, it's actually quite a simple expression that is just a sum of sine waves, multiplied by 2 to increase the amplitude overall. This expression just takes 4 sine waves, with reducing amplitude and increasing frequency, and superimposes them. Each sine wave adds more twists and turns, generating a noisy, but smooth and repeating pattern so we get the sort of wavery motion we are wanting. You can add as many sine curves as you want to get different-looking curves. In our case, the frequencies were chosen to surround the frequencies that are natural to the scene (30-frames = 1 s = frequency of 1 for a throw-catch period; 100-frames ~ 3 seconds = frequency of 0.3 for a throw to throw period) so the z-direction movement would not look weird and unnatural.

For the other object, create another (not identical) expression to give it a similar look, but sufficiently different that the objects don't look like they are doing the same thing. We used:

1.7*(sin(2*3.14*0.3*t)+0.7*sin(2*3.14*0.5*t)+0.4*sin(2*3.14*0.9*t)+0.2*sin(2*3.14*2*t))

You can compare the curves in the curve editor window visually, to ensure they are reasonably different but still similar in character.

We are now done with animating the objects and can return to controlling the fluid movement.

5. Test the fluid motions, and decide on additional daemons: first, drag daemon

Run additional experimental runs to see what values are needed in the dspline to get the fluid to follow the animated motions and arc trajectory. Apply a drag daemon to reduce the momentum of the particles during the throw.

You should still have the cosine function driving the axial strength of the dspline, so go ahead and run some new tests with the animated version of the dspline. Alter the values of axial strength and also the radial strength to see how well you do at keeping the fluid moving along the dspline to the other end, and in the time needed.

It won't take you long to figure out that this task is virtually impossible with just a dspline daemon. Various problems arise, most obviously 2:

1. It is difficult or impossible to hold the fluid particles at one end for any period of time, while the end is moving around, because the particles get left behind and scatter.

2. It is difficult to get the particles to follow the dynamically moving dspline path, and they tend to shoot away and scatter as they move across.

This illustrates the important point that if you have a scene with things moving that affect your fluid, the fluid's momentum will make it quite difficult to control and the behaviour will be very different to a similar situation but where daemons and objects are not moving around. Sometimes this is OK and you can let the fluid do what it wants, but other times (like here) this is not good enough.

Our first addition to this scene should be fairly obvious: we want to control the momentum during flight and the most obvious way to do this is with a drag daemon.

Add a drag daemon and play with the strength value, running some test simulations. We aren't yet worried about actually getting the timing right, that will come a little later. You should be able to see, however, that a drag strength of 0.1-1 stops the particles from dispersing so wildly, even if you greatly increase the maximum magnitude of the axial strength, for example to values like 600. Even with significant radial strength values, it is still not possible to get the fluid to do exactly what we want with just the dspline, but the drag daemon does help.

6. Add object daemons for control at the ends

To hold the particles at the ends of the dspline prior to each throw, apply object daemons to half-sphere objects created for this purpose, link them to the dspline end points, and scale them up to 8. Make the force a repulsion so that particles get trapped between the dspline force and the object force. Alter the dspline CP radius values so their zone of influence covers the area (CP1 and CP3 =6, CP2=8).

We now want to apply control to what the particles do at the ends of the dspline. First, the particles have to be held to the moving end point prior to being thrown. Second, they have to be released quite suddenly and then permitted to follow the spline. Finally, the particles have to be successfully caught and held at the other end, without scattering and wild splashing. Let's take this one step at a time -- as it turns out, it's really the same problem for all three parts.

In terms of holding the particles at the end before throwing, we need a way to trap them despite the end moving around a lot. One way to do this is with an attractor, which can work well but is less useful when things move quickly as particles tend to scatter. They also don't work so well for the other parts of the throw-catch cycle. You can try this for yourself by adding attractors and linking them to the sphere and cube objects.

A good way to really control the particles is by surrounding them with a strong force field. We already have one source of force -- the dspline's axial force. This can be used to push the particles beyond the dspline's end. We then need a second force pushing from the other side, a little farther from the dspline end, to push the particles back and stop them from going off into space.

You can again try to do this with an attractor with negative strength (a repulsor), but the repulsion will be directed radially and will tend to scatter the particles rather than hold them. What we need is a force field coming from all, or at least most, sides. To do this, RF3 has a special and very useful daemon: the object daemon.

The object daemon applies a force field in the direction of an imported object's normals. So, you can fashion special objects to create shaped force fields. This is what was done here: in a 3D package we created simple half-spheres, to act as force field end-caps to the dspline.

You already have these special objects in your objects directory, so import them now (sphereleft and sphereright). Then, link them to the ends of the dspline -- actually, link them to the objects there (sphereleft to sphere, sphereright to cube).

Next, we want to make sure these objects will encompass the blob of fluid at each end of the dspline, with space to spare, even with plenty of interesting sloshing motions. Scale both objects up to 8 in x, y and z.

We now need to add object daemons and tell them which objects to use.

Go to the daemons tab and add 2 object field daemons. Rename them object_left and object_right. In the object field subpanel, use the object setting to pick the sphereleft for object_left, and sphereright for object_right.

The distance value is the distance from the mesh that the force will be applied. We want the force to reach to the center of the half-spheres, so set this to 5 as a start point.

Before testing, we need to make sure the dspline's area of influence will encompass the moving particles. The best thing here is to overdo it a little in the center, where the fluid may slosh a little wildly as it moves along the arc of the spline, and match the size of the sphere objects at the ends. So, for the dspline activate the CP editing, and set the radius of CP1 and CP3 to 6, and that of CP2 to 8. You should see these values reflected in the circles around each CP.

Now we want to test how well this setup works to trap particles. First, let's just try to hold the particles at the left (sphere object) end of the dspline. In the dspline, delete the cosine curve for the axial strength and make the value a constant negative value. This will mean the dspline will be pushing the particles toward the sphere constantly. Run some test simulations with different values of this axial strength and the strength of object field (also negative, to push the particles away). Also try using positive values of the dspline's radial strength, which will help keep the particles in to the axis of the dspline.

Your tests should show you that for object field strengths of greater than about -50, the particles have a tendency to escape from the sphereleft object when the motion gets quite fast. For values much less than about -100, the particles are held perhaps too well to look very natural. The actual values you decide on depend on your own judgement. We found reasonable-looking results at this stage for a object field strength of -100, and dspline axial strength of -50 and radial strength of 20.

Now that we have the particles held in place, it's easy to see how to release them, and also how to catch them. To release them, since the object field is already pushing them away, we just have to reverse the axial strength of the dspline. To catch them at the other end, we just let the dspline continue to push them into the other object field. All that is left to do -- besides the usual testing and tweaking -- is to animate the axial strength of the dspline to coincide with the throwing and catching motions of the sphere and cube objects. For that, we'll do some easy keyframe animation.

7. Keyframe animate the axial strength for the throw-catch cycle

Set keyframes for the axial strength of the dspline in a boxcar shape, approximately ranging from -10 to 10, in time with the throw and catch actions of the objects. Scale the keyframe values to go from -100 to 100 to start with, and run tests to figure out values that give good-looking results. Adjust the object field strength values to compensate for changes to the dspline axial strength, and work out values for the dspline's radial strength as well.

Now we want to keyframe animate the axial strength of the dspline, to move the particles down toward the other end and back again. To do this, we will use the motion of the sphere and cube objects as reference, and manually set keyframes for the strength.

In a real production you would probably take great care with each keyframed value of the axial strength, but we're going to cover some keyframing techniques that allow you to get this job done quickly but still reasonably well. Taking a lot of care over each point would be time consuming since there are a number of throws and catches over this fairly lengthy sequence, and we will be doing tweaking of the global values so we want to have quick ways of altering the entire sequence rather than pushing around individual control points all day long. To do this, we'll use the Scale and Pan functions of the Curve Editor to set values for groups of keyframes.

In the Curve Editor, bring up the x-positions of the sphere and cube objects. Select the sphere.position X, and along the top hit the Fit button to fit the sequence to the graph window.

You can see from playing the animation that the throw action of the sphere corresponds to the major positive increases. These changes are where we need the dspline's axial strength to go from strongly negative (keeping the particles at the sphere end) to strongly positive (pushing the particles along the spline to the cube at the other end).

Set the value of the dspline axial strength to -10, and bring it into the Curve Editor along with the x-positions sequences of the sphere and cube. We assigned the -10 value simply so the first point would be visible along with the sphere.position x sequence.

Using RMB-click, create keyframes at the bottom (start) end of each throw action in the sequence. The actual values don't matter as we'll set them all as a group -- we just want the times to coincide with the action.

Now LMB-drag around all these new keyframes, and hit the Scale button on the top bar. Set the y-scale value to 0.0 and hit return, to set all the values to 0 (but preserving the key timings). Also, RMB-click and set the selection to linear interpolation, which is sufficient for our needs here.

Now hit the Pan button, and set the pan y value to -10, and hit return. All the values have now been set to -10. This combination of multi-selection, scaling to 0, and panning to a value is a quick way to set idential values for groups of keyframes. We'll scale these values later as a group as we tweak our dspline settings.

Now we want to set all the values that the dspline strength goes to for the completion of each throw action by the sphere -- so we want to end up on a positive value. We'll use +10 to make the values symmetrical about 0, allowing easy scaling later.

At the top end of each throw action, set another group of keyframes (again, not worrying over the values, just the times). After setting them all, use shift-LMB-click to select each point in this group. Finally use the scale and then pan functions to place these values at +10.

By playing the animation (not simulating), figure out the places in the cube.position x sequence where the cube throws the fluid, and set equivalent keyframes for the dspline axial strength. Again set selections to linear interpolation, and use the scale and pan functions to set the group of keys at the start of the cube's throws to +10, and the keys at the end of the throws to -10. You should now have a boxcar-shaped curve, going from -10 to +10 in time to the throwing cycle.

We know from our earlier tests that the dspline axial strength has to be larger than +/-10 to move the particles between the objects to achieve the right timing, so select all the keys by LMB-drag and scale in the Y direction by 10. The curve now goes between -100 and +100. You can now return to this sequence whenever you want to adjust the dspline axial strength values, and tweak as much as you like. For example if you now decide that you want the axial strength to go between -20 and +20, just select all the keyframes and scale in the Y direction by 0.2.

We can now start some new tests to figure out the sorts of strength values we need to resolve the scene. Try running a test simulation now to see how the current values look, just for the first 190 frames (2 throws). This will just take a couple of minutes on a reasonably fast workstation, provided you set the resolution to the low value suggested earlier.

Replay the simulation results and see how you like it. The fluid gets thrown and caught at both ends, but the throws are a little "soft" and the fluid takes a little too long to reach the other end.

Try higher dspline axial strength values. You may wish to also adjust the object fields -- if the dspline axial strength is much greater than these, the particles will get pushed well beyond the ends of the spline. Increasing the object field distance will help reduce this effect as well. Be careful not to overdo the field object strengths and distances or the fluid will look too much like it is hitting an invisible object when it gets caught. Remember that the idea is for the fluid to be moved around by force fields, so that it sloshes back and forth rather than flattening against something. If we wanted to have the look of hitting an object, we could just make the fluid do that and avoid using the object fields altogether.

We settled on dspline axial strength values of +/-200, object field strengths of -200, and object field distances of 6, to give reasonably snappy throws and catches and a speed for the fluid's trajectory that looked natural and suited the speed of the throws.

8. Additional deamon effects: surface tension, noise, vortex strength

To get a more mercury-like effect, add a surface tension daemon with strength 100. To get added interesting fluid motions, add a noise deamon with strength 20, and set the dspline's vortex strength to 60. Modulate the radial and vortex strengths for the CPs of the dspline so the vortex strength is halved at the ends, and the radial strength is halved in the middle.

We now have the basic throw and catch motion of the fluid resolved, and can move on to some added effects to give the animation more visual interest. This stage of the work can telescope into a long, time-consuming process as there are obviously a lot of different things that can be animated, tweaked and added. For our purposes, let's just settle on making the fluid more mercury-like by adding surface tension, and give it some sloshing and swirling motions as it travels between the sphere and cube, using the dspline's vortex strength and a noise daemon. We'll also adjust the strengths on the dspline's CPs to refine the motions a little.

First, add a surface tension daemon and set the strength to a fairly large value, so it's effects are obvious -- we used 100.

Next, add a noise field daemon and again increase the value, this time to 20. This value is a fraction of the dspline axial strength (+/-200) and equal to the dspline radial strength (20), so it is in the right ballpark to have a significant, but not dominant, influence. You can try some tests with noise strength values of 200 or higher to see how noisy the motion becomes when the strength becomes a dominant force in the scene. This isn't what we're aiming for in this scene, but it might be in others.

Now go to the dspline settings and set the vortex strength to 60. This will make the particles swirl about the spline axis, giving them a nice dynamic look sort of like putting a spin on a baseball as you throw it.

Ideally, we'd like to make the middle part of the fluid trajectory the most sloshy and swirly, and have tighter, less swirly behaviour at the ends to give the impression of greater control. In fact we can achieve this easily by adjusting the values for the dspline's CPs.

Activate the CP editing in the dspline subpanel, and reduce the end values of the CP vortex to 0.5 (for CP1 and 3). This means the vortex strength at the ends will be 0.5 of the global vortex strength of 60. Next, make the the CP radial of CP2 (middle point) equal to 0.5. This means the radial pull will be half the global value (20), resulting in more freedom of the fluid to swirl and slosh in the middle area, rather than being held tightly to the spline.

At this point you may wish to run a few test simulations and then tweak values to get the scene looking like you want it to.

9. Increase the emitter size, resolution and max particles for the final run.

To set-up for the simulation to get the final results, increase the emitter scale to 2, up the resolution to 1, and reduce the object field distances to 5. Initialize the scene in a locked state for a few seconds, and then run the final simulation.

We will now set the emitter up to run the final simulation, with enough particles to look interesting.

First, increase the size of the sphere emitter to 2 by setting the scale values, in order to get a bigger ball of fluid particles.

Next, increase the resolution from 0.1 to 1. You should now have more than 32,000 particles.

If you start the simulation now, you will notice that it runs very slowly and after a few frames you'll see the ball of fluid particles start to explode. These are signs that something is not physically stable in the scene. The cause is the strong force compressing the fluid on all sides, causing very large inter-particle forces which in turn produce very large particle velocities. In these conditions the simulation engine has to reduce the time step to a minimum in an effort to track the rapidly moving particles, causing the simulation to grind to a near standstill. Even so, the particles shoot away at high speeds. If left to run, this simulation may well cause a crash so be careful here.

When you see particles start to explode away and notice a simulation slows down enormously compared to what it seems like it should be doing, you should stop the simulation and try to figure out what is stressing-out the particles.

In this case, the fluid has little space to be compressed because the object field reaches almost to the center of the particle group. We can ease this by reducing the object field distances so they reach from the half-sphere object polygons to approximately the edge of the fluid blob: about 5 meters.

Now lock the scene and simulate for a few frames so the particle group does not start off in the scene as a perfect sphere. In a locked state the current values of the daemons will apply, but there will be no parameter animation of any kind.

When you are satisfied with the initial state of the fluid, stop the simulation, unlock, and save the file. You can now re-open the file at any time and just hit Action, to run the simulation -- overnight, for example. With 32,000 particles, this scene may take some hours to simulate, depending on the speed of your computer.

Congratulations! You've just resolved the scene and satisfied the director.

Tips:

- We could have got a similar effect using an attractor animated along a trajectory, perhaps with a linked vortex daemon to give us some swirl action. Or, instead of an object field at each end, we could have trapped the particles using direct interaction with the objects linked to the dspline ends. Or, we could have applied an array of attractors set to repulse near each end of the dspline. Each of these would have produced a slightly different looking animation and would require similar techniques to resolve the scene.

- If you followed the steps of this tutorial, you may have noticed the overall strategy of breaking down the problem into easier pieces. We first got the basic motion figured out, and then progressively added more features and details. This kind of animation layering approach is particularly important when working on complex scenes, as it's easy to get overwhelmed in the large number of daemons and parameters.

- In this and the previous tutorial, animation features of RF3 were covered but there are a number of additional things to say about RF3's animation capabilities. Below are a number of brief tips on this topic:

Saving and loading curves:

In the Curve Editor, in the file menu of the top bar, there are two very useful functions: load and save curve. Using save curve you can save the currently active parameter's sequence of keyframes, or save the expression driving the animation, as a .crv file. Using load curve, you can load any .crv file into a parameter. This makes a great way to lift the keyframes from an object in one file, and use them in another without importing the object itself. It is also a great way to save animations and expressions that were not easy to build, for re-use later. You can build up an archive of useful animations this way.

Expressions:

Users who are not too strong on maths may find using expressions a little daunting. Below we give a series of useful expression examples that can be used and re-used easily by just copying and pasting, and then adjusting some values. The advantage of expressions, besides the obvious of being able to use other parameters to drive values, is that they can achieve nice, smooth transitions and precise results without fiddling with individual keyframes.

Sine and Cosine:

The general form of a Sine curve (cosine is the same but shifted by a quarter cycle) is:

D+A*sin(2*pi*f*t)

where A is the amplitude, D is the vertical displacement of the curve, pi is ~3.14, f is frequency (cycles per second) and t is time in seconds.

An example showing a curve with amplitude 5, displacement 6, and frequency 2 is below.

This is a useful kind of curve for smooth oscillations, like bouncing balls. It gets more useful, however, when combined with other functions, as we'll see later.

Exponential:

The exponential is another basic, useful function. Two basic ways to use this are for growth/decay of a parameter, and for ease-in type behaviour. For growth/decay, we can use this:

D+A*exp(r*t)

where D is the vertical displacement, A is the amplitude at the origin, r is a parameter proportional to the rate of decay or growth, and t is time. Negative values of r produce a decay with time, positive values a growth. An example of decay is shown below.

Decay is particularly useful if you want to set up a parameter, such as drag strength, to start off in a scene at a high value, and then drop off quickly in the first few frames to a lower or zero value.

For ease-in behaviour, we can use this version:

D+A*(1-exp(r*t))

where D is the vertical displacement, A is the amplitude, r is the decay rate parameter, and t is time. A negative value of r gives ease-in type behaviour, as shown in the example below.

And finally, RF3's "if-then" function is important for being able to define sections of a curve, which is useful for turning on or off parameters at specific times, like that below.

You can also nest if-then statements. More on this below.

Time-shifting:

You can shift the time for all the above functions by a precise amount, by just replacing the time variable t with (t-S) where S is the shift you want. Below is an example of an exponential ease-in that has been time shifted to the right by 2 seconds (changed t to t-2). Doing this with sine or cosine functions means you can get the peaks or troughs to lie exactly where you want them.

Combinations of functions:

All the above functions are handy on their own, but are far more useful in combination. Below are some examples.

sine and if-then combinations: Using sine curves with a nested if-then allows you to clip out parts of the smooth sine curve to get things like symmetrical peaks and transitions between constant values.

To get a symmetrical sine peak (useful for a limited emission of particles, or pulsing forces from daemons) :

if (t<0.75/f,D-A,if(t>1.75/f,D-A,D+A*sin(2*pi*f*t)))

Again, D is the displacement, A is the amplitude, f is the frequency, and t is time. The values 0.75 and 1.75 are just fractions of a wavelength, to get the start and end parts of the sine wave right. Below is an example. Remember that if you wanted to shift this peak to the right by a time S, just replace the t with "(t-S)". In that case, the expression looks like:

if ((t-S)<0.75/f,D-A,if((t-S)>1.75/f,D-A,D+A*sin(2*pi*f*(t-S))))

Using the same approach, we can get a smooth transition between two constant values:

if (t<0.75/f,D-A,if(t>1.25/f,D+A,D+A*sin(2*pi*f*t)))

where we've just changed the amount of the wave we are clipping, and the value after the clipped-out part of the sine wave is made the peak value, rather than the trough value. An example is below, where the sine wave has been shifted to the right by 1 second.

Another smooth transition can be derived from using an exponential decay in combination with an if-then statement:

if (t<0, D+A, A*exp(r*t))

and here's an example, which has been shifted by 1.5 seconds to the right.

As covered in the tutorial, you can use sums of sine or cosine waves to get well-controlled noise-type behaviours. Combining these with other functions gives you more control. For example, if you wanted a parameter to vary in a noisy way initially, and then after some time to gradually tail off to a constant value, you could do it like this:

And finally, remember you can use parameters other than time in expressions, so you can drive one attractor with another's values. One useful example is the expression for varying a parameter based on the distance between two objects or daemons. There's no "distance" function built into RF3, but it's straightforward to calculate as:

sqrt((x1-x2)^2 + (z1-z2)^2 + (y1-y2)^2)

where the first object or deamon has position (x1,z1,y1) and the second has position (x2,y2,z2). You could use this in an if-then statement to turn an emitter on or off based on how close an object comes to it.

Tutorial 3: Play Catch -- Daemons, Objects and Expressions