• Advertisement

Archived

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

view-dependent orientation

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

Okay, this problem is much easier to visualize than to explain, so please bear with me... Say you have a triangle with an inherit orientation vector (picture this as an arrow plastered on the triangle pointing "north"). If you render this triangle to the screen, the vector will, of course, follow however you rotate the triangle. In screen space, you will see this vector''s orientation moving around in circles on the screen''s "z"-axis (I''m sure you know what I mean when I say the screen''s z-axis). Now my problem is, I want to determine the screen-space unit vector that describes orientation of the triangle, once that triangle is projected to the screen. One way you could probably do it is by projecting the orientation vector onto the viewplane, and then renormalizing. But I need a faster way to do this, especially without having to project anything...preferably a method where once you know the rotation being applied to the triangle, and the original triangle''s orientation, you can calculate an angle (relative to the screen-space orientation vector before the rotation). Does this make sense? It doesn''t have to be completely accurate, either, although that would be nice.

Share this post


Link to post
Share on other sites
Advertisement
Hmmm, I can''t think of a faster method than what you described, transforming and normalizing.

If you''re willing to sacrifice accuracy for speed in your normalization, you should check out this thread at FlipCode. The first post includes an inverse square root approximation function for floats.

You mentioned some stuff about angles which I didn''t really understand... in any case, if you wanted to somehow go from an angle to your final 2D vector, that would involve sin/cos, which is just about as expensive as the sqrt in normalizing, so I don''t see that being any faster.

Share this post


Link to post
Share on other sites

  • Advertisement