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.

# view-dependent orientation

Started by davidko, Oct 12 2001 08:13 PM

1 reply to this topic

###
#2
Members - Reputation: **138**

Posted 12 October 2001 - 10:47 PM

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.

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.