Is this tutorial wrong, or is it just me?
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?
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?
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
// 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
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...]
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...]
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 dotproduct 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!]
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!
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 dotproduct 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 timeslice.
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.
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!
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?
Normals point "out". Unless you have two sided polygons  which means a little more work when handling the collision.
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 righthanded rule, but don't quote me on that.
There's nothing magical about that direction though, except that presumably you are using onesided 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 onesided.) Conversely, if you are already successfully drawing your polygons onesided 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.
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.
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.
Possibly Related Threads...
Thread:  Author  Replies:  Views:  Last Post  
What's wrong with my glutSolidTeapot?  TomorrowPlusX  4  5,354 
Aug 7, 2008 10:27 AM Last Post: arekkusu 

What could be wrong here?  Jones  5  2,692 
Jul 1, 2006 08:52 PM Last Post: Jones 

Can someone help a 'noob'? What's wrong with this?  RagingAvatar  7  4,038 
Jun 4, 2006 11:54 PM Last Post: Fenris 

Texture Color is wrong  DesertPenguin  7  3,804 
Feb 14, 2006 09:04 PM Last Post: DesertPenguin 

Whats wrong with my collision code?  Jake  6  2,859 
Sep 11, 2003 12:44 PM Last Post: MacFiend 