Skip to content


Focus of this release is Solver Iterations, and some UI additions too!

Message Board

Ever opened the Script Editor to find Ragdoll screaming for help? I've added a new Message Board to help Ragdoll stand out from the overall messy or hidden messages from rigs and Maya and all else.


Your goal then is to never have any messages appear in the Message Board.

A silent Message Board means a happy simulation. :)

Solver Iterations

Anything called strength in Ragdoll is a multipler for stiffness and damping. And currently there's a ceiling to how high stiffness and damping values can go, after which point they just stop having an effect.

The values are limited by how many "iterations" you let the solver perform. Per default, they are set to 8 and can be found at rdRigid.positionIterations. This release sheds some more light on this somewhat obscure attribute by exposing it directly on the solver, right next to Substeps.


This value multiplies each rdRigid.positionIterations attribute, meaning a value of 2 yields a total iteration count for every rigid in the solver of 16 (i.e. 2 * 8).

Which means you can now do this!


You can further customise iteration counts per rigid, under the Advanced tab.


There's no limit to how many iterations you can allow; more iterations means greater accuracy. However, I have found that values beyond 128 tend to get funky.

Iteration Count Strength Range Description
8 (default) 0-5 Default, sensible for most uses
16 0-10 High
32 0-500 Really, really high
64 0-1000 Ultra Nightmare

For completeness, here's how Iterations differ from Substeps.

  • Substep Divide each frame into smaller time steps
  • Iterations Number of times a constraint is "resolved"

They both provide accuracy in slightly different ways. With a greater amount of substeps, the solver is effectively working in slow-motion. Everything is easier in slow-motion. Resolving constraints is independent of time and a little more technical to describe, so you can instead kind of think of it a little bit like rubbing dirt of a silver platter. The first rub, you'll get most of it off. But the more you rub, the shinier it gets. There's no limit to how much you can rub, but eventually rubbing will stop having a visible effect.

Help Line

Hovering over any menu item now reveals a short description of what it does in the native Maya Help Line (typically at the bottom of the Maya window).


This is the same information as can be found in the Menu Reference.

Delete From Selection

The Delete All Physics menu-item has gotten an option box, now it can be used to limit deletion to currently selected nodes!


Locked Channels

The previous release would bark at you whenever trying to turn any transform dynamic if it had any of its translate or rotate channels locked. This was a problem when you didn't necessarily care for some of them. For example, with a dynamic control, you really only cared for the rotate channels but would be prevented from simulating them if the sibling translate channels were locked. No longer!

That said, the simulation does still produce both translate and rotate values. There's no way around it. And locked channels cannot be connected or edited. Even though you might want to. If the transform is referenced, then there's nothing you can do.


Warnings will be emitted (and made visible in the new Message Board!) if this happens, so it's still true that if your Message Board is silent, all is well.

Multiple cmdx

This should only really affect users of WeightShift, which also uses cmdx. The previous release was adamant on being the one and only physics solver for Maya. But it has now become more lenient and accepting of other lifestyle choices. :D

Animated Initial State

Heads up! This got removed. Stay tuned for a re-appearance in a later release

In the previous release, you could animate your dynamic controls, but you couldn't change the initial pose unless you explicitly called Set Initial Pose from the Ragdoll | Rigging menu. With this release, you can!



This currently only works reliably with strict FK control hierarchies.

The animation is translated into an initial state, but in doing so we are effectively recreating the parent/child relationship between controls. And sometimes - perhaps a lot of times - this isn't a direct FK hierarchy.


Here you can see how the physics and animation controls disagree on what the pose should be. The animation controls aren't in a hierarchy, they are constrained in a complex manner. It isn't accurately reproduced in the initial state.

So if you notice your the simulated initial state to differ from the first pose of your animation, it's the best you can get at the moment.

Worldspace Dynamic Control

Heads up! This got removed. Stay tuned for a re-appearance in a later release

Guide forces in dynamic controls are all local. Which means it'll maintain a pose, even if that pose is upside down or sideways.


And since many versions ago, you've been able to append these "Guide" controls, that are in worldspace (per default). These look at the worldspace position and rotation of the control, and use that to line up the simulation. Much like IK!


Now these are built-in to each Dynamic Control (toggle in the option dialog).


These can help keep a character closer to an animated pose. But they are "cheats". Forces that appear out of nowhere, as opposed to the local forces which behave like muscles. Muscles can tense and relax whilst still appearing natural, but these are not natural. You can however use them to fake natural.

One more thing; world spaces have strength in either translation or rotation, or both. A worldspace rotation could for example keep a head facing a certain direction, not unlike how IK works. Except physical!



This feature uses the same "virtual hierarchy" as the animated initial state and suffers from the same limitations.