camera or translate
Author
hey everyone...
which, in your opinion is better for moving around a 3d world: gluLookAt or glTranslatef and glRotatef? i have always used translate ond rotate before, but today i tryed to use lookAt. It seems much more complicated that the other two methods. should i stick with translate and rotate or should i start using lookAt? -PmanC
gluLookAt isn''t complicated, it actually makes things much easier.
The first 3 numbers are where the camera is. The second 3 numbers are where you are looking, and the last 3 numbers are what direction is up (0,1,0).
While of course the camera doesn''t ever actually "move", it makes it easier to think of it that way.
But most people say it''s slow, and that you should write your own version of it. I haven''t tested that myself, haven''t gotten around to it...
------------
aud.vze.com - The Audacious Engine <-- Newbie alert, look at your own risk. Can induce severe laughing fits and other variations of hysterical outburst.
The first 3 numbers are where the camera is. The second 3 numbers are where you are looking, and the last 3 numbers are what direction is up (0,1,0).
While of course the camera doesn''t ever actually "move", it makes it easier to think of it that way.
But most people say it''s slow, and that you should write your own version of it. I haven''t tested that myself, haven''t gotten around to it...
------------
aud.vze.com - The Audacious Engine <-- Newbie alert, look at your own risk. Can induce severe laughing fits and other variations of hysterical outburst.
Although using gluLookAt or Translate for a camera is hard to grasp when first going through it, using gluLookAt with a camera is easier to implement in the long run. Especially if you want the user to be able to fly around in free space rather than on a single plane.
I asked one of the Black Robes why the Deceiver wasn't going to stay to defend the dam, and he tersely replied: "He goes to warn the Emperor; moving through odd angles, faster than any man, and if unobserved, much faster than that."
[edited by - Jedi of Myth on June 4, 2002 11:25:27 PM]
I asked one of the Black Robes why the Deceiver wasn't going to stay to defend the dam, and he tersely replied: "He goes to warn the Emperor; moving through odd angles, faster than any man, and if unobserved, much faster than that."
[edited by - Jedi of Myth on June 4, 2002 11:25:27 PM]
Just don''t fall into the trap of thinking the last three params of gluLookAt will always be 0,1,0 ... I''m pretty damn sure they represent the view up vector , not the world up vector.
The reason that they must not be simply set to 0,1,0 is that because gluLookAt uses this, along with the calculated forward vector (from eye xyz and lookat xyz), to create an orthogonal view matrix (getting the right vector from a crossproduct of the forward and up vectors). What happens if the forward vector coincides with the up vector? Bad Things (TM)
Additionally, misusing the up-vector like this restricts you from rotating the view on all three axes (no z rotations).
The reason that they must not be simply set to 0,1,0 is that because gluLookAt uses this, along with the calculated forward vector (from eye xyz and lookat xyz), to create an orthogonal view matrix (getting the right vector from a crossproduct of the forward and up vectors). What happens if the forward vector coincides with the up vector? Bad Things (TM)
Additionally, misusing the up-vector like this restricts you from rotating the view on all three axes (no z rotations).
I think gluLookAt() is very easy to use when you''re familiar with sin and cos.
What you simply do is to create a sphere around you and then LookAt a point on the sphere.
this snip of code comes from a VB program I coded some time ago using lookat:
Maybe you see the point. I think thats very easy to use.... maybe not to understand
mx, my, mz are actually delta-values around the cam-position.
But I have one important question:
Which method is faster? Using LookAt() wanted be OpenGL (because they created this function) and using Rotate and translate is interesting (I didn''t test that yet). But what is faster and why should it be so??
dark
What you simply do is to create a sphere around you and then LookAt a point on the sphere.
this snip of code comes from a VB program I coded some time ago using lookat:
Control.Mouse_GetState mousex, mousey, button1, Button2, 0, 0, True alfa = alfa + (mousex / speed) beta = beta - (mousey / speed) If beta > betamax Then beta = betamax If beta < -betamax Then beta = -betamax ''// calculate x; y; z coordinates for the LookAtPoint my = Sin(beta) * 6 radius = Cos(beta) * 6 mx = Sin(alfa) * radius mz = Cos(alfa) * radius ''// calculates the movementvalues for the camera movecamx = Sin(alfa) * 6 movecamz = Cos(alfa) * 6 slidecamx = Sin(alfa + 3.14159265358979 / 2) * 6 slidecamz = Cos(alfa + 3.14159265358979 / 2) * 6 Maybe you see the point. I think thats very easy to use.... maybe not to understand
mx, my, mz are actually delta-values around the cam-position.
But I have one important question:
Which method is faster? Using LookAt() wanted be OpenGL (because they created this function) and using Rotate and translate is interesting (I didn''t test that yet). But what is faster and why should it be so??
dark
quote:Original post by DarkKiller
But I have one important question:
Which method is faster? Using LookAt() wanted be OpenGL (because they created this function) and using Rotate and translate is interesting (I didn't test that yet). But what is faster and why should it be so??
Here's the MESA' gluLookAt function :
void GLAPIENTRYgluLookAt(GLdouble eyex, GLdouble eyey, GLdouble eyez, GLdouble centerx, GLdouble centery, GLdouble centerz, GLdouble upx, GLdouble upy, GLdouble upz){ GLdouble m[16]; GLdouble x[3], y[3], z[3]; GLdouble mag; /* Make rotation matrix */ /* Z vector */ z[0] = eyex - centerx; z[1] = eyey - centery; z[2] = eyez - centerz; mag = sqrt(z[0] * z[0] + z[1] * z[1] + z[2] * z[2]); if (mag) { /* mpichler, 19950515 */ z[0] /= mag; z[1] /= mag; z[2] /= mag; } /* Y vector */ y[0] = upx; y[1] = upy; y[2] = upz; /* X vector = Y cross Z */ x[0] = y[1] * z[2] - y[2] * z[1]; x[1] = -y[0] * z[2] + y[2] * z[0]; x[2] = y[0] * z[1] - y[1] * z[0]; /* Recompute Y = Z cross X */ y[0] = z[1] * x[2] - z[2] * x[1]; y[1] = -z[0] * x[2] + z[2] * x[0]; y[2] = z[0] * x[1] - z[1] * x[0]; /* mpichler, 19950515 */ /* cross product gives area of parallelogram, which is < 1.0 for * non-perpendicular unit-length vectors; so normalize x, y here */ mag = sqrt(x[0] * x[0] + x[1] * x[1] + x[2] * x[2]); if (mag) { x[0] /= mag; x[1] /= mag; x[2] /= mag; } mag = sqrt(y[0] * y[0] + y[1] * y[1] + y[2] * y[2]); if (mag) { y[0] /= mag; y[1] /= mag; y[2] /= mag; }#define M(row,col) m[col*4+row] M(0, 0) = x[0]; M(0, 1) = x[1]; M(0, 2) = x[2]; M(0, 3) = 0.0; M(1, 0) = y[0]; M(1, 1) = y[1]; M(1, 2) = y[2]; M(1, 3) = 0.0; M(2, 0) = z[0]; M(2, 1) = z[1]; M(2, 2) = z[2]; M(2, 3) = 0.0; M(3, 0) = 0.0; M(3, 1) = 0.0; M(3, 2) = 0.0; M(3, 3) = 1.0;#undef M glMultMatrixd(m); /* Translate Eye to Origin */ glTranslated(-eyex, -eyey, -eyez);} It contains :
- 2 cross products
- 3 vector normalization (sqrt + muls)
- 2 matrix multiplications (glMultMatrix and glTranslate)
So, it shouldn't be slow. Will it be faster than glRotate+glTranslate ? It depends on the glRotate implementation.
Anyway, the difference shouldn't be noticeable. After all, you only have to use it once per frame so I really doubt it will be the application bottleneck (unless of course you just display a black screen).
EDIT : messed up with source tags.
[edited by - Prosper/LOADED on June 7, 2002 5:14:20 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
