RE: [Algorithms] Sphere plane collision robustness woes... Ahhaaa a!
Brought to you by:
vexxed72
Menu
▾
▴
RE: [Algorithms] Sphere plane collision robustness woes... Ahhaaa a!
|
From: Gribb, G. <gg...@ra...> - 2002-02-27 01:36:23
|
I've been busy but have found this thread amuzing. There is really only one
way to learn about coding collision systems, and that is by doing it.
Collision is hard enough, but then ya throw in dynamic evolution and wow.
You spend hours trying to find the problem, then you spend hours trying to
understand the problem, then hours trying to devise a fix for the problem,
only to find you have created two new problems. And nothing, and I mean
nothing annoys the rest of the development team like continually falling
through the world and getting stuck.
Anyway, you usually have to do collision is arbitrary spaces. And it makes
sense from a performance standpoint to do collision in the space that the
mesh is naturally defined in (or a special space built for speed). You need
to take care to transform things between spaces correctly. Changing
coordinate systems might make the answer more accurate, less accurate or
even bias the answer in some way. This is all very complicated.
Fortunatly, there is an easier solution. Stop trying to find the exact time
of collision and instead give yourself a liberal cushion to work with. Look
at every < and > carefully and bias it toward safety; any == or != are
highly suspect. Look at every denominator and ponder what happens when this
is very small. And spend alot of time building infrastructure to help you
debug, because you are going to be doing alot of debugging.
-Gil
-----Original Message-----
From: Duncan Hewat
To: gda...@li...
Sent: 2/26/2002 6:47 PM
Subject: RE: [Algorithms] Sphere plane collision robustness woes... Ahhaaaa!
Thanks for the help, I think I can see where that could possibly cause
problems. However I think I've just realised I've made a graver error -
at
the moment I do my collision calculations in model space - ie: I
transform
the position and direction of the sphere into the model space of the
object
currently under consideration find my parameter t (In model space!) for
the
collision and then I use this t to update my moving objects position in
world space! Could someone confirm that this is indeed a grave error?
As
the transforms between the spaces will introduce an error that means my
t
parameter isn't directly transferable from one space to another?
Thinking back to the quake source code and others it now seems such
techniques didn't suffer from the problems that I am encountering and I
wonder if this is why (As they did everything in world space). If this
is
the case how are other people handling this? For static objects I could
store all their vertices in world space but unfortunately I'm using
instanced geometry so this wouldn't be great. Are people really
transforming all their instanced geometry to world space before doing
their
collision computations and relying on techniques such as AABB or the
such
like to reduce the expense? Or something else?
Thanks,
Duncan.
>From: Warrick Buchanan <War...@po...>
>To: 'Duncan Hewat' <dun...@ho...>,
>gda...@li...
>Subject: RE: [Algorithms] Sphere plane collision robustness woes...
>Date: Tue, 26 Feb 2002 17:31:25 -0000
>
>Your Maths seems fine to me and at a glance it looks like you've
handled
>the
>obvious problems but one thing I could maybe see you have missed is
that
>you
>should *possibly* _first_ check to see if the initial position is
within
>your epsilon range and then determine if the sphere is moving away from
the
>plane, if it is not within the epsilon range and normal.velocity >=
0.0f
>then report a miss otherwise if it is within epsilon range then only
report
>a miss if normal.velocity > 0.0f (or even normal.velocity >
>somePositiveOtherEpsilon) as something that is travelling inside the
>epsilon
>'skin' parallel with the plane would seemingly still be able to produce
a
>hard penetration - if you're doing sliding as your collision response
you
>may want to make sure your sliding direction is always pointing
slightly
>away from the plane (You may be able to get away without that but I'm
not
>sure).
>
>Well that kinda of make some sense to me (But I am suffering from a
severe
>lack of caffeine today!) and I hope that is of some help,
>
>Warrick.
>
>-----Original Message-----
>From: Duncan Hewat [mailto:dun...@ho...]
>Sent: 25 February 2002 23:50
>To: gda...@li...
>Subject: [Algorithms] Sphere plane collision robustness woes...
>
>
>In the ongoing quest for robustness in my collision code I have managed
to
>demote myself all the way down to the level of sphere plane
collision(!).
>I
>
>think I have handled all the cases I could think of that could cause
>problems but I seemingly still have problems (ie: the sphere still gets
>through the plane somehow - tends to materialise with the plane at a
fairly
>steep incline with a downward motion applied to the sphere) no matter
what
>epsilon I choose for fudging. This is all driving me mad! I've been
>working on this for weeks with seemingly no head way. If anyone has
any
>idea how to get this function to work (ie: I should never ever get
>penetration) please let me know, meanwhile I guess I'll be trawling
through
>log files to figure out where it blows up.... the pain...
>
>Thanks again,
>
>Duncan.
>
>
>bool sphereHitsPlane( float &t,
> Vec3 position,
> float radius,
> Vec3 velocity,
> Plane plane,
> float epsilon = 0.1f)
>{
> // Check to see if sphere is travelling away from the plane
> t = plane.normal*velocity;
>
>
> // Sphere is travelling away so doesn't collide
> if(t >= 0.0f) return false; // Adding epsilon fudging
here
>doesn't seem a
>win
>
>
> float distance = plane.normal*position + plane.d;
>
> // Does not collide through the front of the plane
> if(distance + radius < 0.0f) return false;
>
>
> // Check if starting point is within epsilon range
> if(distance <= epsilon + radius)
> {
> t = 0.0f;
> return true;
> }
>
>
> // Calculate the intersection
> t = (radius - distance)/t;
>
>
> // Sphere doesn't collide with plane
> if(t < 0.0f || t > 1.0f)
> {
> // Check to see if sphere still gets within epsilon
of
>the plane
> if((position + velocity)*plane.normal + plane.d <=
epsilon +
>radius)
> {
> t = (radius + epsilon -
>distance)/(plane.normal*velocity);
> return true;
> }
>
> return false;
> }
>
>
> // Calculate the intersection with an epsilon offset
>
> t = (radius + epsilon - distance)/(plane.normal*velocity);
>
>
> return true;
>}
>
>_________________________________________________________________
>Chat with friends online, try MSN Messenger: http://messenger.msn.com
>
>
>_______________________________________________
>GDAlgorithms-list mailing list
>GDA...@li...
>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>Archives:
>http://sourceforge.net/mailarchive/forum.php?forum_id=6188
>
>_______________________________________________
>GDAlgorithms-list mailing list
>GDA...@li...
>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>Archives:
>http://sourceforge.net/mailarchive/forum.php?forum_id=6188
_________________________________________________________________
Get your FREE download of MSN Explorer at
http://explorer.msn.com/intl.asp.
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=6188
|