   Uhm, is this a scene graph?
  This is Psuedo code, duh.world.load("world.x")scenegraph.attachChild(world)planet.load("planet.x")world wd = scenegraph.getObject("World")wd.attachChild(planet)//later onworld wd = scenegraph.getObject("World")wd.move(0,100,0) //WOULD THIS MOVE ALL CHILDREN UP TOO OR SUPPOSE TO//later on, renders allscenegraph.renderWould this be an example of how you could use a scene graph to load objects and store then, then retreive them and do stuff to them??? Everyone shows how to build a scene graph, but not how to use them when your done. I need to see the end product to go backwards.ThanksJeff. 
Yea, bud id say if you were gona move them manualy like that then get their pointers all at once or something, not everytime u move them. I would attack a controller to the entity so pritty much your game is like: scene.update()  scene.render(); ;  hey, may as well post this why its on topic.... i havent used scene graphs b4 because i dont see how you can use them to sort your scene by state changes?if there are any links to tuts on this i would love to hear ;root    tex1  tex2  tex3light nolight   light nolight   light nolightobj1  obj2 obj3  obj4 obj5  obj6;  what about if a model uses 2 textures to be rendered?and how would you determine which way your object goes through your tree, you can just say if this texture > this texture, go to left node can you?edit: are there any simple scene graphs with code i can look at? this looks intresting... i usueally just sort by material/texture then add my objects to a list, this resulted in poor performance with dx9   edit2: hrmm okay i did some reading, they make sence. The only thing i dont know how to do is insertions? sure you can insert via material/texture/light nodes etc... but what if you want this part automated? for example in my engine i would say:- load this model, and insert into scene graph?[edited by - supagu on February 11, 2004 6:13:24 AM] [edited by - supagu on February 11, 2004 6:52:33 AM];quote:Original post by supagu  what about if a model uses 2 textures to be rendered?then the two parts of the model end up in different leaves, though with current machines, 4-8 tex units and stuff your average model really shouldnt need to changes textures that often.quote:and how would you determine which way your object goes through your tree, you can just say if this texture > this texture, go to left node can you?just the way you travers through every kind of tree. if you want a comfortable method (meaning: comfortable to program but not the maximum in efficiency), make sure all states can be expressed as a number and use the fact, that stl::map will create a new entry when you access a non existing index.struct node {  map ChildMap;};ie: current_node=current_node->ChildMap[obj.texID];will always work, no matter if its the first object using that texture or not. your current depth in the tree would then automatically be a certain type of state (blending, lighting, etc.) and placing the most expensive states as far up as possible should do the rest. of course, some kind of list with the "price" for different state changes in opengl would be handy. ;  so i could also give my nodes a weight?for example a node that sets a texture has a higher wait then a node that sets a material, and use that to insert into my scene? then i only need to figure out how to figure this out...maybe have a SceneMesh class, which has a list of SceneNodes sorted by weight, then when i insert into the scene, it takes the highest weight node, and uses it to insert, then takes the second node etc... until the mesh is in its proper locationwould a primary texture have a higher wight than a secondary texture, to make sure we sort by primary texture first?then i only have to worry about file formats? and shaders?   [edited by - supagu on February 11, 2004 7:06:45 AM];  hmm.. i never mentioned a weight for the nodes. their level in the tree should depend on their cost and all nodes on the same level would be the same state, so you can traverse the tree and know that after 4 steps the numbers describe the state of alpha test or whatever.but i guess checking out scene graphs in other projects might be more reliable than my thoughts on it. after all, things like transformations wouldnt really fit well into such a tree. ;  Hmm, remember guys, a scenegraph is meant to be a purely logical representation of a scene. It is meant to show the logical connections between all the different entities/meshes/nodes/whatever they''re called in your engine. For example, if you had an NPC wandering around, you would attach it to the root(world) node. If the NPC was holding a sword, you would attach the sword to the NPC, if the sword had blood dripping from it, you would attach the particle effect to the sword. The scenegraph should not be directly used to sort entities for anything other than the logical connnections they share. Alpha, shader, state, etc, sorting should be performed as a seperate prerender process once visible geometry has been determined.In answer to the OPs question, you''re on the right track with your example. Basically you have a base class from which your entities (world and planet in your case) are derived from. You can then either have the scenegraph functionality provided by the base class, or you can create a seperate scenegraph structure with Node classes and have them contain pointers to your entities. To render you would traverse the scenegraph by visiting each nodes children, starting with the root node, and call their render functions. The render function would push a local transformation matrix on the scenegraph matrix stack, render the entity, call it''s childrens'' render functions, and then pop that matrix.Hope this helps!Kyle;  Here''s the bit I dont get, and have never gotten.  I must be a ''tard.   Kyle and Trienco described the use of a scene graph from different, conflicting I think, directions.  Kyle uses it as a way to arrange coordinate systems into a hierarchy, and traverse it to create world concatenated world matrices.  Trienco uses it to arrange items by texture, and traverse it for the sake of saving render state changes.I often see both descriptions of scene graphs, but surely both cant be right?  If I am missing something, please educate me... even if it''s just that different people use a ''scene graph'' for different things. My own muddled mind can only make sense of it in 1 way: to have both uses at once!  I.e. build your ''scene graph'' sorted on texture, but also having each object know of it''s hierarchical parents and children.  Then traverse the hierarchical tree first, calculating and caching a world matrix for each object... then traverse your render state tree and output each object with it''s cached world matrix, with as few render state changes as possible.  This is based on render state changes being more expensive by far than changing the world matrix.How far off the mark am I?Atlay 