Matrices vs. Trigonometry
which is better and faster to use for rotations? trigonometry or matrices.
Umm... yeah... that would be great... -Bill Lumberg
Quatrains make it easier to handel more complex rotations. Depending on what you do each one has its advantages.
Historycally, angles always did their job pretty well. The extra overhead added by computing sin and cos can be not so bad when compared to do a whole manual matrix transform.
If you use simd, then I guess matrices would be faster but they look harder to understand than some angles.
The other problem is that historycally, there were not so many complex transforms (say, a translated and rotated rotation) but nothing more difficult than that. For complex rotations everyone puts its word on quaternions but I know for sure you can still do wonders with angles alone.
If you need to do transforms using GL, I guess the best thing you can do is using angles since they can be easily fed to Rotate.
Depending on the kind of application, you may want to use matrices or quaternions for other application-specific reasons (for example, you need to exploit a particular quaternion propriety) but those things usually need to be transformed to be fetched to Rotatef.
As far as I know, quaternions are usually translated to matrices and matrices. I never researched too much matrices but I am pretty sure they would pass it to LoadMatrix or MulMatrix (how is it called?). Doing a single *Matrix call instead of multiple Rotatef may have slightly better performance on some systems, but nothing serious enough to spend time optimizing , unless you have tons of transforms and you are badly CPU-limited.
All this stuff to point the finger in the direction that you need to know a bit of each one and figure out what you like more and works better in your case.
For me, I suggest you to use a combination of angles and vectors (I guess this is what you''re referring as "trigonometry" right?) and drop all the other stuff.
Somebody told me quaternions are the best for skeletral animation and things like that but this is a very complex and advanced topic so I don''t care right now.
If you use simd, then I guess matrices would be faster but they look harder to understand than some angles.
The other problem is that historycally, there were not so many complex transforms (say, a translated and rotated rotation) but nothing more difficult than that. For complex rotations everyone puts its word on quaternions but I know for sure you can still do wonders with angles alone.
If you need to do transforms using GL, I guess the best thing you can do is using angles since they can be easily fed to Rotate.
Depending on the kind of application, you may want to use matrices or quaternions for other application-specific reasons (for example, you need to exploit a particular quaternion propriety) but those things usually need to be transformed to be fetched to Rotatef.
As far as I know, quaternions are usually translated to matrices and matrices. I never researched too much matrices but I am pretty sure they would pass it to LoadMatrix or MulMatrix (how is it called?). Doing a single *Matrix call instead of multiple Rotatef may have slightly better performance on some systems, but nothing serious enough to spend time optimizing , unless you have tons of transforms and you are badly CPU-limited.
All this stuff to point the finger in the direction that you need to know a bit of each one and figure out what you like more and works better in your case.
For me, I suggest you to use a combination of angles and vectors (I guess this is what you''re referring as "trigonometry" right?) and drop all the other stuff.
Somebody told me quaternions are the best for skeletral animation and things like that but this is a very complex and advanced topic so I don''t care right now.
Previously "Krohm"
learn both, and as said above, aslong as you store your rotations as angles then you can give it directly to the opengly rotate functions.
The advantage of this is that opengl''s matrix operations are so bloody fast that you can''t code your own that you can feed using load matrix functions that could beat it.
For your models, its up to how you program it. I use vectors with trig and matricies as some things you can code to be faster one way than the other.
Don''t forget that one add is 1, one subtract is 1, one multiply is 2, one divide is 20 and one sqrt is 80.
when you can add, subtract and multiple, instead of dividing and square rooting, do so
I THINK sin and cos are around 30 to 40 or something. not too noticible. Just a guestimate.
Oh, and don''t forget that a vector is just a matrix, so technically you''re using them anyway.
Oh, atan2l is faster and more accurate than acos, asin or atan.
and sincos() is the same speed as either sin() or cos(), but yields both values at the same time (pointers).
and don''t forget about fastmath.h
The advantage of this is that opengl''s matrix operations are so bloody fast that you can''t code your own that you can feed using load matrix functions that could beat it.

For your models, its up to how you program it. I use vectors with trig and matricies as some things you can code to be faster one way than the other.
Don''t forget that one add is 1, one subtract is 1, one multiply is 2, one divide is 20 and one sqrt is 80.

when you can add, subtract and multiple, instead of dividing and square rooting, do so

I THINK sin and cos are around 30 to 40 or something. not too noticible. Just a guestimate.
Oh, and don''t forget that a vector is just a matrix, so technically you''re using them anyway.
Oh, atan2l is faster and more accurate than acos, asin or atan.
and sincos() is the same speed as either sin() or cos(), but yields both values at the same time (pointers).
and don''t forget about fastmath.h
Beer - the love catalystgood ol' homepage
oh, and you can convert
sin <> cos <> tan <> sinh <> cosh <> tanh
and
asin <> acos <> atan <> asinh <> acosh <> atanh
with a simple function. involves a square root and up to two divide though, but in the case of the atanl2 it can give a more accurate asin and acos depending on your sqrt function.
And for speed if you don''t need accuracy, you can try to set your FPU to single precision instead of double precision.
sin <> cos <> tan <> sinh <> cosh <> tanh
and
asin <> acos <> atan <> asinh <> acosh <> atanh
with a simple function. involves a square root and up to two divide though, but in the case of the atanl2 it can give a more accurate asin and acos depending on your sqrt function.
And for speed if you don''t need accuracy, you can try to set your FPU to single precision instead of double precision.
Beer - the love catalystgood ol' homepage
November 08, 2003 01:34 AM
How can you compare matrices with trigonometry, because matrices requires knowledge of trig!? (with rotations at least)
I've made a fairly good 3d vector and polar cordinate classes that can convert from one to another.
I store objects in polar, and then from there can do some fairly complex rotations. Then when im ready to draw it's converted to the 3d vector (making use of 3 trig calls and 1 if statment).
Basiclly in the long run it doesn'r really matter how you do it, its just up to what your comfortable with. Of coruse there are exceptions to what i just said (in extreme cases).
I wouldn't recomend replacing the sinf, cosf, tanf (trig for floats) with your own fucntions. It's hard to do it faster than moden hardware. I do know it's possible by using a taylor series, but often the bottle neck isn't in trig calls
[edited by - skow on November 8, 2003 1:40:30 PM]
I store objects in polar, and then from there can do some fairly complex rotations. Then when im ready to draw it's converted to the 3d vector (making use of 3 trig calls and 1 if statment).
Basiclly in the long run it doesn'r really matter how you do it, its just up to what your comfortable with. Of coruse there are exceptions to what i just said (in extreme cases).
I wouldn't recomend replacing the sinf, cosf, tanf (trig for floats) with your own fucntions. It's hard to do it faster than moden hardware. I do know it's possible by using a taylor series, but often the bottle neck isn't in trig calls

[edited by - skow on November 8, 2003 1:40:30 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement