Game Development Reference
In-Depth Information
{
worstContact = contact;
worstPenetration = contact->penetration;
}
}
if (worstContact) worstContact->applyPositionChange();
else break;
}
(which is the code from chapter 14), we start with a value equal to the tolerance we
are allowing:
Contact* lastContact = contacts + numContacts;
for (unsigned i = 0; i < positionIterations; i++)
{
Contact* worstContact = NULL;
real worstPenetration = penetrationEpsilon;
for(Contact* contact = contacts; contact < lastContact; contact++)
{
if (contact->penetration > worstPenetration)
{
worstContact = contact;
worstPenetration = contact->penetration;
}
}
if (worstContact) worstContact->applyPositionChange();
else break;
}
The situation is similar for the velocity. Now no contact will be selected that has
a penetration below this epsilon value. This value should be small enough so that the
contact is not easily noticed by the player. The first time the contact is resolved, the
resolution should bring the contact's penetration below this limit, so it will not be
considered again. Tuning is, again, a necessity. For the demos on the CD I have used
values around 0.01 for each. If your objects are larger or faster, then higher values
should be used. If they are smaller or slower, then use lower values.
Both the velocityEpsilon and penetrationEpsilon values are properties of the
collision resolver class. In the code on the CD I have included methods to set and
get their current value.
When I added this simple change to the engine, I gained a fivefold speed-up im-
mediately. For complex stacks of objects the improvement was even more significant.
Between the sleep system and this pair of tolerances, we have a physics simulation
that is fast enough for real production work. Further optimization can be achieved in
Search Nedrilad ::




Custom Search