Hmm, It might not be that simple, as obviously when I translate it after I return it to the origin it isn’t going to return to where it was.
My example of unrotating the cube before rotating may have been oversimplified in one respect. In my example, only one rotation around the Y axis is used. If you are using rotations around X, Y, and Z, then in addition to rotating the cube by the -angles, you must reverse of the order of rotations. I have coded this up and tested it. It seems to be working for me if I understand what you really want. The lines of code of interest to you would be …
My example of unrotating the cube before rotating may have been oversimplified in one respect. In my example, only one rotation around the Y axis is used. If you are using rotations around X, Y, and Z, then in addition to rotating the cube by the -angles, you must reverse of the order of rotations. I have coded this up and tested it. It seems to be working for me if I understand what you really want. The lines of code of interest to you would be …
Example of Code
[/QUOTE]
This refuses to work as well. Again this may be my mistake, I will play around. Let me clarify what I want to do. My problem is that after I translate the cube, the rotation is around the origin on the screen. Obviously If I translate first and then rotate, this problem does not occur. But this will not result in the desired movement. I want it so that upon a keypress, the cube will move towards, say, the blue face. If then I rotate the cube (around its own axes), I want it to continue to move towards the blue face.
I have read elsewhere (and I understand why this is being done) people move the object back to the origin, rotate it, and then translate it back to where it was; but I am having trouble implementing this.
So your cube is not moving in a straight line. You want to be able to steer it, i.e. interactively change its direction of motion. To do that I would use glRotates to orient the cube and glTranslate to move it. This gets more involved cause you have to calculate the translation vector by doing your own rotation operations (short, matrix multiplication routines).
Yes, that is basically what I want. Well I know that if I rotate it and then translate it, I will later have problems rotating it, as it will rotate around the origin. If this were a further pure mathematics question I would simply calculate the needed matrix, but it seems I don’t have direct access to the matrix, so maybe you could eleborate a bit further?
btw thanks for all your help 
Hi Ghaz,
Let me first throughout a quick disclaimer that I myself am quite the openGL newbie and by no means of polished code or 100% correct ideas. This being said, I HAVE recently done some things similar to what you are attempting with decent success and particularly this is how I would attack your problem:
First, I return attention to Ekh’s post way back when, who has the correct foundation for what you need to do:
This is the most intuitive way, for me at least to use the matrix translations as what this is doing in English is
a) glTranslatef(…): Translates the origin for our quad to such a new position (moves it linearly about the world frame)
b) glRotatef(…): Rotates the object by such an ‘angle’ around this NEW origin
c) draw(): calls on any rendering function you yourself defined (in this case, glBegin(GL_QUADS)…). NOTE: that this entire object is draw about the NEW origin location in the NEW rotation from a) and b)
d) glPopMatrix()x2: Inverse to the glPushMatrix()'s preceding a) and b). Effectively undoes the translation and rotation for all future rendering (useful if say, you wanted to have a second cube whose position/orientation were independent from the first…)
NEWBIE PITFALL: quick note about push/pop (cause I was that guy that spent a day figuring this out the hard way…)
You should be VERY careful to perform the inverse pop for each and every push that you write, ESPECIALLY if you are looping through that piece of code (odds are you are if you get to it from glutIdleFunct(…) or some such thing). The reason being is that you will be one level higher on your stack than you meant to be for each pop that you miss. This error propagates in many amusing and head-scratching ways if you don’t know to look for it, effectively moving your scene infinitely if translations are involved.
So, where was I? Back to your issue at hand. Assuming you understand the above well enough to implement such a foundation, your problem in my eyes is NOT that you need more matrices as this gets to be a heartache and a half (at least to me), but rather that you need some sort of calculated variable for the parameters of your single glTranslatef(). While it sounds complicated, I humbly believe that this method will be better than any additional matrices in the end as it allows you more direct control over your program rather than calling on obscure matrix transform functions more than necessary.
Simply put, you want to advance your cube’s position some delta-position in the x,y, and z every time you move it ‘forward’ as defined by your current orientation. I assume turning it is no big deal, as you can just intuitively alter the value of glRotatef() directly, however this angle shall be invaluable for calculating your LINEAR translation as well.
All you have to do is a bit of highschool trig so long as you know the initial ‘front’ of your cube and of course the current angle for glRotatef(). I will for simplicity assume that th front is facing the +y axis, and that your rotation is of the form glRotatef(angle,0,0,1), as in it will rotate counter-clockwise as you increment ‘angle’. I will also assume that you desire to move the cube forward some distance, D. You merely need a
dx = -D*sin(angle*PI/180);
and
dy = D*cos(angle*PI/180);
ASIDE: note the need to convert the angle value as trig functions in openGL read RADIANS but our mind thinks in DEGREES generally, which I assume is true for your program and the initial units of ‘angle’. Feel free to make this ratio a cleaner constant for your program to use. I put in the actual value for clarity. Also note that dx is calculated as negative direction by virtue of large values for ‘angle’ turning the object COUNTER-clockwise (there is a chance I am wrong about this…).
So, with this dx and dy you need only two more lines:
x_translate += dx;
and
y_translate += dy;
Before you call upon your matrix translations where x_translate and y_translate are your x and y values for glTranslatef(), respectively. Note the beauty that at the end of the day these two values represent your TOTAL overall translation from your initial origin, which is exactly how glTranslate() operates.
Done.
Amusing anecdote:
Though I am painfully aware of my already exorbitantly long post, I cannot help sharing a (wrong) idea that occurred to me for this problem as I was typing:
To keep the whole program utilizing JUST matrix transforms and no math, one could reasonably write a recursive method of a form:
...
void cubeMove(int i){
pushMatrix();
rotate(angle[i]);
pushMatrix();
translate(distance[i]);
if(i==0) //draw once you've traversed the WHOLE path...
drawStuff();
else //many more matrices, yay!
cubeMove(i-1);
popMatrix();
popMatrix();
}//worst method ever.
where basically, your distance and angle arrays become one larger every time the user changes angle (and/or?) distance, or quite possibly each time the program loops period, and at this point the cubeMove() is called upon with an index one higher, to infinity…hmmm. However HORRIBLE of an idea this is, it is interesting to note that in this form we have chicken-and-egg situation where we can pretty safely exchange the hierarchical of translate and rotate as we have an infinite number of each to work with.
So ya, this is the sort of thing that comes to mind for me when i think of working with any number of matrices greater than two for a given object. Though I am sure such previously proposed scenarios cannot be worse than infinite matrices…:).