INSIDE 3DS MAX® 7 [Electronic resources] نسخه متنی

Testing and Stabilizing

Open Dolphin&Rider_02.max from the DVD or continue with my_Dolphin&Rider_02.max from the previous section.

Before we can use our ice chunks in reactor, we need to give them some mass. Objects that have no mass cannot experience an impact and therefore can't be fractured or affected in any other way within the reactor virtual world.

Once the ice chunks have mass, however, reactor's gravity affects them and they immediately begin falling, rather than sitting and waiting nicely to be fractured. reactor does offer a very simple way to prevent objects from moving until they are affected by some other object or system. Here's the procedure, using our four fragments:

This technique would work fine if we just needed to immobilize the fragments in midair. In our final scene, however, this will not be sufficient, because we will be placing the ice chunks in water, with waves that will affect them just like collisions with solid objects. We want them to be affected by the water, but not so much that they start breaking apart before the dolphin hits them. For that, we need techniques that stabilize the fragments despite the presence of forces that tend to destabilize them. So let's explore what's available to accomplish that kind of stabilization.

For testing purposes, we'll create a box to act as a platform for the ice chunks to sit on. We won't give the platform any mass, so it will not fall, but it will support the ice chunks.

The techniques we use here will also work when the fragments are in water. However, stabilizing ice chunks in water can be a tricky business and hard to judge. We'll learn the ropes on dry land first.

It's not easy to position the ice chunks so that they sit stably on the platform but do not interpenetrate it. If the ice chunks start in an unstable position, they will shift slightly at the beginning of the animation and are quite likely to fragment. This is not what we want. We want the fragmentation to begin only when the dolphin hits the ice chunks.

Surprisingly, making the initial shift very small can increase the fragmentation. This may be because a fragment can start bouncing back and forth between the platform and other fragments very fast, creating multiple sequential interpenetrations with the neighboring fragments. As we saw in the earlier exercise, interpenetrations tend to cause explosive fragmentation. In some cases, initial instability can actually knock multiple fragments out of the viewport in the first instants of the animation. To the viewer, it looks as if they just disappear. reactor permits users to store and view collision data, so you can analyze situations like this in detail to determine exactly what is going on.

Luckily, it's easy to allow the ice chunks to find a stable position and then assign that position to the ice chunks in the first frame of the animation. That way, there is no initial movement and no danger of fragmentation before the dolphin hits. The key to this process is reactor's Update MAX function, which assigns the current state of the animation to the beginning of the animation.

Here are the detailed instructions. They come in three parts: initial testing of the fracture, storing and viewing of collision data, and stabilization of the fragments.

Note

Your results may vary somewhat from those described in the coming sections, depending on exactly where you positioned your Slice Planes. If you want to follow along and get exactly the same results described, open Dolphin&Rider_02.max on the DVD.

Initial Testing of the Fracture

First we'll create the fracture and test for initial instability.

We do have some initial instability, with more visible results when the platform is at 35 on the Z axis than when it is at 36. At this point, we could just proceed to stabilizing the fragments. Instead, let's get a more detailed view of what is going on in those first few instants of the animation. We can do this by storing and viewing collisions.

Storing and Viewing Collisions

When reactor creates keyframes, it can also optionally store data about every collision that occurs. Initially, the data is stored only in memory, not on the disk. You can view the collision data without saving it to disk, and you also have the option of saving to a text file. Since the number of collisions can be overwhelming, reactor provides a filtering capability so that you can narrow the collisions stored to make it easier to find the ones that interest you. You set the filters before storing the collisions in memory.

So far in this chapter, we haven't been creating keyframes; we've just been previewing the animation. Now we'll create keyframes and store collisions. We'll try it once with the platform at 35 and again with the platform at 36. Once you have an impression of what is going on, we'll do some filtering to make it easier to eyeball the data.

Creating Keyframed Collisions

Here's the procedure for our first test, with the platform at 35.

Stored Collisions

Here's a rundown on what each column means:

• Ticks
  The time, in ticks (1/4800 of a second), when the collision occurred. We're using a standard video frame rate of 30 frames per second, so there are 160 ticks in each frame.

• Frame
  The time, in frames, when the collision occurred. If the current time unit is something other than frames (such as SMPTE timecode), this column will reflect that.

• Object A
  One of the two objects involved in the collision.

• Object B
  The other object involved in the collision.

