What better(faster):gluLookat or glTranslate/Rotate?

Plus, keeping your own matrices will also make your code more portable if you ever move away from OpenGL (perish the thought). Of course, you may have to transpose your matrices if you use something else.

Wow, a troll in the OpenGL forum; now I have seen everything.

Don’t get me wrong, I think the world needs alot more high school age script kiddies who have nothing better to do with their time.

Especially such a masterful OpenGL god as the author of these posts: http://www.opengl.org/discussion_boards/ubb/Forum2/HTML/010467.html (No comment) http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/009016.html (Advanced OGL…? This isn’t even advanced programming!)

I’ve also noticed you use GLUT. Haha, if you’re going to bash GLU, why use the library that completely abstracts the main program away from you?

He’s right though. Along those same lines, why should we even bother going to the gas station to get gasoline when we can be leet and go to an oil rig and pump the crude out ourselves, take it to the refinery and crack our own fuel. /me rolls eyes

Now to answer the original question: Use what works. gluLookat certainly makes things easy. But if you find it’s draining your performance when it comes time to optimize, then look into a better solution.

Well Gumby, at least you give a usefull answer. Now it makes alot more sence to me.
If the other guy (I don’t remember his name) told us this instead of that ‘advanced’ forum crap we would not have reacted that way. Thanx again for your answer.

I don’t know but, if talking about a nVidia driver cheat in 3D mark 2003 is an advanced topic then what the hell am I even doing in the beginners forum. I should head over there and be ‘advanced’

Especially such a masterful OpenGL god as the author of these posts: http://www.opengl.org/discussion_boards/ubb/Forum2/HTML/010467.html (No comment) http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/009016.html (Advanced OGL…? This isn’t even advanced programming!)

Oh My God, I almost died from laughing!
Goddamned never post something like this anymore, you want me to die or something?

Thank’s for all replies. It was interesting. But returning the basic question i thing that i need information about low level calculations mechanism that use opengl to undarstand what faster in different cases.

“But returning the basic question i thing that i need information about low level calculations mechanism that use opengl to undarstand what faster in different cases.”

Why? Use gluLookAt() and run your program. If it performs OK, stop. If not, profile it to see where the bottlenecks are. More than likely they’re not in OpenGL code anyway. Once you’ve found the bottleneck, tweak your code to fix it.

Try to resist the urge to prematurely optimize.

to make something clear:

the most people are switching from gluLookAt() for leaving the linkage with glu.lib,
because this needs one dll more, on which your program depends on…

returning swiftly to topic:

I think that if we use gluLookat we do next steps:

  1. Calculate position of camera
  2. Calculate position of target
  3. Calculate position of up vector
  4. Let OpenGL calculate matrix using previous data.

If we use glTranlate/Rotate we only let OpenGL calculate matrix. Doesn’t it faster?

well, it all comes down to HOW you compute the matrix. I’ll explain how gluLookAt works to try and illustrate why its easy enough just to build the matrix.

but, hold the thoughts on gluLookAt for a moment and consider this intereting trick with rotation matricies.

OpenGL uses 4x4 matricies to represent transformations in homogeneous coordinates. Certain parts of this 4x4 matrix effectively do different things because of the way they modify incoming verticies. Keep in mind that the matricies map one space to another space (but the identity matrix maps the space to itself: ie. there is no change).

The upper 3x3 sub-matrix represents the orientation and scale of the axis and the fourth column represents the remapped position. I want to focus on the upper 3x3 matrix for most of my discussion. Its interesting property is that you can directectly get back the three vectors that span the space. What spanning a space means is that you can get any vector in three-space by linear combinations of the basis, or spanning vectors.

An example of this is the identity matrix, which has an upper 3x3 of

1 0 0
0 1 0
0 0 1

if we take the three column vectors we have [1 0 0] (the first column), [0 1 0] (the second) and [0 0 1]. Now, think of any three-dimensional point… say, <1 2 3>. this can be represented as a linear combination of these three vectors, namely

<1 2 3> := 1 * <1 0 0> + 2 * <0 1 0> + 3 * <0 0 1>

we can do this for ANY three-dimensional point, and so we can say that these three vectors span the space. (Side note: its possible to come up with three vectors that don’t span the entire space. For example, we could set the third vector to be <0 0 0>, not <0 0 1>… this means the z-dimensional becomes the null space of the matrix because its impossible to represent a 3D point with a non-zero z value).

What does this have to do with gluLookAt? Well, the handy trick is that we can directly construct a rotation by figuring out where we want the identity transform to be mapped to.

An example of this is the following. Suppose we want to come up with some rotation/scale matrix that maps the X, Y and Z axises to the vectors A, B and C respectively. that is, we want to move a point such as <1 0 0> (along the x axis) to be some point thats a linear combination of A. So, if A was <1 2 3>, then we want <1 0 0> to ‘turn into’ <1 2 3>. If you’re not clear about that then think about what a transformation is doing. A translation to <1 2 3> says that the point <0, 0, 0> “turns into” <1 2 3>, and all other points are SIMILARLY mapped. Here we’re saying we want points along a particular vector to “turn into” points along ANOTHER particular vector. We can directly build this transformation with the matrix

