Still trying to understand Vector Projection

Started by
29 comments, last by smitty1276 15 years, 6 months ago
Quote:Original post by zyrolasting
It seems much that was discussed had more relation to line/segments rather than rays, even though rays were used. (Given we discussed "start" and "end" points.)
Yes, if you are talking about start and end points, then you are talking about line segments, but line segments are just lines with an extra piece of information. The original reply to your original question was describing plane/segment intersection test, which is a ray intersection test with the additional constraint that you must check t to see if it the ray/plane intersection occurs within the length of the line segment.

What I've been wanting to explain is that the existence of a "line segment" is superfluous to the intersection test. You do a ray/plane intersection... you find that it intersects at some value for t... you THEN check to see if t lies within the distance you are interested in (the "line segment").

Quote:So I guess this just tells me that from the start point, the ray goes to infinity but there is still that "end" point and the scalar is going between the "start" and it?
No... a line or ray has no end point. The scalar can be any real number from negative infinity to positive infinity. (A ray is just a special case of a line, where you are only interested in points given by a positive scalar.)

Quote:Just curious here, are each of you guys approaching this in a slightly different way?
No, we're all saying the same thing... I'm just being a stickler on the semantics because I think you'll benefit from understanding when you are talking about a point vs vector, or a line vs segment vs ray. [grin]
Advertisement
Quote:Original post by zyrolasting

Whoa, what? I know there can be a lot of good I can get from this, but what exactly is going on when you plug these in? Specifically, I notice you are making more use of the Y component of each vector. Also, what do the numbers represent above and below each evaluated formula? (I.E. [1][7][1] and the [0]s below each)



I had a bad feeling the formatting would mess this up...I was trying to represent vectors like..


p = (px, py, pz) in collum form...


[px]
[py]
[pz]

EDIT: Used forced spaces to try to make the layout a bit clearer...
I do think I speak for everyone here that this may have been discussed enough...
Unless, Of course, something was left out.

I'll say one more time: Thanks so much for helping me through this. I haven't been to a forum this supportive before. I'm used to hearing stuff like: "Your FOR loop is crap" and that's it. :p

How about we try wrapping this up by having me try to apply this in code?

Here's my next attempt.

//Assuming a pointer to player struct with position is available.D3DXVECTOR3 playerVec(player->x,player->y,player->z);D3DXVECTOR3 FallDirection(0.0f,-1.0f,0.0f);D3DXVECTOR3 PlaneNormal(0.0f,1.0f,0.0f);D3DXVECTOR3 WhereItHappened;float t, d = 5.0f, scl = 2.0f;D3DXPLANE floor(PlaneNormal.x,PlaneNormal.y,PlaneNormal.z,d); //Normal pointing up, distance 5 units from origin./*I'll be checking 2 units down on unit vector FallDirection. (via scl variableabove) Even though I am checking 2 units down, those 2 units can be considereda "cap" since I am, by basic ray definition, checking in infinite distance inone direction.*/t = (d - (D3DXVec3Dot(playerVec,PlaneNormal))/(D3DXVec3Dot(playerVec,planeNormal));/*Find the parameter to check with scalar.*/if (t < 0.0 || t > scl){ /*Nope. Nothing happened. Wrap up script and...*/ return false;}/*Got something. Where exactly did it happen?*/pIntersect = playerVec + FallDirection * t; /*Find point of intersection.Judging from Olii's example in code similar to this, it'd be better tohave a reference to the vector containing the result than to do it locally.*/return true;


Am I still wrong or off anywhere? I think I'm getting it.
For the record, I remember your word of warning Olii.

