Jump to content
  • Advertisement
Sign in to follow this  
ibelchamber

vector3 dot product giving 90 angle as 0

This topic is 4993 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Sorry, another starter question: VVect and NewTarg are all 0 apart from VVect.X=-10 and NewTarg.Z=-10. I read that the dot product will give the angle between vectors. I'm expecting RotAngle to get the value PI/2, but it stays at 0. RotAngle = Vector3.Dot(VVect, NewTarg) Why is this? Thanks.

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
Dot gives the cosine of the angle, now whats the cosine of PI/2 :)

Share this post


Link to post
Share on other sites
BTW: Never ever use the dot product + acos() to find angles. It's prone to numerical error and is difficult to make robust. Use atan2() instead.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
BTW: Never ever use the dot product + acos() to find angles. It's prone to numerical error and is difficult to make robust. Use atan2() instead.


heh, ok, so leaving it as an exercise for the user to derive this are we? How is acos() prone to numerical error? I haven't ever had problems using acos to get answers.

mind telling me if this is what you are talking about as the "preferred solution".:


Vector3 v1, v2;
v1.normalize();
v2.normalize();

float cosTheta = v1.Dot( v2 );
float sinTheta = sqrt( 1 - cosTheta*cosTheta );

//QUESTION: do we have to take the absolute value of this? I feel like we do...
float theta = atan2( sinTheta, cosTheta );




-me

Share this post


Link to post
Share on other sites
Quote:
Original post by Palidine
Quote:
Original post by Sneftel
BTW: Never ever use the dot product + acos() to find angles. It's prone to numerical error and is difficult to make robust. Use atan2() instead.


heh, ok, so leaving it as an exercise for the user to derive this are we? How is acos() prone to numerical error? I haven't ever had problems using acos to get answers.

mind telling me if this is what you are talking about as the "preferred solution".:

*** Source Snippet Removed ***

-me

Not, Nicht, Nein ....

Angle=atan2(Length(CrossProduct(A,B)),DotProduct(A,B));

No need to normalize, too.

Share this post


Link to post
Share on other sites
Quote:
Original post by Palidine
Quote:
Original post by Sneftel
BTW: Never ever use the dot product + acos() to find angles. It's prone to numerical error and is difficult to make robust. Use atan2() instead.


heh, ok, so leaving it as an exercise for the user to derive this are we? How is acos() prone to numerical error? I haven't ever had problems using acos to get answers.
[/quote]
Yes, and this question WILL appear on your final, so study up. [evil]

The problem with using acos, essentially, is that it's undefined for x>1.0. Obviously, this should never happen with normalized vectors; but in practice, numerical error can crop up, either in the normalization process or the dot product or both, and give you 1.0000002 or something as a result. And unlike a lot of extreme corner cases, this one actually WILL crop up rather often.

The other reason you might not want to use it is that it isn't too good at preserving sign. If you don't care about signed angles then this doesn't matter, but the number one reason to use atan2 is that you don't have to worry about quadrants or anything; it Just Works (tm).

Dmytry's source snippet works well. And in 2D, it's even easier:

theta = atan2(v1.y,v1.x)-atan2(v2.y,v2.x)

Wrap the whole thing in an abs() if you don't want the signed angle.

[Edited by - Sneftel on March 17, 2005 12:29:47 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
Quote:
Original post by Palidine
Quote:
Original post by Sneftel
BTW: Never ever use the dot product + acos() to find angles. It's prone to numerical error and is difficult to make robust. Use atan2() instead.


heh, ok, so leaving it as an exercise for the user to derive this are we? How is acos() prone to numerical error? I haven't ever had problems using acos to get answers.

Yes, and this question WILL appear on your final, so study up. [evil]

The problem with using acos, essentially, is that it's undefined for x>1.0. Obviously, this should never happen with normalized vectors; but in practice, numerical error can crop up, either in the normalization process or the dot product or both, and give you 1.0000002 or something as a result. And unlike a lot of extreme corner cases, this one actually WILL crop up rather often.

The other reason you might not want to use it is that it isn't too good at preserving sign. If you don't care about signed angles then this doesn't matter, but the number one reason to use atan2 is that you don't have to worry about quadrants or anything; it Just Works (tm).

Dmytry's source snippet works well. And in 2D, it's even easier:

theta = atan2(v1.y,v1.x)-atan2(v2.y,v2.x)

Wrap the whole thing in an abs() if you don't want the signed angle.

BTW, somewhat more optimized version for 2D:
atan2(v1.y*v2.x-v1.x*v2.y , v1.x*v2.x+v1.y*v2.y)
Returns angle between v1 and v2, positive when this angle is like angle between [0,1] and [1,0] (normally it's clockwise, unless you are working with good-old "hardware" pixel coordinates that have 0,0 in topleft corner of screen)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!