   SceneGraph & Camera confusion
  I'm currently in an opengl crash course on my university and have been given the exercise to create an opengl scenegraph.up til now I thought of camera positioning as creating a matrix which everything you draw afterward will be multiplied with.So I thought the camera should be set up first and then the rest should be rendered.The problem here is, they want the camera to be a part of the scenegraph, in which every node does its job and clears the matrix using push/popmatrix.I currently have no idea how I'm supposed to do this.Any hints ?Thx   
  The View transformation (the one defined by the camera) is the last transformation to be applied to the objects before projection. This means all the objects should be inserted as children of this transformation. I personally think this isn't a great idea though (actually I don't like scenegraph in general).   ;  glPush/glPop doesn't clear the matrix, but duplicate the top element on the current matrix stack and remove the top element, resp. (Or do your push/popmatrix mean something else?)However, the matrix stack in question is the MODELVIEW stack. Its matrices are build asV * Mwhere V denotes the view matrix and M the model matrix. If the camera is integrated into the world like any other object, too, the correspondence between the "model" matrix of the camera and the view matrix is justV = C-1the inverse, where C denotes the said "model" equivalent matrix of the camera.Why is this the case, you're asking? Because of the model matrix describes the local-to-global space transformation. Applying it to the model means to "see" the model no longer in its own local co-ordinate space but in the global one. But the rendering should happen in the local space of the camera; that is for what the camera is good for. So you have to further transform from the global space down into the local space of the camera. Since the camera matrix is a local-to-global transformation matrix, you have to use its inverse for the global-to-local way.You can see that in the scene graph as well: You have to go from a Box (as a model) up to reach the ROOT, and then down to reach the Kamera node.[Edited by - haegarr on June 6, 2010 8:59:30 AM];Quote:Original post by haegarrglPush/glPop doesn't clear the matrix, but duplicate the top element on the current matrix stack and remove the top element, resp. (Or do your push/popmatrix mean something else?)I know, badly described by me.. I meant push before the transformation and pop after are used to store/restore the matrix, i.e. get back to the original after the work is doneQuote:Original post by haegarrHowever, the matrix stack in question is the MODELVIEW stack. Its matrices are build asV * Mwhere V denotes the view matrix and M the model matrix. If the camera is integrated into the world like any other object, too, the correspondence between the "model" matrix of the camera and the view matrix is justV = C-1the inverse, where C denotes the said "model" equivalent matrix of the camera.Why is this the case, you're asking? Because of the model matrix describes the local-to-global space transformation. Applying it to the model means to "see" the model no longer in its own local co-ordinate space but in the global one. But the rendering should happen in the local space of the camera; that is for what the camera is good for. So you have to further transform from the global space down into the local space of the camera. Since the camera matrix is a local-to-global transformation matrix, you have to use its inverse for the global-to-local way.I'm a little confused, I don't have any global coordinates, how am I supposed to get them ?I don't think I have a way to calculate the global coordinates first and then apply the camera.In fact, I don't have any control over which nodes are done first and which last.I think my main problem understanding this is that everything I do inside the camera node will be undone..the matrix calculated will not be applied to anything. so do I have to take the box nodes and find out where the camera is ?   ;  Just to make it clear: I second apatriarca's opinion about scene graphs.Quote:Original post by TTK-BanditI'm a little confused, I don't have any global coordinates, how am I supposed to get them ?Assume this way: glLoadIdentity() clears the current MODELVIEW matrix. On the stack:IStart iterating the scene graph in ROOT down the way to the red Box object. You cross the node Rotate y:45. This probably means glRotate(45,0,1,0). The top matrix on the stack now is the product:I * R(45,0,1,0)Next you hit the Translate node, what means glTranslate(-2,0,0). The top matrix becomes:I * R(45,0,1,0) * T(-2,0,0)Next you're rendering the red Box, using its mesh which is given in local co-ordinates. Due to the top matrix (as derived above) OpenGL transforms the local co-ordinates into global co-ordinates. So you actually have global co-ordinates in this situation.The problem is that the above computes the matrix M only, ignoring V totally (or, to be precise, using the identity matrix for V).Quote:Original post by TTK-BanditI don't think I have a way to calculate the global coordinates first and then apply the camera.You have, and here we come to the reason why an "OpenGL scene graph" make no sense IMHO. The smooth way would be to compute the global matrix yourself (i.e. using no GL matrix stuff for it)! Every serious approach would do so. However, the exercise is of a different meaning.Quote:Original post by TTK-BanditIn fact, I don't have any control over which nodes are done first and which last.Then you've lost. It is definitely necessary to compute V before rendering any visible object.One possibility is: You can iterate the graph, compute the global matrices (as shown above), store them, and link all renderable objects into a list. During iterating the graph you'll (hopefully) hit the Kamera, too. Compute the inverse of its matrix, push that as V using glMultMatrix, then iterate the list of renderable objects.Another (perhaps easier and more exercise aware) possibility is to look up the Kamera first, iterate its path bottom up and apply the inverse particular transformations until ROOT is reached. Then iterate the scene graph as usual. When coming to the Kamera again nothing special happens because the camera doesn't count to the renderables.Quote:Original post by TTK-BanditI think my main problem understanding this is that everything I do inside the camera node will be undone..the matrix calculated will not be applied to anything. so do I have to take the box nodes and find out where the camera is ?Undone? What do you mean?   ;Quote:Original post by TTK-BanditI think my main problem understanding this is that everything I do inside the camera node will be undone..the matrix calculated will not be applied to anything. so do I have to take the box nodes and find out where the camera is ?I think your problem was misunderstood. Just think about it, A scenegraph is a construct to place things into a world, not to set up rendering from a camera view. Using the scenegraph you place the camera into the world. If you traverse the scenegraph for rendering you will render the camera at the right place into the world(if you represent it with geometry) but you won't be viewing the world from the camera view.So ofcourse you first need too determine which camera you will view the world from. And then build the transformations by travering from the camera to root.This will ofcourse give you the camera matrix. And now you're set up to traverse the scenegraph to render the world.Hope it makes sense, I'm no expert but.;  Just to play devil's advocate for a sec, what do you do if you have multiple cameras in a scene? I'm not saying that the scene-graph is completely useless, but you may want to take a look at  this article  by Mr. Forsyth on the topic.   ;Quote:Original post by dudeman21Just to play devil's advocate for a sec, what do you do if you have multiple cameras in a scene? I'm not saying that the scene-graph is completely useless, but you may want to take a look at  this article  by Mr. Forsyth on the topic.Lets remember a scenegraph isn't about rendering although it can be used for that. It's about hierarchical transformations, and that is its purpose. I didn't read through Tom Forsyth but at the very first sentence he stated the scene graph as a "rendering method" which for me seemed odd, since it's just one thing the scenegraph can be used for.