Animats logo support

Products

Order
FREE Demo
Videos
Downloads
Support
Patents
Technology
About
Contact

 

Just getting started? Try the tutorial.

The Falling Bodies Manual, or the FAQ below, may answer your question.

If that doesn't solve your problem, please contact us at: support@animats.com


Frequently asked questions

Will Falling Bodies work with Sumatra (now XSI)?

No. Unfortunately, XSI does not support softimage|3D plug-ins, and XSI's own plug-in support isn't complete yet.

Common problems

    How do I stop this thing?

      Close the "Falling Bodies" window, or the "Falling Bodies Progress" window. All the frames simulated before you stop it go into Softimage, so whenever you've seen enough, go ahead and stop it.

    Why, in the demo of the guy falling down the spiral staircase, did the guy's foot stop before it hit the first step?

      "Cement clothing syndrome." The blue pants caught on the step. Falling Bodies is a rigid-body simulator, and clothing is rigid. If somebody does a clothing effect for Softimage, we'd be glad to make it work right with Falling Bodies.

    If I rerun a simulation, sometimes it comes out differently. Why?

      Falling down is chaotic. If you change the initial conditions ever so slightly, the paths slowly diverge, and may be totally different 50 or 100 frames later. Try running the same simulation twice, changing one joint angle by 0.0001, and compare the results by loading the old scene on top of the new scene. Tiny errors are introduced as the object positions go back and forth between Softimage and Dynamic Actor, because the systems don't use the same mathematical representations. (Softimage uses 4-byte floating point joint angles and scaled 4x4 matrices; Falling Bodies uses 8-byte angles and quaternions.) This is a basic property of the universe.

      If you run the same run with the same initial conditions, though, you will get the same results.

    Sometimes, when I try to lead into a Falling Bodies simulation with some keyframed motion, there's a huge jerk. Why?

      As Matt Heckert wrote in a recent issue of Game Developer, "It is a theorem that any three-number representation of rotations will suck, for some mathematically rigorous definition of suck." If you're near a multiple of 90 degrees for any of the axes of a 3D joint, wierd things can happen. The trouble is that there is more than one set of three angles that can represent the same rotation. The Softimage representation of rotation with three fcurves thus has inherent problems. This is related to issues like "what's the longitude of the North Pole", and "gimbal lock". It's possible to get Softimage itself into trouble this way, when trying to represent tumbling motion. This may get better with Softimage Sumatra or with later versions of Falling Bodies. Falling Bodies itself doesn't suffer from this problem while running; it's only a problem with getting Falling Bodies started from Softimage-created keyframes.

    How should I set the joint limits on a character?

      There are three issues with joint limits:

      1. Keeping body parts from going through each other,
      2. Preventing "gimbal lock", and
      3. Making the simulation go fast.

      The first is easiest; set the joint limits so that joints can't go further than they should for anatomical reasons. Remember that collision handling won't prevent bodies connected by the same joint (like a thigh and a calf of the same leg) from interpenetrating. So set knee joint limits (with Motion->Constraint->Rotation Limits) to prevent calves from going into thighs, for example.

      The "gimbal lock" problem is tricky. "Gimbal lock" is a problem only for joints with three degrees of freedom; in Softimage this is the first joint of a 2D chain and all joints of a 3D chain. Gimbal lock occurs when the first and third axis of a joint line up. If all the joint limits are narrow (under +-80 degrees or so) gimbal lock can't happen. If you get "Gimbal lock" errors, try narrowing the joint limits on the joints with three degrees of freedom.

      The simulation will be very slow if a completely straight limb hits an obstacle hard. In the real world, bones break when this happens. Falling Bodies struggles to find a solution that makes sense in such situations, but it takes minutes. You can prevent this by setting the joint limits so that knees and elbows can't quite make it to the straight position. One or two degrees short of straight is enough to stop this problem.

    Why is Falling Bodies usually fast, but sometimes very slow?

      That's a long story. Internally, the system does not advance one frame at a time; it takes much smaller steps, and the steps get smaller when the problem gets messy. Sometimes the steps get really tiny, as small as a microsecond, and that's when you see interminable "Frame 24: 75.3% done" messages. In the initial releases of Falling Bodies, our main concern is to make the difficult situations work right. Speed will come later.

      Some speed hints.

      • In general, big collisions in which much energy must be dissipated in a short time run slowly.
      • Free fall is very fast.
      • More joints in the character slow the simulation down linearly.
      • Multiple simultaneous collisions slow it down considerably.
      • Joints up against joint limits also slow the simulation down considerably.
      • The complexity of the scene geometry doesn't matter much up to 25,000 polygons or so. Very complex scenes may slow down the startup of Falling Bodies, but once it's running, geometric complexity usually doesn't slow things down visibly.
      • If there's significant disk activity while Falling Bodies is running, virtual memory is thrashing because you don't have enough memory. Generally, systems configured big enough to run Softimage comfortably won't have trouble with Falling Bodies. It seems that a 64MB machine will handle about 20,000 polygons.

      Incidentally, even if you see "Frame 24: 75.3% done" over and over again, it's not stuck; eventually, it will work through the tough part and speed up, or (rarely) give up.

    How does Falling Bodies compare with Hypermatter?

      Hypermatter is great if you like lots of squash and stretch. It's best for objects that behave like Jell-Otm. Falling Bodies is a jointed rigid-body simulator with some ability to handle skin deformation. It's best for realistic characters. See the Hypermatter demo movies on the Kinetix site, then compare the Dynamic Actor demos on the Animats site.

      You can use Softimage's Quick Stretch and Falling Bodies together. This provides squash and stretch, and a bit of softness in an otherwise rigid body. This can provide the look of Hypermatter. It looks best if you use only small amounts of Quick Stretch; Quick Stretch doesn't check collisions, and Falling Bodies is applied before Quick Stretch, so too much Quick Stretch can make objects go through each other.

    How does Dynamic Actor compare with Softimage's dynamics module?

      The Softimage dynamics module is good for simple things like falling bricks, but if you try it on something with joints, it doesn't do well. Falling Bodies is currently limited to doing one thing, but it does that thing well.

Last updated June 1, 2001