• Point
  The point, expressed in world coordinates, where the objects collided. (Due to a bug in max 7, the points displayed onscreen are wrong. If you click the Save button on the Stored Collisions window to save the data as a text file, the text file contains the proper points.)

• Normal
  This expresses the direction (but not the velocity) of the impact in terms of the XYZ coordinate system. The direction is expressed as if object A were standing still and only object B moved (even though the opposite may be the case, or both may be moving). It's expressed as three numbers, representing the X, Y, and Z axes. Imagine an arrow representing the impact. Consider the length of the arrow to be one unit. The three numbers tell you how far you need to move in the X, Y, and Z directions to get from the tail of the arrow to the point. The mathematical term for this is the unit normal vector of the collision.

• Speed
  The relative velocity of the two objects along the unit normal vector. If you save the data to a file, this will be listed as NRV (Normal Relative Velocity).

• Phantom
  This column indicates whether the collision involved a phantom rigid body, one that can pass freely through other bodies. Possible values are Not Phantom (the collision didn't involve a phantom rigid body), Entering (the collision time shows when the phantom rigid body started penetrating the other rigid body), and Leaving (the collision time shows when the phantom rigid body completely exited the other rigid body).

Here are the first four collisions in the data we just created. (They are in the format produced when you click the Save button to save the data as a text file.) All four collisions involve the platform and Object02.

Time : 0

A : Object02

B : platform

Point : ( 43.4185 8.4282 34.8831 )

Normal : ( 4.60904e-006 7.0279e-005 1 )

NRV : 0

Phantom : Not Phantom

Time : 1

A : Object02

B : platform

Point : ( 43.4185 8.4282 34.8831 )

Normal : ( 4.60904e-006 7.0279e-005 1 )

NRV : 0

Phantom : Not Phantom

Time : 16

A : Object02

B : platform

Point : ( 43.4185 8.4282 34.8831 )

Normal : ( 4.60904e-006 7.0279e-005 1 )

NRV : 1.20694

Phantom : Not Phantom

Time : 18

A : Object02

B : platform

Point : ( 43.3884 8.44 34.8482 )

Normal : ( 3.01953e-005 4.6361e-005 1 )

NRV : 167.956

Phantom : Not Phantom

If the platform were moving, all four collisions would be directed straight up along the Z axis, as indicated by the final 1 in the unit normal vector. (Actually, of course, it's Object02 that's moving, and the direction of movement is down, not up.) Essentially, all the unit normal vectors are equivalent to (0,0,1), the first two numbers being extremely small in each case. (For instance, 4.60904e-006 is .00000460904.)

The first two collisions show zero velocity (presumably a minuscule velocity rounded off), and the third shows a very low velocity (fewer than 2 units per second). The fourth, however, suddenly shows a velocity of about 168 units per second.

Close the Stored Collisions window. Select Fracture01 and go to the Modify panel. You'll see near the bottom of the Properties rollout, in the Break On section, that this fracture breaks when one of its fragments is involved in a collision with a velocity of 100 units per second or more. (This is the default setting.) So this fracture starts breaking up almost immediately, on the fourth collision between the platform and Object02, when the velocity first exceeds 100 units per second.

Move the platform to Z = 36, create animation again, and view the stored keyframes. There are 15 initial collisions between the platform and Object02:

Time : 0

A : Object02

B : platform

Point : ( 43.4185 8.4282 35.3831 )

Normal : ( 8.73185e-007 1.33144e-005 1 )

NRV : 0

Phantom : Not Phantom

Time : 8

A : Object02

B : platform

Point : ( 43.4185 8.4282 35.3831 )

Normal : ( 8.73185e-007 1.33144e-005 1 )

NRV : 0

Phantom : Not Phantom

Time : 16

A : Oject02

B : platform

Point : ( 43.4185 8.4282 35.3831 )

Normal : ( 8.73185e-007 1.33144e-005 1 )

NRV : 0.643699

Phantom : Not Phantom

Time : 23

A : Object02

B : platform

Point : ( 43.36 8.45117 35.315 )

Normal : ( 6.10491e-006 1.37024e-005 1 )

NRV : 81.8201

Phantom : Not Phantom

Time : 32

A : Object02

B : platform

Point : ( 43.3017 8.47404 35.2468 )

Normal : ( 1.5911e-005 1.16828e-005 1 )

NRV : 81.2282

Phantom : Not Phantom

Time : 39

A : Object02

B : platform

Point : ( 43.2435 8.49689 35.1791 )

Normal : ( 1.86716e-005 0 1 )

NRV : 81.2799

Phantom : Not Phantom

Time : 47

A : Object02

B : platform

Point : ( 43.1855 8.51968 35.1113 )

Normal : ( 2.42683e-006 6.6013e-006 1 )

NRV : 80.6884

Phantom : Not Phantom

Time : 64

A : Object02

B : platform

Point : ( 43.0698 8.56508 34.9767 )

Normal : ( 1.17392e-005 1.14664e-006 1 )

NRV : 79.5036

Phantom : Not Phantom

Time : 80

A : Object02

B : platform

Point : ( 42.9547 8.61027 34.8441 )

Normal : ( 8.05859e-006 8.62837e-006 1 )

NRV : 78.3188

Phantom : Not Phantom

Time : 96

A : Object02

B : platform

Point : ( 42.8402 8.65524 34.7135 )

Normal : ( 7.59867e-006 5.01621e-006 1 )

NRV : 77.1333

Phantom : Not Phantom

Time : 112

A : Object02

B : platform

Point : ( 42.7263 8.70001 34.5849 )

Normal : ( 1.33756e-005 2.07282e-006 1 )

NRV : 75.947

Phantom : Not Phantom

Time : 128

A : Object02

B : platform

Point : ( 42.6129 8.74456 34.4582 )

Normal : ( 6.45438e-006 3.80507e-006 1 )

NRV : 74.7607

Phantom : Not Phantom

Time : 144

A : Object02

B : platform

Point : ( 42.5001 8.78887 34.3335 )

Normal : ( 5.95529e-006 2.11222e-006 1 )

NRV : 73.5742

Phantom : Not Phantom

Time : 160

A : Object02

B : platform

Point : ( 42.3878 8.833 34.2108 )

Normal : ( 2.73037e-006 9.18103e-006 1 )

NRV : 72.3864

Phantom : Not Phantom

Time : 176

A : Object02

B : platform

Point : ( 42.2762 8.87688 34.0901 )

Normal : ( 1.14404e-005 1.22867e-006 1 )

NRV : 71.1988

Phantom : Not Phantom

The direction of the impact is the same as before. But the highest velocity achieved is less than the 100 units per second required to break the fracture.

Filtering Collisions

Let's filter collisions to see if the trends established in the first instants of the animation continue through the rest of the animation. We'll do this by looking only at collisions with a velocity of 100 units per second or more.

The numerical data matches the previewed animation in the Real-Time Preview window and the keyframed animation in the viewports. They all reflect the fact that any initial instability in a reactor fracture can be magnified if the fragments start life too close to another object, particularly an immovable object like the platform. (A similar phenomenon can occur when a fragment starts life between two other fragments, particularly if there are interpenetrations. See the first paragraph in "Fracture Tips" in the 3ds max 7 user reference.)

Now that we've investigated the initial instability in some detail, let's move on to stabilizing the fragments.

Stabilizing the Fragments

We are going to be concerned here with two different kinds of stability:

• Physical balance

• Nonreactivity, which includes reduced susceptibility to fragmentation

The two are interrelated: If a group of fragments is out of balance initially, it will start moving as soon as the animation starts. That very movement may trigger fragmentation. This, in fact, is exactly what's happening to the fragments we're working with now.

Let's start with nonreactivity. reactor has a number of features aimed at taming feisty fragments that are blasting apart more easily or more enthusiastically than you'd like. For instance, there are three parameters in Utilities > reactor > World > Fracture Penetrations that are designed to make reactor less aggressive about pushing interpenetrations apart (Figure 16.30).

• Separation Time can be increased to slow down separation of fragments.

• Velocity Cap can be decreased to reduce the top achievable velocity.

• Scale Tolerance can be reduced to effectively raise reactor's standards for what constitutes a collision or an interpenetration.

All three tend to result in less explosive, though possibly also less realistic, fragmentation. (Realism is decreased if visible interpenetrations occur, owing to fragments not separating fast enough.) Reducing the Scale Tolerance value, because it raises the bar for what constitutes a collision or an interpenetration, can reduce not only the intensity but also the number of collisions and interpenetrations that reactor perceives.

Of these three parameters, Scale Tolerance is generally the most powerful. Scale Tolerance changes the distance at which reactor considers that fragments have collided or interpenetrated. This distance is called the Collision Tolerance. It might seem logical that objects would have to touch in order to collide. This would be true if reactor checked for collisions continuously. In reality, reactor checks at regular, discrete intervals (called simulation time steps). A fast-moving object can move into an interpenetrating state from one simulation time step to the next. By triggering the collision reaction a little bit before the objects touch, reactor prevents some of those interpenetrations.

This does mean that objects can begin to affect each other slightly before they actually touch. However, it turns out that viewers are much less likely to see this little bit of separation than the same amount of interpenetration. Think of the standard Hollywood cowboy punch, in which Cowboy A swings his fist 3 inches from Cowboy B's chin. No contact is ever made, but Cowboy B jerks his head backward. As long as the viewers see it from the correct angle, they'll be convinced that he really was hit. Compare that with the fist's appearing to penetrate 3 inches into Cowboy B's head. There is no angle from which this will look right.

By default, reactor triggers nonfracture collisions when objects are 3.937 units apart. This Collision Tolerance (for the virtual world as a whole) is set at Utilities > reactor > World > World Scale > Col. Tolerance. Since by default reactor equates 39.37 max units to 1 meter (see the first parameter in the World Scale section in Figure 16.30), 3.937 units equals one-tenth of a meter, or 10 centimeters. Thus, reactor triggers collisions when nonfracture objects are the equivalent of 10 centimeters apart.

All that applies to nonfracture collisions. However, with fractures, a smaller collision tolerance is unlikely to cause visible interpenetrations: Fragments typically begin life snug against one another (so interpenetrations can't be seen), and thereafter either stay so close that interpenetrations still can't be seen, or else blast apart and never come back together so interpenetrations don't occur. There's very little opportunity for the scenario in which a fragment moves from a state of non-interpenetration to a state of interpenetration from one simulation time step to the next. In addition, fragmentation usually happens very quickly and involves multiple fragments, so that we perceive it more as an overall event, without being able to precisely follow the positions of individual fragments. For these reasons, fractures can generally accommodate a much smaller Collision Tolerance than 10 centimeters.

Scale Tolerance is a multiplier, ranging from 1 to 1, that scales the Collision Tolerance value for fractures without affecting the Collision Tolerance value for the virtual world as a whole. The default Scale Tolerance value is one-tenth (0.1), making the Collision Tolerance within fractures one-tenth of the World Collision Tolerance. Thus, by default, reactor triggers collisions when fragments are .3937 units (equivalent to 1 centimeter) apart. (Collisions between a fragment and a nonfragment use the World Collision Tolerance value. Only collisions between two fragments are affected by Scale Tolerance.)

If you set Scale Tolerance to 0, reactor doesn't detect a collision until fragments are touching. If you set a negative value for Scale Tolerance, fragments will actually interpenetrate before a collision is detected.

When fragments are fairly large in relation to Collision Tolerance, even a Scale Tolerance value of 1 may not reduce collisions as much as you want. In the project in this chapter, for instance, the bottom fragments average 75 units at the base (since the initial pyramid's base was 150 units square), so shaving approximately 4 units off the Collision Tolerance (by changing Scale Tolerance from the default of 0.1 to the maximum negative of 1) might not be expected to have a huge effect. In fact, it doesn't.

Adjusting Collision Tolerances

To attain greater stability in the overall effect, try this:

Eleven collisions are better than 17, but still not what you'd call stability.

Energy Loss and Stability

Another parameter in the nonreactivity category is Energy Loss. Select the fracture and go to the Modify panel. Energy Loss is near the bottom of the Properties rollout (Figure 16.31). Energy Loss determines what percentage of its energy a fragment loses when it breaks off. Increasing Energy Loss makes for less energetic fragmentation.

In the case of our project, the nonreactivity parameters, even when taken to extremes, do not prevent the initial fragmentation. So let's see what we can accomplish through physical balance.

Physical balance can be achieved through a simple, straightforward procedure that involves temporarily disabling fragmentation, allowing the fragments to settle down into a state of equilibrium, and then assigning that state to the fragments at the beginning of the animation.

Here are the details:

This example is typical: If you're looking for initial stability, physical balance is often the easiest way to achieve it. The nonreactive parameters are usually more appropriate for moderating the action once fragmentation begins.

Now that we've achieved a state of equilibrium, let's disturb it with a dolphin.