Game Development Reference
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
* Holds the length of the rod.
* 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();