A1 B1 C1
A2 B2 C2
A3 B3 C3

which is a pretty interesting result. How does this affect gluLookAt?

Think about the interface to gluLookAt. You need a camera position, a point the camera is looking at, and a vector to describe the ‘up’ position.

What we’re saying is that we want all points along the Y axis to be mapped to the ‘up’ vector, and points along the X and Z axis to be mapped to some vectors “sensible” with the position, lookat and sky vectors.

Since the default opengl system treats -z as depth, we can compute the map vector for z as the vector from the position of the camera to the look-at point. That’s easy: Z’ is just the vector lookat-position. The X’ vector is some vector thats orthogonal, or perpendicular to both the Z’ and Y’ vectors. We can compute that easily by the cross product of Y’ and Z’. The cross product of two vectors will give a third vector at right angles to them. The cross product is essentially computing the determinant of a parameterised 3x3 matrix.

So, with one cross product and one vector subtraction we’ve computed three vectors to represent the rotation we need to build. All we need to do is plug these into the 4x4 matrix like so:

X1' Y1' Z1' p1
X2' Y2' Z2' p2
X3' Y3' Z3' p3
0   0   0   1

where Y’ is the sky vector, Z’ is lookat-pos, and X’ is the cross product of Y’ and Z’. the p in the fourth column is the position vector again; it maps the origin to the new position.

SO… why can’t this be done directly in opengl? Firstly, because its not necessary as we can build the matrix directly, and secondly because opengl doesn’t have an interface for the cross=product. At the end of the day, gluLookAt isn’t a lot of code and is certainly far from computationally expensive.

I hope this helps.

cheers
John

DJSnow : that might be true, but isnt glu required to exist in order for the envrinment to be opengl compliant? in that case it really doenst matter if its one or 2 dlls, since if one exist the other must exist too, and in the other case we can say that atleast in windows, its up to date allways shipped toghether with opengl32.dll

Well thanx for the math lessons but this stuff I knew from my math books.
Anyhow it’s post like this that help the community!

I think we can conclude that it’s OK to use gluLookAt() because it’s not doing anything heavy. Use it untill you come at a point where it doesn’t fit your needs anymore and you have a solid reason of why to write your own routines. When the time comes you will know what to do, and if not then ask here

BUT ALWAYS REMEMBER THIS:
Donald Knuth once said:
“We should forget about small efficiencies, about 97% of the time. Premature optimization is the root of all evil.”

The critical word is PREMATURE. I’m not against optimization. I’m just against unnecessarily poor software designs that are justified in the name of optimization.
Remember this your whole life!

Originally posted by NVade:
[b]

Especially such a masterful OpenGL god as the author of these posts: http://www.opengl.org/discussion_boards/ubb/Forum2/HTML/010467.html (No comment) http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/009016.html (Advanced OGL…? [/b]

Sorry for going off-topic guys but I had to do it : Bravo NVade!

John - Thanks! That’s good stuff. I archived a copy of your latest post for future reference. It kind of reminds me of Steve Baker’s “Matrices can be your friends” article:
http://www.sjbaker.org/steve/omniv/matrices_can_be_your_friends.html

I have not been in the OGL world for a long time due to work. But GODDAMN some things do not change. Right Mihail?? Some people just suck for a life time and never snap out of it…

Well, to help out on the camera system with glRotate, glTranslate, glLoadMatrix… I might have gluLookAt somewhere in there too. Anyways, I have several demos demonstrating how to build your own matrices from quaternions and use glRotate, glTranslate, and glLoadMatrix… If you are interested…
http://141.217.130.254/miguel/

To add on the glRotate and glTranslate compared to gluLookAt.
I would use gluLookAt if it is a quick demo. But for a bigger demo I would glRotate and glTranslate because as someone already said, they are done in HW.
I must also say that it all depends on what you like best. I like rotate and translate better because I feel I have more control over what I do. gluLookAt hides the work from you; it creates a view matrix.

All in all, they both give the same result, so your real concern should be which one you feel more confortable using, since the overhead is not even noticible.

Thank’s for tutorial & links. I will keep it in mind.

Hello,

I think the argument for rotate/translate over gluLookAt is obfuscated, somewhat, by speed issues. It is true that both generate a transform matrix, but where they differ isn’t necessarily just that one is directly supported in hardware, but that they have different interfaces. I think this argument is more important.

For instance, how would you set up the rotation/translation so that the user is at A, looking at B with the up-vector C? The answer is simple with gluLookAt, but the only way that i can think of from the top of my head to do this using purely rotate/translate is to to project A and C onto the XZ and YZ axis and compute the angle to find the X and Y rotations and project the up axis onto the XY plane to find the Z rotation. That’s a lot of work JUST so you can turn around and provide three rotation + one translation call to GL.

