   airplane rotation problem
  Hi all,I search since the morning for a way to rotate an airplane correctly. My game calculates three angles, pitch, yaw and roll which should be the orientation of the airplane. I try to rotate the axis with the plane after the glRotatef(angle, vx, vy, vz) call, but it doesn''t work.If someone has already solved this problem, please post a part of the sourcecode. (I have already hundreds of pdfs googled - but without success. I just found that I'' m not the only one with the airplane rotation problem ;()thank you in advance,turbotank 
  It seems like you''re running into a thing called "Gimbal Lock."  You could try using quaternions to store your rotations, as they don''t have this problem.  There are lots of quaternion tutorials out there.   ;  first things first: the fact that euler angles are extremely useless to store orientations is NOT called gimbal lock. it seems that word gets tossed around all the time without knowing its meaning and from there its "oh, didnt quaternions solve that problem, you have to use quaternions".if he is using glrotate, i see absolutely no way for gimbal lock. every rotation will change the axes and they will still be orthonormal. maybe someone enlighten me how two axes should end up the same in that case (as i doubt he''s mixing rotations around local and global axes). in other words: unless his problem is that he''s rotating 90° (or 180 or whatever) and then being unable to do some other rotation there is no "lock".later the same person will come back, having replaced matrices for rotations with quaternions and guess what? it doesnt solve a thing. a faulty architecture wont become correct by using another hammer to build the house.there is a way to work with three angles. use two as polar coordinates and a third for roll, then always rotate yaw,pitch,roll. why wouldnt i use that? imagine your plane rolled to the left 45 deg. you pull back the stick and the plane turns around its LOCAL x axis. you can NOT just add some number to pitch and expect the right result, because you influenced all three angles and figuring out how much to add/subtract to them would just mean a lot of trig."I try to rotate the axis with the plane after the glRotatef(angle, vx, vy, vz) call, but it doesn''t work."now THAT sounds like a good start. you noticed you have to update the axes you rotate around after each rotation. your next step is not to call glrotate, because you only care about that new axis.question: are you aware that the transformation matrix is storing exactly those axes (right/up/forward + position) and calling rotate will update them (and has the nice advantage of keeping them orthonormal, if you do the math yourself rounding errors will make your matrix/vectors fall apart over time).what you can do easily is either store this matrix per object and apply rotations/translations to it (you will have to "fix" it every few rotations) or load it, do the transformation and read it back (which might have quite some overhead if you use it too much, but does all the work for you).to render multiply it to the modelview (which shouldnt contain anything but the "view" at this time).if you feel like not using that much memory you can use quaternions and a position vector to store the orientation. of course then you have to build quaternions for every rotation and convert the quaternion to a matrix once per frame for opengl (they are fine to save memory or if you need to interpolate rotations, else i still cant see any reason to bother). ;  Hi Trienco,""I try to rotate the axis with the plane after the glRotatef(angle, vx, vy, vz) call, but it doesn''t work."now THAT sounds like a good start. you noticed you have to update the axes you rotate around after each rotation. your next step is not to call glrotate, because you only care about that new axis."does that mean that:glRotatef(pitch, 1,0,0)rotate upvector around rightvector with pitch as angle.glRotatef(yaw, newupx, newupy, newupz)...wont work?"what you can do easily is either store this matrix per object and apply rotations/translations to it... "three reasons why i dont want to use a matrix for rotation:- dont want to have the get/store/set overhead of a 4x4 matrix per object (just if possible)- i think (hope) that a GPU should calculate the matrix faster as a CPU- i have not realy much expereance with matrices (i dont want to wait with the rotation thing until i will learn it at school)realy frustrating, i have written a well working terrain/objectfollower but i''m unable to rotate my objects around more as 1 axis correctly.thank you for the replies!i hope you understand my english turbotank ;  short question,are pitch, yaw and roll already euler angles?turbotank ;quote:Original post by turbotank  does that mean that:glRotatef(pitch, 1,0,0)rotate upvector around rightvector with pitch as angle.glRotatef(yaw, newupx, newupy, newupz)...wont work?if you try that you do too much. all transformations in opengl are happening in local space (given by the current modelview). when you call rotate for pitch you already are changing your up and rotating around (0,1,0) already IS your new up. so whatever your newup will result in is most likely not the "up" of your object.also, keep in mind that the typical naive approach of just storing three angles cant and wont work for anything but very basic first person shooter cameras. you need to store at least two vectors (usually forward and up) and update them with every rotation. if at the moment you try something likeif input=left : yaw--if input=right : yaw++etc.and dont just use pitch/yaw/roll to collect small rotations in a single frame you throw away the order in which they have been applied and will end up in a lot of orientations, but not the one you want. while for very small angles (like the changes within one frame) different orders wont make a noticeable difference it''s not something to try for anything else.the reason i suggest storing the matrix is that its just one more vector and keeping the "right" vector around means that a) you dont have to calculate it every frame and b) its often useful to have all three (though more for cameras than objects, unless they are supposed to strafe). ;quote:Original post by Trienco  if you try that you do too much. all transformations in opengl are happening in local space (given by the current modelview). when you call rotate for pitch you already are changing your up and rotating around (0,1,0) already IS your new up. so whatever your newup will result in is most likely not the "up" of your object.also, keep in mind that the typical naive approach of just storing three angles cant and wont work for anything but very basic first person shooter cameras. you need to store at least two vectors (usually forward and up) and update them with every rotation.I havent thought that it will be so easy!thank you for the explanations!it works perfectlyturbotank