Is this tutorial wrong, or is it just me?

Member
Posts: 509
Joined: 2002.05
Post: #1
On this collision detection page it says that...

intersection point = Ray.Origin + Ray.nVector * t

where t is the distance from the origin to the plane. Just now I realized that the problem in my collision code is it isn't finding the point that the sphere collides with the polygon correctly. Now I think this code must be wrong for the following reason, imagine a sphere traveling parallel to a plane 2 feet off the ground, the ball will NEVER hit the plane, but the equation above is telling me that the intersection point is where the ball is plus its vector*2.

Basically what i'm asking, is how do I find the exact point of where a ray hits a plane if I know the vector and starting position of the vertex, and the normal of the plane?
Quote this message in a reply
Member
Posts: 304
Joined: 2002.04
Post: #2
well it does have this line:

// parallel to the plane (alpha=90)
if (cosAlpha==0) return -1.0f;

in case you are moving *exactly* parallel to the plane. However it isnt a great tutorial because it doesnt compute the true collision point. It looks at the distance between the sphere and plane each frame. So if your object moves fast enough it will miss a collision. And the more acute your angle of collision - the further off the calculations will be. This code probably works well with larger spheres that dont move *too* fast. You would need a different algo for bullets for example.

you might want to check out <http://www.gamedev.net/reference/article...le1026.asp>

hth
Quote this message in a reply
w_reade
Unregistered
 
Post: #3
Well, you need to know a point on the plane too, surely...

This seems to have turned into a slightly excessive maths dump... it all turns into a nice formula at the end, though. Please do read it... if you haven't done anything like this before it may seem a bit much to take in, but understanding why your formula works is a lot more important than just knowing what the formula is.

Anyway, let's say we have:

B, a vector representing the starting position of a bullet;
Bv, a vector representing the velocity of that bullet;
W, a vector representing a point anywhere on a really big wall; and
Wn, the normal vector to that wall.

All points (x, y, z) through which the bullet passes have the form

(x, y, z) = B + k * Bv

where k is some scalar, and all points on the wall satisfy the equation

Wnï(x, y, z) = WïWn

:ohmy:, you might say, but if we hack these around a bit they become a bit more palatable. Witness:

