Just getting started? Try the tutorial.
The Falling Bodies
Manual, or the FAQ below, may answer your
If that doesn't solve your problem, please contact us at: email@example.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.
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
If I rerun a simulation, sometimes it comes out differently.
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?
- Keeping body parts from going through each other,
- Preventing "gimbal lock", and
- 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
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
- 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
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
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.