damn the matrices!!

hi everyone, i’m trying to implement a camera, and i understand how to use the glMultMatrixf function to translate and rotate, and squish objects…but i’m not clear on how to use it with a vector?? i’ve read a lot about using it with vector multiplication, but i don’t understand exactly WHAT it does…(if anything). is it commonly used?? any info would be very helpful, thanks.

also, can someone explain please what the advantage is of using the matrix operations to move the camera rather than just translating the entire scene with glTranslatef and glRotatef?


a couple of advantages
a/ no gimbal lock problems
b/ only one operation ‘multmatrice’ instead of a few ‘translate and rotating’

your best bet would be to use gluLookAT

Hi Zed,

nobody told me about the damn gimbal lock. been spending 3-4 days on a simple rotation, but couldn’t get it to work.

do I have to use glLookAt to avoid the gimbal problem? I have found a work around to premultiply the rotation matrices

push matrix
load matrix m
glRotatef (x…
glRotatef (y…
glRotatef (z…
save matrix to m
pop matrix
multiply matrix by m

this essentially multiplies my matrix as following

m * Rx * Ry * Rz * m

which cause my object to appear half the size…(no biggy)

but I understand this is very inefficient (specially reading matrix values off the vid card is VERY VERY slow)

do u think I can just use the rotation matrices and multiply them by hand and not use glLookAt? if I need to use glLookAt, can u give me some tips?

Much appreciated,

Why are you even multiplying the matrix in the first place?? I don’t see the point of doing it the way you are.

What does m contain when you first load it?

You don’t need to use glLookAt, since that does all the loads/multiples for you. (up,eye,front-- or whatever the order is)

Oh, and if you want to know how to use vectors, look at the 80+ topic on glmultmatrix on this board… I don’t know how you missed it.

[This message has been edited by Elixer (edited 01-31-2001).]

I’m sorry, Elixer, but gluLookAt does not do all the stuff for you. You must rotate the “camera” matrix first so that you send the valid “look at” values to gluLookAt. There’s no possible way to use gluLookAt to rotate the matrix for you. So, if you want to take advantage of T&L, you have to do the following (psudocode):

// and only NOW do we have the values to pass to gluLookAt

Ofcourse, you could do this slightly differently and not use gluLookAt and instead just multiply the modelview matrix with our matrix. But in either case, you have to load the matrix in and rotate it and translate it and then get it back. Otherwise, what the heck do you send to gluLookAt unless you’re doing some kind of pre-hardcoded camera thing???

Woah. You do not want to do that Punchey. gluLookAt quite easily constructs a view matrix, and post multiplies the current matrix (which should be the modelview matrix) by it.
From MSDN:
The gluLookAt function creates a viewing matrix derived from an eye point, a reference point indicating the center of the scene, and an up vector. The matrix maps the reference point to the negative z-axis and the eye point to the origin, so that when you use a typical projection matrix, the center of the scene maps to the center of the viewport. Similarly, the direction described by the up vector projected onto the viewing plane is mapped to the positive y-axis so that it points upward in the viewport. The up vector must not be parallel to the line of sight from the eye to the reference point.
Once you have the modelview matrix set either by using discrete transformations or gluLookAt, you can then do the discrete transformations for the objects within the scene. The values you pass to gluLookAt should be quite easy to come by, one is the direction you want the camera to look, another is the position of the camera, and the final value is the up vector and is normally a constant.

Assuming you track camera location in world coordinates, and track your viewing vector/orientation vector as unit vectors, you should be able to:

gluLookAt(cameraX, cameraY, cameraZ,
cameraX + viewX, cameraY + viewY, cameraZ + viewZ,
upX, upY, upZ);

… and be done with it. No?

– Jeff

[This message has been edited by Thaellin (edited 01-31-2001).]

Rizo: If you need to do matrix math, it would be wise to create a matrix math library. That will be much faster than trying to use OpenGL as a math library, which it is not.


using the matrix lib already…here is what our prof told us

Screen <- [World Centred transformation][model_view_matrix][Body Centred transformations] <- P

where P is the point in the 3D coordinates and Screen is what we see (ignorning other matrices). To do Body Centred Rotation, we should multiply the matrices on the right of [model_view_matrix]. to do world centred rotations (eg, trackball) we should multiply the rotation matrix on the left of [model_view_matrix]. Eg, after a trackball rotation the above looks like this

screen <- [T][model_view_matrix] <- P

and if I do a body centred x-rotation, then it looks like this

screen <- [T][model_view_matrix][Rx] <- P

and if I do a World centred y-rotation then

screen <- [Ry][T][model_view_matrix][Rx] <- P

I’ve been trying this out…but doesn’t work, perhaps I haven’t implemented it correctly.

I should say that, it seems that even you experienced guys are confused about all this rotations so many conflicts I don’t know whom to trust.


DFrey, Yes, I DO want to do that. I am right and your quote proves it. gluLookAt does not give you your up vector, front vector, or position information. You have to SEND those things TO gluLookAt. Therefore, gluLookAt DOES NOT do EVERYTHING for you. Sure, it sets up the modelview matrix for you but only AFTER you have supplied it with elements from your camera matrix. Therefore, you must still manipulate your camera matrix using rotation and translation operations BEFORE using gluLookAt. This is all I was saying. I never said that gluLookAt didn’t give you a fully translated and rotated modelview matrix. But it sure as hell does not give you a camera matrix that describes the orientation thereof.

gluLookAt creates a fully translated and rotated modelview matrix. Just grab the source for Mesa3D and see for yourself. In there, you will find two gl-commands: glMultMatrix, which does the rotation, and glTranslate, which does the translation.

You are correct, gluLookAt does not give you the upvector, front vector and any other information. But that is completely unecessary, since you already know them.

If you want the viewpoint at A, looking at B, you just put the proper arguments into gluLookAt, and it creats the necessary information for you, so that the modelview matrix is currently located at A, looking at B. Of course, the upvector is, as DFrey said, mostly constat, so that was not mentioned. But since it’s constant you know it.

gluLookAt(10,0,10, 0, 0, 0, 0, 1, 1);

The above code will generate a modelview matrix, that is located at (10, 0, 0), will be rotated so that it is looking at the origin, and view of the origin will be slightly roleld aswell because of the upvector. No magic involved with manual rotations/translations, and other mathematical tricks. Can it be easier?

Are you really sure you know what gluLookAt actually does and how it works? Try read the Red Book…

Thanks Bob.

Punchey: What I’m saying is that regarding the up vector, front vector, or position information, you generally should already have that information to give to gluLookAt. You should not need to get that info by reading the matrix back from OpenGL (generally a slow thing to do).

And in case your viewpoint is attached to some hierarchy, in which case some translations and rotations may be necessary, do that with your own matrix code. Do not use OpenGL as a math library. That is, if you are interested in maximum performance.

[This message has been edited by DFrey (edited 02-06-2001).]

Yes, Bob, I know exactly what gluLookAt does and your questioning me as much is not appreciated. Sure, you can simply use straight values or values not pulled from a matrix. But, as has been stated, using those values, you must generally assume that the up vector is constant. And, in many cases you can safely do this. However, there are also a GREAT many cases in which you DO NOT want to do that. And, more and more nowadays, you don’t want to do that at all. In most modern game development cases (particularly FPS-type games such as shooters and flight sims), you want the camera to be attached to a object in the world. Sure, you don’t HAVE to use a matrix, but it’s a very nice thing to do in MANY instances. And that’s why using a camera/object matrix is a very easy way to go about doing things. And so I maintain that gluLookAt DOES NOT magically do everything for you. Yes, it creates a modelview matrix for you given the front, up, and position. But you have to supply those values to it and therefore, in the vast majority of circumstances, there is still more work to be done. e.g. rotating and translating the camera. Sometimes not.

As for it being slow to read a matrix back into OpenGL, I think you might be the one who doesn’t understand how gluLookAt works. All you have to do is a:

Now how slow is that? How is that any slower than anything else?

[This message has been edited by Punchey (edited 02-06-2001).]

Always when these cases happen, Punchey, I simply do it all myself. I only use glu functions if they perfectly fit into my problems.

That’s another way of going about it.

No Punchey, it it not the indexed addressing of the matrix that is slow. It is getting the matrix from OpenGL using glGetFloatv, that’s the performance issue I’m speaking of.
You are using OpenGL as though it were a math library, which in general, is a bad thing to do. And again, the only time I can see you needing to use any matrix math to get any of the vectors for gluLookAt is if the camera is attached to some member of a hierarchy (except the root). Otherwise, as in almost all shooters and sims, you already know precisely where the camera should be and how it should be oriented.

[This message has been edited by DFrey (edited 02-06-2001).]

I agree with Punchey, you still have to supply the info to gluLookAt, and if the camera is bound to a model then what’s the best way of doing the model translation/rotation? I’ve heared that the glGet* function is slow but it’s either that or doing your own matrix math, which is better? OR is there another way to do this whole thing?

remember the model is walking/flying around not a specific point looking at another specific point.

remember the model is walking/flying around not a specific point looking at another specific point.

I think quite the contrary. A model has a origin (i.e. a specific point), and is looking in the forward direction at any point along the forward direction. Just take the forward view vector and add it to the model’s origin (plus another vector for camera offset if needed) and that is a good point to send to gluLooAt, and the up vector is still just a constant. No extended matrix math is necessary to do that.

[This message has been edited by DFrey (edited 02-06-2001).]

so then DFrey how would you do the rotation for the models view vector? would you use openGL, or homemade vector math?

To rotate the view vector, I would definately use a math library, not OpenGL. To rotate the model, I would use OpenGL. I’d even track the OpenGL modelview matrix with my own, if for some reason, I needed to access the matrix, I can get the info from the copy without resorting to glGetFloatv. Of course, I’d only go to that length if I needed such access many times per frame.

[This message has been edited by DFrey (edited 02-06-2001).]