   Scene graph in relation to model
  How should the scene graph be used in related to the internal model of the game? Is it possible to use the MVC system in combination with scene graphs?- memory management: should the scene graph or the model allocate and delete data or just hold pointers?- storage of non-render related data: for objects that need other data than just mesh, texturing and a world matrix for position and rotations (say some AI related data) how would the storage typically work? Should I have a list of model classes storing all data and then have pointers to the matrices of these classes in the scene graph? Or should I send (copy) the data to the scene graph every rendering frame? Or should I have an object with a pointer to the scene graph node where it's graphical representation lies?- manipulation of non-render related data: if I store 100 projectiles in the game world, and want to move all of them one step during a frame, and test if they're out of fuel - say it's a self-propelled rocket projectile - where would these tests typically be kept, and where would the extra non-render-related data be kept for a logical and practical structure? Should this animation be within the 100 scene graph nodes for the projectiles or should I keep the projectiles in separate classes and manipulate/animate them there, while the pointer in the scene graph remains constantly pointing to the matrices within those objects?- if I have a geomipmap based landscape render system, should I really include it in a scene graph or should I have it in a separate system, for example a single class that holds a heightmap and the vertex buffer pointers and takes care of the drawing?- is it customary to sometimes have multiple scene graphs to solve complex problems? For instance a geomipmapping system works much like a scene graph, could I then use the geomipmap system as one scene graph and another scene graph containing the characters moving around within the landscape?- for special effects, say water with a reflection and refraction, it's necessary to do multiple render passes for it to work. How would such a thing fit into a scene graph system? Because in order to get the reflection in the water surface, the entire scene including nodes above would need to be rendered again, and for instance the camera position would need to be different for the reflected image render pass, so should for instance water effects really be kept in a scene graph structure or should it be done outside of it?[Edited by - all_names_taken on June 18, 2006 9:19:33 AM]
  Okay, I'll answer what I can, or what I think I can, and then someone else can just fill in the blanks or tell me that I'm wrong. [smile]Quote:Original post by all_names_taken- memory management: should the scene graph or the model allocate and delete data or just hold pointers?It shouldn't be allocating or deallocating memory at all. It should just hold pointers to the objects.Quote:Original post by all_names_taken- storage of non-render related data: for objects that need other data than just mesh, texturing and a world matrix for position and rotations (say some AI related data) how would the storage typically work? Should I have a list of model classes storing all data and then have pointers to the matrices of these classes in the scene graph? Or should I send (copy) the data to the scene graph every rendering frame? Or should I have an object with a pointer to the scene graph node where it's graphical representation lies?You should keep all data related to an object in the object. You don't really want the scene graph to be aware of the actual matrices of an object it contains. You should probably just have a couple of functions for every node in the graph like "preRender", "render" and "postRender". In either the "preRender" or "postRender" function, you'll generally have some sort of update happening if the node is animated, and in the "render" function you should be applying the transformations of the object, setting any material states you need (lighting, textures, special ultra cool parallax maps, whatever), and then drawing it. I have those three functions for my scene graph as well, so whenever "preRender" for the scene graph is called, it goes through the whole scene graph and calls "preRender" for every object, and the same for "render" and "postRender." But for "render" before it calls "render" on the object, it pushes a matrix onto the stack and after it returns from render, it pops it off again. This is so you can ensure the transformations are being done in the space you think they're being done in.[edit]I have a VideoDriver object, which is basically where all the calls for the graphics API are. So, whenever I need to set a transform I do a call like so:m_videoDriver->transform(WORLD_MATRIX, objectTransformMatrix);That way, I don't need any outside classes to need to be aware of the particular matrices for each object, I just have the object do it, so I could change everything to use Quaternions for rotation internally, and I wouldn't have to change the interaction code between the scene graph and the objects.[/edit]Quote:Original post by all_names_taken- manipulation of non-render related data: if I store 100 projectiles in the game world, and want to move all of them one step during a frame, and test if they're out of fuel - say it's a self-propelled rocket projectile - where would these tests typically be kept, and where would the extra non-render-related data be kept for a logical and practical structure? Should this animation be within the 100 scene graph nodes for the projectiles or should I keep the projectiles in separate classes and manipulate/animate them there, while the pointer in the scene graph remains constantly pointing to the matrices within those objects?You should really be keeping that info inside the part of the app that is not dedicated to graphics. So, you'll have a high level loop which will look something like this:while( game->running() ){scene_graph->preRender( time->getTime() );scene_graph->render();scene_graph->postRender();game->run_game_logic();game->run_physics();}Something along those general lines. The 'game' object will keep all the objects in different data stuctures, and that will do all the checking and implementing should a game object have to be created or killed. The scene graph is simply there so all the objects are rendered correctly in regards to their transforms.Quote:Original post by all_names_taken- if I have a geomipmap based landscape render system, should I really include it in a scene graph or should I have it in a separate system, for example a single class that holds a heightmap and the vertex buffer pointers and takes care of the drawing?No idea.Quote:Original post by all_names_taken- is it customary to sometimes have multiple scene graphs to solve complex problems? For instance a geomipmapping system works much like a scene graph, could I then use the geomipmap system as one scene graph and another scene graph containing the characters moving around within the landscape?I imagine it's possible. I haven't ever thought of this, or heard of this, but then, I'm relatively new to graphics (a little over a year and a half).Quote:Original post by all_names_taken- for special effects, say water with a reflection and refraction, it's necessary to do multiple render passes for it to work. How would such a thing fit into a scene graph system? Because in order to get the reflection in the water surface, the entire scene including nodes above would need to be rendered again, and for instance the camera position would need to be different for the reflected image render pass, so should for instance water effects really be kept in a scene graph structure or should it be done outside of it?If you set up your scene graph so all it does is render during the "render" function and doesn't do any updating of anything at all, then this becomes a little easier.For my engine, during the "preRender" call, each object will register for any special rendering it needs done, such as reflections, with the VideoDriver object (which contains all the functions to interface with the graphics API). Then when it comes time to render, it will have a list of objects that need to have reflections rendered onto them. So, it will set up some states, render the scene once for that object, set up some states, render the scene for the next reflective object, etc, etc, until no more reflective objects need to be rendered. Then onto the next special rendering category, and so on, and so forth. Then the last thing I do is render the scene normally. I've only really just started with this and don't know how it will work out, but it seems to be okay so far, and I think that I'll get quite a ways with it until I decide if I need to change it.   ;  I actually use a system very similar to Endar's but I will say that I do the rendering slightly different when it comes to special effects, etc. (although I did try his approach). Generally the way I see it, the scene graph has no idea how to render these things in terms of special effects. Instead what happens is that each individual object knows what calls it needs to make to the VideoDriver object. However I give each object a pass number (render this on pass 0, pass number 1, etc.). The scene graph sorts them, lets each object call the appropriate things, and then renders them.The main downside of this approach is that when I need multiple passes of an object I need multiple objects pointing to the same data. As such I have a mesh class which is held by 1 or more actor classes, which are then held and sorted by the scene graph. It works well if I need to use non-render related data as I can just have the actor deal with it, not the scene graph (the scene graph should never be in charge of that stuff as far as I'm concerned, its only there for rendering). I like this approach but then again I'm odd like that.   ;Quote:Original post by all_names_taken- memory management: should the scene graph or the model allocate and delete data or just hold pointers?The scene-graph should only deal with the high level objects. It doesn't tneed to know if a node is a particle syatem or an animated model.Quote:Original post by all_names_taken- storage of non-render related data: for objects that need other data than just mesh, texturing and a world matrix for position and rotations (say some AI related data) how would the storage typically work? Should I have a list of model classes storing all data and then have pointers to the matrices of these classes in the scene graph? Or should I send (copy) the data to the scene graph every rendering frame? Or should I have an object with a pointer to the scene graph node where it's graphical representation lies?You need to have higher level classes that contain this information. It may be several layers down from a "model" object that you have the vertex data, etc.Quote:Original post by all_names_taken- manipulation of non-render related data: if I store 100 projectiles in the game world, and want to move all of them one step during a frame, and test if they're out of fuel - say it's a self-propelled rocket projectile - where would these tests typically be kept, and where would the extra non-render-related data be kept for a logical and practical structure? Should this animation be within the 100 scene graph nodes for the projectiles or should I keep the projectiles in separate classes and manipulate/animate them there, while the pointer in the scene graph remains constantly pointing to the matrices within those objects?I have a similar rendering system to endar. There needs to be a seperation between the low level data and eneral game mechanics.Quote:Original post by all_names_taken- if I have a geomipmap based landscape render system, should I really include it in a scene graph or should I have it in a separate system, for example a single class that holds a heightmap and the vertex buffer pointers and takes care of the drawing?What is the point of having a scene graph if only "some" of the scene data is there? If the terrain implementation is similar to a scene graph, it should fit into it very well. Derive a new scene node and call it a terrain node.Quote:Original post by all_names_taken- is it customary to sometimes have multiple scene graphs to solve complex problems? For instance a geomipmapping system works much like a scene graph, could I then use the geomipmap system as one scene graph and another scene graph containing the characters moving around within the landscape?I am sure it is possible, but what is the point? The entire reason for a scene graph is to hold all of your scene data in a simple, manageable structure.Quote:Original post by all_names_taken- for special effects, say water with a reflection and refraction, it's necessary to do multiple render passes for it to work. How would such a thing fit into a scene graph system? Because in order to get the reflection in the water surface, the entire scene including nodes above would need to be rendered again, and for instance the camera position would need to be different for the reflected image render pass, so should for instance water effects really be kept in a scene graph structure or should it be done outside of it?Again, I have a similar method to Endar's. I perosnally have a seperate structure to hold the render data. This allows me to call "render" on an object and have it be placed in the RenderGraph, which sorts the objects by how they need to be drawn.   ;Quote:Original post by all_names_taken- is it customary to sometimes have multiple scene graphs to solve complex problems? For instance a geomipmapping system works much like a scene graph, could I then use the geomipmap system as one scene graph and another scene graph containing the characters moving around within the landscape?There is a case for multiple scene graphs, but it works differently from what you think. This paper describes one such approach. I'm new to gfx also so don't hold me responsible :), but I think the basic idea is that game objects live in a flat structure ("object soup"), and you then have multiple scene graphs (tree, octree, bounding volumes, whatever) tailored for specific functionality referencing these objects. For instance, a spatial graph could be used for proximity ai (mob shouting "help! being attacked!"), collision detection, and culling, a multi-semantic view could be used when it makes sense (maybe propagate ai, or destroy all rockets in the scene) and a state-sorted graph could be used for rendering. This supposedly addresses the problem of overloading the scene graph and slowing it down and also avoids having to state-sort all your objects dozens of times per second since a model's material/shader state does not generally change all that often. On the other hand this introduces some complexity into your node management code.   ;  Thanks for the replies, I think I've figured out most of it now, though special effects are still a bit tricky :)   ;  Personally, since I use scenegraphs to organize my objects in many different ways(rendering,physics,semantics), I use something I call "SuperNodes". A SuperNode encapsulates an entity(a game object) and an arbitrary number of Views. The Views in turn have a "children" list that points to other SuperNodes. So, a SuperNode can have a group of children with respect to RenderView, and a completely different group of children with respect to PhysicsView. Also, Views encapsulate a number of events, like OnUpdate(), OnAddChild() and such, that when triggered call a user-defined functor which usually(not always) manipulate the entity is some ways. When I call node.view[ViewID].Update(), the graph is traversed with respect to view ViewID, and the OnUpdate() is called for all of them. The user in OnUpdate() may or may not choose to stop the traversal. For example, a node may choose to get all of its children, munipulate their entities itself, and stop the traversal there.That way, I have all the info about the hierarchy in any time. When "inside" one particular view, you can access the Supernode and, in turn, the entity and all other views of the SuperNode. So, while updating the Rendering View, one can inspect the Physics or Semantics view easily, if one was so inclined.   