Game Development Reference
This is where things get a little weird. The setParam() function sets the value of
a number of different constraint variables, two of which are used in the preceding
code. It is called a total of twelve times, since there are three axes, two directions for
each axis (positive and negative), and two different types of variable to edit ( 3x2x2
= 12 ). The two aforementioned variables are CFM ( Constraint Force Mixing ) and
ERP ( Error Reduction Parameter ).
CFM is essentially a measure of the strength of the constraint. A value of 0 means
a perfectly rigid constraint, while increasing values make the constraint more spring
like, up to a value of 1 where it has no effect at all.
ERP represents the fraction of how much joint error will be used in the next simu-
lation step. Many constraints could be working in unison to create a complex inter-
action (imagine a rope bridge, which can be simulated by a attaching a bunch of
springs connected together) and ERP is used to determine how much of the previ-
ous data will affect the calculation of future data. This is a difficult concept to explain
in such a short space, but imagine that we have multiple constraints acting on the
same object, each forcing the others into breaking their own rules. ERP is then the
priority of this constraint relative to the others, and helps determine who has higher
importance during these types of complex constraint scenarios.
And there we have it. We detected the collision point, and then built our constraint.
That wasn't so bad, was it? The last snippet of code to look at is in the Motion()
function, the code which updates the position of the constraint while we're still hold-
ing down the left mouse button.
// use another picking ray to get the target
btVector3 dir = GetPickingRay(x,y) -
// use the same distance as when we originally
picked the object