WïWn is a constant (provided the wall doesn't change). Calculate it, call it C or something, and forget about it for now. Thus:

Wnï(x, y, z) = C

Now, from the bullet/line, we can see that:

x = B.x + k * Bv.x
y = B.y + k * Bv.y
z = B.z + k * Bv.z

and from the equation of the wall/plane:

Wn.x * x + Wn.y * y + Wn.z * z = C

Now it's a simple matter of substitution - put the equations for x, y and z from the line into the equation of the plane:

Wn.x * (B.x + k * Bv.x) +
Wn.y * (B.y + k * Bv.y) +
Wn.z * (B.z + k * Bv.z) = C

Collect everything that's a coefficient of k together and move everything else to the other side:

k * ( (Wn.x * Bv.x) + (Wn.y * Bv.y) + (Wn.z * Bv.z) )

=

C - ( (Wn.x * B.x) + (Wn.y * B.y) + (Wn.z * B.z) )

Which simplifies down rather nicely to:

k * WnïBv = C - WnïB

So, replacing C with what it means again:

k = (WïWn - WnïB) / WnïBv

...whew.

You'll notice that if the wall normal is perpendicular to the bullet direction, WnïBv = 0, so k is meaningless (the bullet never hits the wall); otherwise, the point of intersection of the line and the plane is B + k * Bv.

Damn, I'm tired. Deriving equations that I could quite easily look up wasn't really what I planned to do this eveni... morning. Blast. Still, it was fun, in an odd sort of way. Everybody, please point out any flaws you notice... this stuff can be a bit hard to proofread.

hope this helps, post again if it needs clarification
william

[edit: goddamn! all that typing, and I'm beaten to an answer by one measly minute...]
Quote this message in a reply
Moderator
Posts: 439
Joined: 2002.09
Post: #4
Not sure where you derived that formula you have. From their diagram I get the intersection is the ray R scaled by the length l. The length l is computed by

l = d / (R.N)

where R is the ray vector, N is the plane normal, and d is the distance between R's origin and the plane.

Note that they are dividing by (R.N). If that dot-product is zero (which it would be in the parallel case you mentioned) then you are dividing by zero. Hence the intersection would never occur. This is handled with an if statement in the sample code.

Once you have length l you can scale R by it to get the intersection point.

[edit: darn, all that typing and I was beaten by two other people!]

Quote:However it isnt a great tutorial because it doesnt compute the true collision point.
Maybe so. I didn't look at their code too closely. But the formula above can always be used to calculate the exact intersection point (with some modification to handle spheres.) Then you just have to decide whether you have reached that spot or not in this time-slice.

Another way to do this is to compute the end position of the sphere if there was no plane, do a distance test to see if it crossed the plane, then using ratios you can compute how far back the intersection point was.

To really confuse jake we need at least two more people to post their own explanations! Three isn't enough!

Measure twice, cut once, curse three or four times.
Quote this message in a reply
Member
Posts: 509
Joined: 2002.05
Post: #5
Thanks for the posts everyone, I read over it and I think I understand most of it, I will add the code today or tomorrow and post the results (I hope).

Quote:Originally posted by MattDiamond
To really confuse jake we need at least two more people to post their own explanations! Three isn't enough!


Blink
Quote this message in a reply
Member
Posts: 509
Joined: 2002.05
Post: #6
I was wondering, each plane can have 2 normals, their normal one, and then one facing the opposite direction. Does it matter what one I use? Should I just use the default one my cross product returns?
Quote this message in a reply
Member
Posts: 304
Joined: 2002.04
Post: #7
Normals point "out". Unless you have two sided polygons - which means a little more work when handling the collision.
Quote this message in a reply
Moderator
Posts: 439
Joined: 2002.09
Post: #8
Quote:Originally posted by Jake
I was wondering, each plane can have 2 normals, their normal one, and then one facing the opposite direction. Does it matter what one I use? Should I just use the default one my cross product returns?


The cross product returns a different answer depending on what order you supply the arguments. I believe it's a right-handed rule, but don't quote me on that.

There's nothing magical about that direction though, except that presumably you are using one-sided polygons as codemattic said, and are therefore are already culling polygons that facing the other way.

The only real trap here is if you don't use consistant orientation. If you don't represent your planes/polygons with consistently oriented normals, then you will have trouble with collision detection AND with drawing the polygons (if one-sided.) Conversely, if you are already successfully drawing your polygons one-sided and they look good, then I think you won't have much trouble using their normals for the kind of collision detection we have been talking about.

Measure twice, cut once, curse three or four times.
Quote this message in a reply
Member
Posts: 509
Joined: 2002.05
Post: #9
Whihoo!!! Thanks to everyones help I now have collision detection working, along with collision response. Right now, everything works REALLY good except when the ball rolls, it kind of jitters around, I haven't had time to fix it yet because of soccer games.

Thanks!!!

Oh, for my normals, I just checked the Y value, and if it was negative I reversed the vector, so they all face towards the sky.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  What's wrong with my glutSolidTeapot? TomorrowPlusX 4 5,835 Aug 7, 2008 10:27 AM
Last Post: arekkusu
  Lighting a sphere with OpenGL lights (normals wrong?) cecilkorik 3 8,313 Dec 27, 2007 02:40 PM
Last Post: _ibd_
  What could be wrong here? Jones 5 2,935 Jul 1, 2006 08:52 PM
Last Post: Jones
  Can someone help a 'noob'? What's wrong with this? RagingAvatar 7 4,330 Jun 4, 2006 11:54 PM
Last Post: Fenris
  Texture Color is wrong DesertPenguin 7 4,171 Feb 14, 2006 09:04 PM
Last Post: DesertPenguin