   ModelView Problems
  Hi Guys,Im having trouble understatnding the difference between Viewing and Modelling transformations using the ModelView Transformation.Viewing transformations should be made before modeling ones. Would appropriate code beglMatrixMode(GL_MODELVIEW);   //thengluLookAt(...);//set camera, thenglTranslate(..);    //translate to position to draw modelDrawModel();   //Draw model functionHow do I differentiate between translating the camera and translating models?I want to be able to:1. Move the camera around my model. &2. Move my model with a stationary camera.Thanks for any help given!   
Quote:Original post by CacksHi Guys,Im having trouble understatnding the difference between Viewing and Modelling transformations using the ModelView Transformation.Viewing transformations should be made before modeling ones. Would appropriate code beglMatrixMode(GL_MODELVIEW);   //thengluLookAt(...);//set camera, thenglTranslate(..);    //translate to position to draw modelDrawModel();   //Draw model functionHow do I differentiate between translating the camera and translating models?I want to be able to:1. Move the camera around my model. &2. Move my model with a stationary camera.Thanks for any help given!To move your camera around your model you will need to change the gluLookAt() parameters and you will most likely need to trig out the path you want to move around your model...to move the model just call gltranslatef() before you call your rendering code to display the model...Look into glPopMattrix() and glPushMatrix() and you will need to increment your xyz or whichever you need to move your model in the glTranslatef()   ;  Can u also use glTranslate etc to modify the camera postiion? If this is the case how do you distiguish between wanting to move either the camera or model?Before using gluLookAt() do I have to specify glMatrixMode(GL_MODELVIEW)?Thanks   ;  Think of the camera defining an origin and an orientation of viewing in the world. A model's co-ordinate frame is (for now) also given in the world (don't confuse this with the vertices of the mesh, since those are almost given in the local co-ordinate frame of the model).Since the screen should display not the origin of the world but what the camera "sees", you actually want the overall transformationmesh (or local) -> world (or global) -> camera (or view)Now, since the model is assumed to be given in global co-ordinates, you have to set-up the models co-ordinate frame as the transformation local->global. Now also the camera is (normally) given in the global co-odinate frame, so there is a transformation view->global. But due to the overall transformation mentioned above, you want the inverse, namely global->view.Next you have to consider that the first transformation you supply OGL with will be the last applied to vertices. Looking again at the overall transformation above, that means you first have to supply the global->view trafo, then the local->global trafo of the model. With V denoting the global->view (or in OGL terms the VIEW) trafo, and M denoting the local->global trafo (or in OGL terms the MODEL) trafo, and furthur considering that OGL uses column vectors, you getV * MNext, assume that a single trafo in use is build from rotation R and translation T (no scale for simplicity). You should apply rotation first, followed by translation, since otherwise rotation will simultanously also do a translation on an arc, what makes things weired. SoV * M = TV * RV * TM * RMwhere e.g. TV means the translation part of V, and RM similarly the rotation part of M.Now, considering that the camera C is defined by the inverse of V, you getV * M = C^-1 * M = (TC * RC)^-1 * TM * RMwhat is, under the given circumstances, identical toRC^t * TC^-1 * TM * RMwhere RC^t means the transpose of RC, and TC^-1 is the same as TC but with negated translation values. The both left terms together describe the VIEW matrix here, the both right parts together the (simplest form of a) MODEL matrix.So, writing in OGL, you have to do(1) glLoadIdentity(2) glRotate with inverse camera orientation(3) glTranslate with inverse camera positionfor the set-up of the VIEW matrix, followed by(4) glTranslate with the model position(5) glRotate with the model orientationNotice that this is the basic form. More sophisticated transformations are usual.EDIT: manual page says that gluLookAt is equivalent to glMultMatrixf(M); glTranslated(-eyex,-eyey,-eyez);where M is computed as rotation matrix from the given parameters. So yes, I assume that the matrix stack has to be already chosen, and also the identity martix should be loaded (but I don't know it surely). Notice furthurmore that the order of the both transformations gluLookAt does, and also that the eye point if negated. All this could be found in the explanation above, too.   ;Would I first write: glMatrixMode(GL_ModelVIEW):thenHow do I specify I want to move the camera here?(1) glLoadIdentity(2) glRotate with inverse camera orientation(3) glTranslate with inverse camera positionfor the set-up of the VIEW matrixHow do I specify that I want to move the model here?(4) glTranslate with the model position(5) glRotate with the model orientationThanks!   ;Quote:Original post by CacksglMatrixMode(GL_ModelVIEW):You should switch the MODELVIEW matrix on if it isn't the current matrix. Normally it _is_ current (if the rest of code is written correct), but you could switch it on there to be sure.Quote:Original post by CacksHow do I specify I want to move the camera here?(1) glLoadIdentity(2) glRotate with inverse camera orientation(3) glTranslate with inverse camera positionfor the set-up of the VIEW matrixYou don't need to specify this. Imagine this: After the total set-up of the matrix (say both the VIEW and the MODEL part) you push geometry in form of vertices to OGL. As soon as a vertex is supplied, OGL transform that vertex by the set-up transformation matrix. That could be written like this:p' := C^-1 * M * p = MODELVIEW_MATRIX * pwhere p is the original (i.e. model local) vertex position, and p' the transformed one, say in view co-ordinates. As you can see here, there is no special need for OGL to distinguish between the VIEW and the MODEL part, and hence there is no need for you to specifiy that the first matrix is the VIEW matrix. In other words, only the fact of how the math is applied and that you supply the C^-1 matrix first (making them to be applied last) makes it implicitely the VIEW matrix.This behaviour of OGL is often confusing first, but you'll see that stuff is ok.   ;  Appendix:Quote:Original post by CacksHow do I specify I want to move the camera here?(1) glLoadIdentity(2) glRotate with inverse camera orientation(3) glTranslate with inverse camera positionfor the set-up of the VIEW matrixPlease notice that this _does not_ move the camera! Instead it instructs OGL to reflect the effect of a (rotated and) translated camera! I suggest you to make a strict distinction of these things. Track the state of the camera like any model in your data set. When its time to render, supply the local transformation to OGL. You should avoid to use OGL to track a transformation state for you if possible.   ;  So is the camera position determined by the first transformations as transformations are performed in reverse order?Also is this the correct format for rendering:1. ModelView transformations2. Projection transformation3. ViewPort transformationor are these meant to occur in the reverse order?Thanks!!   ;Quote:Original post by CacksSo is the camera position determined by the first transformations as transformations are performed in reverse order?Also is this the correct format for rendering:1. ModelView transformations2. Projection transformation3. ViewPort transformationor are these meant to occur in the reverse order?Thanks!!You are correct. In the rendering pipeline for OpenGL a vertex transformed in that order. Normally though, you only need to set the Projection matrix and the viewport once (upon initialization). Your main concern in rendering is the modelview matrix.   ;  Some different ways to look at it:No, their is no absurd "first transformation applies to camera" system that would only make it a pain to work with and confuse people. The easy explanation is that there ISN'T a camera. Your view point will always be the origin and you will always be looking down negative z. All you can do is to PRETEND that there is a camera by moving everything else in the opposite way. To make life easier you can treat the camera as an object and setup the modelview with the cameras inverse transformation, which means nothing but "transform everything coming after that in the opposite way".I would also advice to NOT use the "OpenGL is doing everything backwards" point of view, as it will just confuse the hell out of you when you start pushing and popping the matrix a lot. All transformations are done in local space and applied to the current modelview (ie. they create a transformation matrix and multiply it to the current modelview). Now the fun part is that if you have transformation T and modelview M, multiplying it one way applies it in local coordinates and the other way uses global coordinates. Order matters, and if you apply T "after" M it will be based on M (which is the sum of all previous transformations), but if you apply it "before" M it uses the unchanged coordinates (ie. global). If of course it is really making it a lot easier for you to think in world space, then the consequence is that you can pretent it is all happening in reverse order.Might be less confusing in D3D, where you have to manually create and multiply the matrices and can decide on the order yourself. But OpenGL is doing a new transformation AFTER previous ones, which especially means that if you first rotate and then translate the translation will use different axes than it would have before the rotation. Think of every "object" to have its own coordinate system and that everything you do is using the objects coord system and NOT the world coord system. Some nifty images might help to explain, but lacking nifty images all I can say is that this is good and neat. An objects "forward" (depending on how you modelled it, let's just say the z axis by default), will always be the objects "forward", no matter how much you move and rotate it around. You don't need to figure out which way an object is facing, if all you want to do is move it forward. You can stubbornly glTranslate(0,0,speed) (or could, as usually you want to know where it ended up and "asking" OpenGL all the time isn't exactly efficient).   