Global rotation

Hi,

I’m having a few problems trying to get my object to rotate around the global (world) axis, rather than it’s own local axis.

Here’s the order in which I’m doing my transformations:
gl.glTranslatef(transObjx,transObjy,transObjz);
gl.glRotatef(rotObjx,1.0f,0.0f,0.0f);
gl.glRotatef(rotObjy,0.0f,1.0f,0.0f);
gl.glRotatef(rotObjz,0.0f,0.0f,1.0f);
gl.glScalef(scaleObjx,scaleObjy,scaleObjz);

But this is giving me undesirable results! Here’s what happens. Say my object starts off like this first image:

Now after the first rotate of 45 degrees around the X axis it looks like this:

But now when the object rotates around the Z axis, it looks like the following image:

It it rotates around the purple axis not the blue one, because it’s already been rotated around the X axis first!

How can I get it to rotate around the blue Z axis, regardless of how much it’s been rotated around the X axis? In other words, I need to force OpenGL to retain the same global axis when I’m doing rotations, not the local axis.

I know I could do this easily if I wrote the rotation code myself, but I’m using Java so this will slow it down a lot.

Many thanks for your help!

Bob

Try to find a copy of the red book (OpenGL Programming Guide), might be in this site as well. There it states that the order you write down your transformations depends on whether you think in object or world coordinates. In essence, try reversing the order with which you pass the transformations and you’ll probably get what you want. But do read the chapter about transformations from the red book. Cheers

PS Ok, I agree that Java is slow but have you heard of glMultMatrix?

Java hasn’t been slow for years. In fact in most cases it comes very near to native speed - because the most essential bytecode get’s compiled to native code at runtime, plus Hotspot can perform many optimizations at runtime (that static compilers cannot).

Now, I’m still a clewless newbie with opengl, but in my understanding it’s even crazy to think about the speed of rotation calculations because you’re using immediate mode - which is SLOW. And as I’ve gathered, if you’re going to use vertex arrays, you’d have to perform the calculations yourself anyways.

Thanks for the replies.

dvm - yeah I did consult the Viewing chapter in the red book before posting, but I couldn’t get what I wanted from it. What it deals with is the difference between the local and global axis when you’re actually translating an object.

In my case, this doesn’t apply since the object itself is always positioned at the centre of origin. At the moment the only GL commands in my code that actually do anything are the rotate commands - I only put the translate and scale commands in my example above just for completeness.

The thing is, once you’ve done the first rotate command, it then skews the axis off for whatever command you do next. It becomes a local axis. So no matter what order you put your glRotatef commands in, it still rotates around a local axis, not the global one.

And I’ve tried using the glMultMatrixf command too, but when you’re doing a rotate with this you’re essentially just doing the same thing the glRotatef command does anyway.

glClewbie - yeah, I know Java’s not that slow any more, but my objects will contain a hell of a lot of polys (70,000 or more), and I’m sure that having to rotate them all with my own Java code will still make a significant impact on the performance.

On my 3.6ghz Dell it can throw 70,000 polys around the screen at 11fps (which is fast!) - but I’m expecting to have several objects of that complexity on screen, so it will still make a difference.

I was only kidding with Java, but C/C++ rest in my heart
As for your problem you know the solution. And I wouldn’t be so sure about your object staying at the center of origin. Since you transform, you’ve lost the global coordinates (which remain fixed).
See page 108 of the red book (version 1.2) about the Grand, Fixed Coordinate System. Write down the order you suppose your transformations should occur, and then reverse them in your code.

Sometimes things may be more complicated, but usually a little fiddling around with the order of transformations produces the result.