Game Development Reference

In-Depth Information

Second, if we apply just one of the two contacts (to separate or to close) at each

frame, we will end up with a vibrating rod. On successive frames the rod is likely to

be too short, and then too long, and each contact will drag it backward and forward.

To avoid this we generate both contacts at every frame. If either of the contacts is

not needed (i.e., the separating velocity is greater than zero, or there is no interpen-

etration), then it will be ignored. Having the extra contact there helps to keep the

contact resolver algorithm from overcompensating, so the rod will be more stable.

The downside of this approach is that for complex assemblies of rods the number of

iterations needed to reach a really stable solution can rise dramatically. If you have a

low iteration limit, the vibration can return.

We can implement our contact generator in this way:

Excerpt from include/cyclone/plinks.h

/**

* Rods link a pair of particles, generating a contact if they

* stray too far apart or too close.

*/

class ParticleRod : public ParticleLink

{

public:

/**

* Holds the length of the rod.

*/

real length;

public:

/**

* Returns the current length of the cable.

*/

real currentLength() const;

/**

* Fills the given contact structure with the contact needed

* to keep the rod from extending or compressing.

*/

virtual unsigned fillContact(ParticleContact *contact,

unsigned limit) const;

};

Excerpt from src/plinks.cpp

unsigned ParticleRod::fillContact(ParticleContact *contact,

unsigned limit) const

{

// Find the length of the rod.

real currentLen = currentLength();