camera

if u dont feel like getting into the math behind it, use glulookat, gluperspective, etc. to generate your own matrices and stuff. otherwise, you''ll have to do the transformations, yourself. personally, i''d rather do as much possible by myself, and only pass the final transform matrix to opengl.

technically there is none. glulookat will set a modelview matrix, thats the inverse of the camera transformation, therefore every object you render after that will have its own transformations multiplied with this inverse. and the inverse is doing nothing else but moving objects the other way. regarding the math you are _always_ at 0,0,0 and looking down negative z.

and btw. i would avoid "doing as much as possible by myself" if that requires to do a lot of matrix math yourself. if you make opengl do the work you have the chance that its functions are highly optimized and that part of the work is done by the gpu.

though one approach that might be worth a look is storing all orientations as quaternions, adjusting the object quaternion depending on the cam quaternion where its a simple operation and then convert it to a matrix and load it. but i would profile both ways to see if the additional conversations are worth it.

I seriously think quaternion is one of the best ways to accomplish this task. I'm OpenGL fag, so if you direct3d, then I won't be much help.

I calculated, with quaternion, I get 37 multiplications(all angles of the qut) and 4 sin/cosines + transposing the matrix, where as rotating the pure matrix(the same way as rotatef in open gl) gives me 2 matrix multiplications that , 3 if I want all degrees of freedom and then the transposion and additionally the trig. This is totally un optimized, but probably as close as it gets. So if you are going to use pure matrix, you are better off doing it directly through opengl with rotatef.

One method is this:

camOrient.postMult(angleX, angleY, angleZ) //Optimized
camOrient.getMatrix(mat)


mat = mat*tra

glLoadMatrixf(mat);

where as using this one yields to all kinds of problems such as gimbal lock:
glRotatef(angleZ, 0, 0, 1);
glRotatef(angleY, 0, 1, 0);
glRotatef(angleX, 1, 0, 0);
glTranslate(position);


Another method would be constructing your matrix out of UVN vectors, which is basically what gluLookAt does, except that there is no point doing it so, since you are doing the matrix multiplication anyway in one way or another, especially if you are going to use rotatef.

I was wondering if there is any way to apply quaternion directly to rotatef instead of loadMatrix to get access the hardware acceleration. Besides OpenGL does much of the stuff in assembly so it is really wise to drop the stuff directly to opengl.

I haven't tried this exactly, but what would you have to do to the quat to get quats work with glRotate(quat.w, quat.x, quat.y, quat.z); This would remove the most expensive calls from you and give them to OpenGL, which could use the optimized methods to accomplish the given task?

Edit:
Too much coffee or not enough ritalin, you decide.

[edited by - Captain Goatse on May 2, 2003 4:13:43 AM]

(umm this is opengl forum, damn me)

You asked advatanges and disadvatanges, well here you go:

gluLookAt

Pros: really easy to set up and running and really easy to find decent tutorial www.gametutorials.com ahem ahem.

Cons: Does a lot of unneccesary stuff. Not that it only constructs the matrix, which you obviously have already and are going to need later, it also doesn''t give you an option to control all of the attributes.

identity and 3 times rotate and translate
Pros: Pretty easy to use. Gives you a lot of control.

Cons: Gimbal lock if you use eulers, which is most likely, because if you don''t things get complicated, which is you don''t want. Also fast, since you are using OpenGL commands.

Quaternion:
Pros: Simple once you understand it.
Cons: Hard if you don''t grasp it. A lot of different approaches around the net. Hard to find the one suitable for you. Also if you don''t know what you are doing, you can really slow things down.

quote:

---

Original post by m0n0n0ke
what are the advantages and drawbacks of theses 2 methods to handle the camera.

- using glulookat
- rotating and translating the objects around the camera position to make as if the camera was really moving.
...

---

Camera...does not exist! The ''camera'' is simply a way to move/rotate object to simulate a viewer.
In OpenGL there is only one matrix to compute object space coordinate (MODELVIEW).
gluLookAt create a MODELVIEW matrix in a way that is similar (I''m sure because it''s the fastest) to the method I''ve proposed here

http://www.gamedev.net/community/forums/topic.asp?whichpage=1&pagesize=20&topic_id=153283

As you can see to create a ''camera'' matrix you have only one matrix*vector mult and for an ''object'' matrix you have no multiplications at all.