Is my point clear? Certainly it’d be easier to shift a camera once its orientated and y ou want to make modifications to it in a picewise fashion, but if you start with the identity matrix and want to jump to a particular postion/lookat/up configuration then I think you’d be hard pressed to come up with a better solution than gluLookAt. My argument is that its not so much a matter of trivial amount of speed difference but that both offer different interfaces and ease of expressing different transformations.

cheers
John

Originally posted by john:
[b]Hello,

I think the argument for rotate/translate over gluLookAt is obfuscated, somewhat, by speed issues. It is true that both generate a transform matrix, but where they differ isn’t necessarily just that one is directly supported in hardware, but that they have different interfaces. I think this argument is more important.
[/b]

True, I already mentioned it and it is an desicion that is made depending on what is easier for each individual.


For instance, how would you set up the rotation/translation so that the user is at A, looking at B with the up-vector C? The answer is simple with gluLookAt, but the only way that i can think of from the top of my head to do this using purely rotate/translate is to to project A and C onto the XZ and YZ axis and compute the angle to find the X and Y rotations and project the up axis onto the XY plane to find the Z rotation. That’s a lot of work JUST so you can turn around and provide three rotation + one translation call to GL.

What is the use of projecting a vector in order to translate or rotate?
Fortunately, projections are not needed for what you are suggesting; rotating an object or whatever you want… You always have three axis that are orthogonal, and operations are cumulative. This allows for independet rotation along any axis. So, yes you are right you need three glRotate and one glTranslate to rotate, but this is only if you are using euler angles, which by nature is buggy (it suffers from gimbal lock). If you were using quaternions, you would only need one glRotate, and one glTranslate, and this does not suffer from gimbal lock.


Is my point clear? Certainly it’d be easier to shift a camera once its orientated and y ou want to make modifications to it in a picewise fashion, but if you start with the identity matrix and want to jump to a particular postion/lookat/up configuration then I think you’d be hard pressed to come up with a better solution than gluLookAt. My argument is that its not so much a matter of trivial amount of speed difference but that both offer different interfaces and ease of expressing different transformations.

Well, I really dont see why a piecewise rotation is any different from rotating a identity matrix whatever amount you want. What I mean is that you do not need to rotate one degree each time. You can rotate 45 degrees one time and 30 the other!!! Simply do a sin(45) cos(45) and sin(30) cos(30)!!! To jump from 0 degrees to 85 degrees? do a sin(85) and a cos(85)!
The rotation matrix is created by OGL when you call glRotate. You can create your own matrix and load it or multiply it by the existing one.

I suggest you look at the code I have for camera systems… It is fairly clear and quite helpful if you want to learn how some basic camera systems work.

Miguel

What is the use of projecting a vector in order to translate or rotate?

to find out the angles about each three axis. Actually, for a given point in three dimensions you only need to find two angles of rotation because a single point doesn’t define the ‘up’ vector. Given a point <A B C> you need to project htat point to the XZ plane and hence compute the rotation of the point <A C> with

y_rotation=atan2(C, A);

and then compute the X rotation by projecting the point to the YZ plane with

x_rotation=atan2(B, C);

Fortunately, projections are not needed for what you are suggesting; rotating an object or whatever you want…

then what would you suggest?

but this is only if you are using euler angles, which by nature is buggy (it suffers from gimbal lock). If you were using quaternions, you would only need one glRotate, and one glTranslate, and this does not suffer from gimbal lock.

well, euler angles aren’t buggy. They only have degenerative issues in some cases, but that isn’t a bug and it is only a hinderance if you’re parameterisation is bad. Gimbal lock occurs becuase you’re rotating your rotation device, also; it isn’t a problem if you don’t do that. There isn’t a degeneracy in this case because its being statically computed, not modified.

quote:
Is my point clear? Certainly it'd be easier to shift a camera once its orientated and y ou want to make modifications to it in a picewise fashion, but if you start with the identity matrix and want to jump to a particular postion/lookat/up configuration then I think you'd be hard pressed to come up with a better solution than gluLookAt. My argument is that its not so much a matter of trivial amount of speed difference but that both offer different interfaces and ease of expressing different transformations.

The rotation matrix is created by OGL when you call glRotate. You can create your own matrix and load it or multiply it by the existing one.[/QUOTE]

what I meant by picewise transformation was building the transformation matrix as a culmination of transformation operations, not rotating/translating by a unit at a time. gluLookAt isn’t piecewise; it computes a single matrix. successive calls to glRotate about each axis and a glTranslate is (from my intended meaning) a piecewise approach insofar as you’re making successive modifications.

I suggest you look at the code I have for camera systems… It is fairly clear and quite helpful if you want to learn how some basic camera systems work.

<cough> ah, thanks. I’m doing a PhD in computer vision modelling real cameras to reconstruct geometry from photograms. :slight_smile: Oh, and we use Euler angles all the time; quaterions are really only applicable for animating rotations, not for computing static rotations.

Want to see my camera class? :slight_smile: It even models skew and optical centre parameters. Actually, that isn’t all that exciting; the vast majority of the work is getting the interface for camera in real world measurements (focal length and CCD dimensions in millimetres) into a format I can interchange arbitarily with opengl.

cheers
John