Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

nick5454

my sin code is not getting the correct angle

This topic is 5216 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

I use this code to get the new angle and its 10 degrees off D3DXVec3Subtract(&vDiff, &vPos, &vDest ); D3DXVec3Normalize(&vTempDiff, &vDiff); fYaw = vTempDiff.x; .785 is the number I need in radians but I always get .82 Its direct3d please help.

Share this post


Link to post
Share on other sites
Advertisement
How do you know the number you need? Could it be that 0.82 is in fact the correct yaw angle?

Share this post


Link to post
Share on other sites
If you want radians, then you should do this:
    fYaw = acos( vTempDiff.x );  
since
    cos( fYaw ) = vTempDiff.x  
by definition, right?


John Bolton
Page 44 Studios
Current project: NHL Faceoff 2005 PS2

Share this post


Link to post
Share on other sites
Actually, now that I think about, it's going to be more complicated than just grabbing the x component. The problem is that when you transform pitch, yaw, and roll into a vector orientation, you would technically have to exactly reverse that transformation step by step to extract the pitch, yaw, and roll again.

What this means, for example, is if you have an orientation vector with an extremely high pitch (85° let's say), then the x component is going to be really small since this vector is almost parallel to the Y-axis, as opposed to a lower pitch (45° for instance) which will have a larger x component. However, pitch isn't supposed to affect yaw. This tells us that the process of extracting PYR information from a vector is going to be a bit more involved than just grabbing coordinates.

Luckily, it isn't too difficult. To extract the yaw, you must project the vector to the XZ plane, and find the angle there. One version of the code would look like: fYaw = atan( vec.x / vec.z );

Extracting pitch and roll require some more complicated projections. As a matter of fact, you won't be able to extract roll at all without an additional vector perpendicular to the orientation vector (sometimes refereed to as an UP or RIGHT vector, depending on how it's oriented).

If you store PYR information in a transformation matrix, it might be easier to extract the information later than rebuilding it from a vector orientation. I have no idea how exactly you would do this, heh, but assuming it's possible it would work for everything but degenerate cases (i.e pitch being 90°, which would lead to a gimbal lock scenario).

[edited by - Zipster on June 6, 2004 10:12:05 PM]

Share this post


Link to post
Share on other sites
well actually the yaw is only 10 degrees off so its just a hunt and peck. I chose that angle because I set a location that I know x would be exactly 45 degrees. which means the radian is .005 off.

I''m thinking that this could be a precision issue with the float. Because its flying on a X plane basically during testing I dont use the roll factor, maybe I should but I dont see how it affects the outcome. And since were running on the X plane Y is 0 also so thats not used.

Baseically I''m saying I haqve the possibilities limited to the x plane. And since the z factor just means I flip the x arc 180 degrees, thats not the issue.

I dont use acos because sometimes the it return numbers greater than .99999 which bugs out.

But if you have any ideas.

Share this post


Link to post
Share on other sites
Your numbers are 0.035 off, which isn't a precision error. 0.0000001 is a precision error.

Like I was saying, pitch and roll could have an adverse effect on your yaw calculations.

Here's what we'll do. Tell we what vPos and vDest vectors you're using as a test, and I'll tell you whats wrong with your code

[edited by - Zipster on June 6, 2004 11:29:06 PM]

Share this post


Link to post
Share on other sites
Yeah I wasnt listening maybe because I was medication for a virus I caught.

vPos is the current Position

D3DXVECTOR3(0,0,0)

vDest is the position I want to travel to

D3DXVECTOR3(1000,0,1000)

Thats basically the code. If you need an actual snapshot I can send one tonight. I''m going to attack the code tonight to see if I can find out why.

Thanks a lot,
Nick

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
ok so I tested all different calcs. this one came the closest

double sinYaw = sin((double)fYaw); // fYaw is the x counterpart in the subtraction of the 2 vectors after normalization

This resulted in 45 degrees which wopuld be 0.82496662150210143

which means when x is 1024 then z is 946. If I could just get 2 more degrees over.

how frustrating. I tried multiplying, adding, dividing, and subtract and no avail.

Nick

Share this post


Link to post
Share on other sites
You wouldn''t take the sine of the yaw, because the x coordinate of the normalized vector already is the sine value. Take the arcsine.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
then I get 76 degrees. it doesnt make sense. I wish I knew of a link to help with my problem. I cant weven fire a missle

Share this post


Link to post
Share on other sites

  • 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!