Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 3 of 3

Thread: Rotating around my object using gluLookAt moves really fast

  1. #1
    Junior Member Newbie
    Join Date
    Feb 2013
    Posts
    3

    Rotating around my object using gluLookAt moves really fast

    Hi everyone,

    I'm trying to move around a cube centered at the origin using gluLookAt instead of performing the R*T transformation directly on the object. At first, I was not sure how to do this problem. Then I realized (after implementing half of a solution in circular coords) that I should try using a spherical coordinate system representation. I was able to write some code to do this, but I (the 'eye' of the camera) spin really quickly around the cube. Also, I notice that I'm moving a bit closer to the cube as well instead of holding a constant radius. When I use the Rotate*Translate method, it spins at a more proper rate with the same distance.

    My approach for rotation was to use spherical coordinates, but I'm not sure if this is correct. I calculate the two angles, according to the diagram located on the Wikipedia page (I cannot link to it. My account is too new). I calculate the magnitude of the current point I'm at (represented by distX, distY, and distZ ; we are initially in the XY plane looking at the negative Z plane). I'm also given two angles, one to specify the angle of rotation about the x-axis and one for the y-axis. These five values are calculated based on how my mouse clicks are made.

    I calculate theta and phi based off of some trig and then finally the new position. These formulae can be found in that link earlier. The last step is to plug it into gluLookAt. Again, upon running this program, I am able to spin around the cube, but it is very fast and translates the camera as well. What am I doing wrong?

    My code is listed below in case you want to reference it. The part referencing 'y' and 'up' are my attempts to calculate the rotation about the Z axis. The best way I can describe that rotation that is if you look at an object, imagine yourself the camera, and tilt your head left and right. I did not include it in my gluLookAt since I couldn't get that to work either.

    Code :
    void sceneTransformation(){
    	glLoadIdentity( );
            //Using the R*T approach. Works flawlessly
    	//glTranslatef(-distX, distY, -distZ);
    	//glRotatef( anglex, 1.0, 0.0, 0.0 );
    	//glRotatef( angley, 0.0, 1.0, 0.0 );
     
    	GLdouble radx = anglex*PI/180.;
    	GLdouble rady = angley*PI/180.;
     
    	GLdouble l = sqrt(pow(distX, 2) + pow(distY, 2) + pow(distZ, 2));
    	GLdouble phi = atan(distY/distZ) + anglex;
    	GLdouble theta = acos(distZ/l) + anglex;
     
     
    	GLdouble deltaZ = l*sin(theta)*cos(phi);
    	GLdouble deltaY = l*sin(theta)*sin(phi);
    	GLdouble deltaX = l*cos(theta);
     
     
    	GLdouble ytheta = atan(distX/distY); 
    	GLdouble y = sqrt(pow(distX,2) + pow(distY, 2));
    	GLdouble yangle = 90-ytheta-angley;
     
    	GLdouble up_y = y*sin(yangle);
    	GLdouble up_x = y*cos(yangle);
     
    	gluLookAt((distX - deltaX), (distY - deltaY), (distZ - deltaZ), 0, 0, 0, 0,1,0);
     
    }

    Thanks for any help!

  2. #2
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,190
    Quote Originally Posted by thewriter View Post
    I'm trying to move around a cube centered at the origin using gluLookAt instead of performing the R*T transformation directly on the object. ... Then I realized ... I should try using a spherical coordinate system representation. ... but I (the 'eye' of the camera) spin really quickly around the cube.
    Your basic tech approach makes sense. You just need to reduce the angle traversed in one second. (Haven't sifted your code though.)

    Query your system time value in seconds (e.g. gettimeofday() or whatever). Decide what angle/second rotation rate you want. Then multiply it by the system time, modulo by some reasonable angle range (0..2pi or whatever), and feed to your trig functions. Gearing your animation rate to real-world time has the advantage of making your rendering independent of frame rate.

  3. #3
    Junior Member Newbie
    Join Date
    Feb 2013
    Posts
    3
    If that is the case, then why does the model transformations route work fine without matching the frame rate? I tried implementing what you proposed, but the result was unsuccessful.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •