external cockpit views 3d math !
ok guys, you''re sitting in the cockpit of a nice airplane travelling along the Z axys. If you pull the joystick to yourself the camera accomplish a rotation on the X axys increasing your pitch, and that''s just fine ...
Then you move your head at your left to see some landscape (camera glRotatef on Y axis) but now ... pulling the joystick to yourself still rotate the camera on the X axys, while it should now rotate along the Z axys if you want to increase your pitch ...
I really can''t imagine what kind of formulas do I need to perform this, nor if I explained myself ... but please answer me, sigh ...
sign check out ( maybe the fog diatance extension demo on my site i sadi maybe, it could be the wrong one )
http://members.xoom.com/myBollux
http://members.xoom.com/myBollux
if you''re gonna rotate around all 3 axises its impossible to do thiscorrectly just by using glRotate here read this
http://web2.airmail.net/sjbaker1/eulers_are_evil.html
http://members.xoom.com/myBollux
http://web2.airmail.net/sjbaker1/eulers_are_evil.html
http://members.xoom.com/myBollux
Just useing glRotate? Yea, that''s possable if you can get it to work.
What you need to do is rotate your rotations around the current rotation! If that made sense?
You have to examin how the rotations are taking place and write code to handle any situarion.
For example if you roll 45 degrees to the left your left wing is now half way between the -x and -y axis''s and your right half way between the +x and +y axis''s. If you subsiquently pitch up 90 degrees you have a little problem...
If your program simply adds the 90 to the pitch the nose of the aircraft ends up on the +y axis. In reality it should end up half way between the +y and -x axis''s! To accomplish this you have to rotate the pitch by the roll. This becomes even more complicated as you figure in the heading!
Another complication is the fact that one orientation can be represented by more then one set of numbers!
For example a heading of 180 degrees can also be represented as a combination of a pitch of 180 degrees and a roll of 180 degrees.
This may make it neccisary to change the representation of the rotaions at some point. Like when pitching up or down past 90 degrees you might have to reverse the heading and roll adding more complexity to the program.
This is all related to a problem called gimble lock. The only two solutions I know are to represent the rotation as a matrix or quaternion.
Matrix has a problem as well. rounding errors can cause drift. this can be fixed by renormalizing the matrix. But they can be passed directly to OpenGL with glMultMatrix.
And with quaternions they need to be converted to matrix''s before being passed to OpenGL with glMultMatrix.
It''d actually be nice if there were a provision for passing quaternions to gl but I know of none.
What you need to do is rotate your rotations around the current rotation! If that made sense?
You have to examin how the rotations are taking place and write code to handle any situarion.
For example if you roll 45 degrees to the left your left wing is now half way between the -x and -y axis''s and your right half way between the +x and +y axis''s. If you subsiquently pitch up 90 degrees you have a little problem...
If your program simply adds the 90 to the pitch the nose of the aircraft ends up on the +y axis. In reality it should end up half way between the +y and -x axis''s! To accomplish this you have to rotate the pitch by the roll. This becomes even more complicated as you figure in the heading!
Another complication is the fact that one orientation can be represented by more then one set of numbers!
For example a heading of 180 degrees can also be represented as a combination of a pitch of 180 degrees and a roll of 180 degrees.
This may make it neccisary to change the representation of the rotaions at some point. Like when pitching up or down past 90 degrees you might have to reverse the heading and roll adding more complexity to the program.
This is all related to a problem called gimble lock. The only two solutions I know are to represent the rotation as a matrix or quaternion.
Matrix has a problem as well. rounding errors can cause drift. this can be fixed by renormalizing the matrix. But they can be passed directly to OpenGL with glMultMatrix.
And with quaternions they need to be converted to matrix''s before being passed to OpenGL with glMultMatrix.
It''d actually be nice if there were a provision for passing quaternions to gl but I know of none.
------------------------------Piggies, I need more piggies![pig][pig][pig][pig][pig][pig]------------------------------Do not invoke the wrath of the Irken elite. [flaming]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement