Testing and StabilizingOpen 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
Initial Testing of the FractureFirst 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 CollisionsWhen 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 CollisionsHere's the procedure for our first test, with the platform at 35.
Stored CollisionsHere's a rundown on what each column means:
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 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 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 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 CollisionsLet'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 FragmentsWe are going to be concerned here with two different kinds of stability:
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).
Figure 16.30. The World rollout of the reactor utility.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 TolerancesTo 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 StabilityAnother 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. Figure 16.31. The Energy Loss setting, near the bottom of the Properties rollout of the Modify panel.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.
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. |
![[View full size image]](/image/library/english/13875_16fig23_alt.gif){kind=link}
![[View full size image]](/image/library/english/13875_16fig24_alt.jpg){kind=link}
![[View full size image]](/image/library/english/13875_16fig26_alt.gif){kind=link}