Now, I just had an idea. I mentioned a player struct. Wouldn't be useful if I included another x, y and z coordinate group with stores the last position it was in? I figure it the player hits a wall, it's position should revert to the very last one. A engine I sometimes use, Game Maker, had a similar practice.
Quote:Original post by zyrolasting
t = (d - (D3DXVec3Dot(playerVec,PlaneNormal))/(D3DXVec3Dot(playerVec,planeNormal));

Am I still wrong or off anywhere? I think I'm getting it.
I haven't checked the math, but assuming Olii's intersection test is correct, you might have your operations grouped incorrectly (depending on where you meant to put the missing close parenthesis) and one of your vectors is wrong.

Olii's:
t = (d - (a . n)) / ((b - a) . n)
Yours (if I remove the unmatched parenthesis at front):
t = d - (a . n) / (a . n)

You need to use parenthesis to group the first part:
t = (d-(a.n)) / (a.n).

And the (a.n) in the divisor is wrong... to match the (b-a) in the example's divisor you need the downward fallDirection vector, not the position (which was a in Olii's example).

Quote:I figure it the player hits a wall, it's position should revert to the very last one.
Not necessarily... your object could cover quite a lot of distance between undates. What if a bullet is travelling at supersonic speeds, and 1/30 sec later has impacted a wall? You want it on the wall, not in the gun.

In this situation, I would pull the object/player/whatever back along the negative velocity vector until its bounding volume is no longer intersecting the thing it collided with. Of course, you might want to have things bounce or reflect, which is another calculation.
I've found this site helpful with figuring out various collision tests. Specifically applicable is the page titled "The intersection of a line with a plane".
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
Quote:I've found this site helpful with figuring out various collision tests. Specifically applicable is the page titled "The intersection of a line with a plane"


I appreciate the reference, Extra. However, that is different enough to have me confused again. At least, the last part. It might just be since it's in a slightly different context. I have a headache enough as is. ;P
I'll keep the link bookmarked. Thanks!

Quote:

Quote:
Original post by zyrolasting
t = (d - (D3DXVec3Dot(playerVec,PlaneNormal))/(D3DXVec3Dot(playerVec,planeNormal));

Am I still wrong or off anywhere? I think I'm getting it.

I haven't checked the math, but assuming Olii's intersection test is correct, you might have your operations grouped incorrectly (depending on where you meant to put the missing close parenthesis) and one of your vectors is wrong.

Olii's:
t = (d - (a . n)) / ((b - a) . n)
Yours (if I remove the unmatched parenthesis at front):
t = d - (a . n) / (a . n)

You need to use parenthesis to group the first part:
t = (d-(a.n)) / (a.n).


Noted. I assume this is correct?
By the way, I did not see reference to (b - a) in the 2nd operand. Looking at Oliii's code, it looked like only the direction was taken into account.

Quote:tParam = (planeD - (playerVec.dotProduct(planeNormal)) / (fallDirection.dotProduct(planeNormal)); // intersection parameter.


There is so much to read on the first page, so I could just be overlooking another formula. I know I'm going to have to refer to this topic every now and then.

t = (d - D3DXVec3Dot(playerVec,PlaneNormal)) / D3DXVec3Dot(FallDirection,planeNormal);

The missing set of parenthesis and failure to reference the FallDirection vector was a complete slip up on my part; Normally I would have caught that. I understand where I went wrong there, but did not pay attention to what I was typing.

Is there anything else wrong, or that I should know?
Quote:
Quote:
Olii's:
t = (d - (a . n)) / ((b - a) . n)
Yours (if I remove the unmatched parenthesis at front):
t = d - (a . n) / (a . n)

You need to use parenthesis to group the first part:
t = (d-(a.n)) / (a.n).


Noted. I assume this is correct?
By the way, I did not see reference to (b - a) in the 2nd operand. Looking at Oliii's code, it looked like only the direction was taken into account.


That's a typo. should be read...

Quote:
You need to use parenthesis to group the first part:
t = (d-(a.n)) / ((b - a).n)


generally, a direction, is a difference of two position is space. (b - a) is a direction vector.

Everything is better with Metal.

b - a is a direction vector... Even so, it's just

playerVec - FallDirection in my case?
Also, it's best normalized, right?
fallDirection itself is a direction vector :)

You don't have to normalise fallDirection for that particular equation.

Everything is better with Metal.

Coulda just told me what I had was right. :p
I was still under the "start/end" logic, and was still associating it with a and b.

If this is cleared up here, then I thank you guys again.

This topic is closed to new replies.

Advertisement