D
Dave
Hi folks,
I am trying to develop a routine that will handle sphere-sphere and
sphere-triangle collisions and interactions. My aim is to develop a
quake style collision engine where a player can interact with a rich
3D environment. Seem to be 90% of the way there! My problems are
related to calculations where the result tends to zero (or another
defined limit.)
Have loads of cases where this kind of interaction occurs but this one
is as tricky (?) as any...
When a moving sphere approaches a triangulated plane I am using a
sphere-plane collision routine to see if a collision will occur. All
goes well until I start to have near parallel interactions (e.g. when
the sphere has sufficient energy to collide with, and then slide along
the plane.) During the next pass of the collision routine the velocity
of the sphere is perpendicular (in a single plane) to the face normal
of the previous colliding plane. A dot product between the velocity of
the sphere and the normal of the colliding plane should be zero. It's
close to zero but how close is close enough to warrant no further
collision? A "need to collide" case occurs where the sphere is just
above the plane with a velocity almost parallel to the plane BUT just
on a collision course. The above dot product will be very close to
zero again, but this time there should be a collision with this plane!
Since I need to account for glancing off faces, approaching faces at
right angles, interacting with steps, falling off edges etc the number
of vector operations to determine the final position and velocity of
the sphere need to be as accurate as possible.
I guess my question (sorry for the waffle) is how to minimise rounding
errors in floating point operations?
So far I've tried to account for the errors (or eliminate them) by:
- Using double precision decelerations and calculations
- Using the epsilon error on the variables to account for known
internal storage errors
Unable to eliminate or account for the errors I then set about trying
to use flags to ignore colliding objects from future collision during
the current recursive collision routine call. Helped in some cases so
started to try to account for all near critical iterations using
flags.
Getting close to a general solution now but my once clear simple
routine has turned into a logical nightmare!
When working with numbers where accuracy is paramount should I be
using a different approach? I've considered the following:
- Using a quantised system where all values have to fall along a
virtual 3D grid
- Using sin and cos tables to support the above goal of quantisation
- Using integer mathematics
- Use a high precision custom storage class for calculations (speed is
off the essence so might not be an option?)
Perhaps I am worrying too much! My current "effort" seems to handle
interactions in a similar, if much more shaky, way to Unreal
Tournament 2004. Kind of clunky at times, stops occasionally and seems
to have problems jumping on steps!
I'm working on Windows 2000 using Visual Studio 6 and .net enterprise
architect 2003 (c++). It's a DirectX application if that makes any
difference?
Any advice would be really appreciated.
Many thanks,
Dave
I am trying to develop a routine that will handle sphere-sphere and
sphere-triangle collisions and interactions. My aim is to develop a
quake style collision engine where a player can interact with a rich
3D environment. Seem to be 90% of the way there! My problems are
related to calculations where the result tends to zero (or another
defined limit.)
Have loads of cases where this kind of interaction occurs but this one
is as tricky (?) as any...
When a moving sphere approaches a triangulated plane I am using a
sphere-plane collision routine to see if a collision will occur. All
goes well until I start to have near parallel interactions (e.g. when
the sphere has sufficient energy to collide with, and then slide along
the plane.) During the next pass of the collision routine the velocity
of the sphere is perpendicular (in a single plane) to the face normal
of the previous colliding plane. A dot product between the velocity of
the sphere and the normal of the colliding plane should be zero. It's
close to zero but how close is close enough to warrant no further
collision? A "need to collide" case occurs where the sphere is just
above the plane with a velocity almost parallel to the plane BUT just
on a collision course. The above dot product will be very close to
zero again, but this time there should be a collision with this plane!
Since I need to account for glancing off faces, approaching faces at
right angles, interacting with steps, falling off edges etc the number
of vector operations to determine the final position and velocity of
the sphere need to be as accurate as possible.
I guess my question (sorry for the waffle) is how to minimise rounding
errors in floating point operations?
So far I've tried to account for the errors (or eliminate them) by:
- Using double precision decelerations and calculations
- Using the epsilon error on the variables to account for known
internal storage errors
Unable to eliminate or account for the errors I then set about trying
to use flags to ignore colliding objects from future collision during
the current recursive collision routine call. Helped in some cases so
started to try to account for all near critical iterations using
flags.
Getting close to a general solution now but my once clear simple
routine has turned into a logical nightmare!
When working with numbers where accuracy is paramount should I be
using a different approach? I've considered the following:
- Using a quantised system where all values have to fall along a
virtual 3D grid
- Using sin and cos tables to support the above goal of quantisation
- Using integer mathematics
- Use a high precision custom storage class for calculations (speed is
off the essence so might not be an option?)
Perhaps I am worrying too much! My current "effort" seems to handle
interactions in a similar, if much more shaky, way to Unreal
Tournament 2004. Kind of clunky at times, stops occasionally and seems
to have problems jumping on steps!
I'm working on Windows 2000 using Visual Studio 6 and .net enterprise
architect 2003 (c++). It's a DirectX application if that makes any
difference?
Any advice would be really appreciated.
Many thanks,
Dave