Quote:Original post by Shamino
The thread was more dealing with the first question of yours..

The creation and destruction of complex objects, like your torch for example, either needs to be hard coded, or loaded in modularily.. With files, created with an Editor..

You could fill out a structure of object info yourself, instead of creating an editor which uses files, but this is where your engine might begin to come inflexible...

Yea, I am going to use files created from an editor (or hand). I figured that bit out, there is no other way to do it. Have you figured out anything with moving objects or re-parentable objects in your S.G.? Do you have your quadtree/octtree seperate or like the one I may do?

Well for geometry transformation I use a DOF node..

Something like this


One of these comes before any piece of geometry, or renderable data, that we have. It takes the transformation of the parent node, the transformation of the local node, and adds them together for a final transformation.

But do you mean like, say, Soldier A under terrain A moves to terrain B suddenly, now we have to move soldier A and all its children to be under terrain B?

This is a strange issue I havn't really dealt with yet..

Being able to do this would quickly make a lot of huge benefits, for instance, ruling out millions of polygons incredibly fast. You know your frustrum isn't looking at terrain 1, so why bother checking frustrum culls for anything on terrain 1?

And for your torch, lying on the ground it is relative to the terrain, when you pick it up its now relative to your hand... I'm thinking transfer ownership functions?

Quote:Original post by Shamino

But do you mean like, say, Soldier A under terrain A moves to terrain B suddenly, now we have to move soldier A and all its children to be under terrain B?

This is a strange issue I havn't really dealt with yet..

I was thinking keep the dynamic units out of the graph entirely (make thier parent the base node and do a quadtree cull), and make them have have thier own tree off them.. but then they would not have any data for collision, ect..

Quote:Original post by Shamino
And for your torch, lying on the ground it is relative to the terrain, when you pick it up its now relative to your hand... I'm thinking transfer ownership functions?

Yes this is what I was thinking, just re-assign the parent pointer the the Soldier, but then we will have a ever changing scene graph, which Sr_Guapo points out should be largly.

Would it be waise to partition them into a quad/octtree and then put them in that order, so when rendering, it can check bounds all the way doun until we finally get to the objects? or how could they be seperate?

Yeah, the scene graph is for everything, not just static geometry :)..

Quote:Original post by snk_kid
A quad/octree are not scene graphs well not in the typical sense and no scene graphs are not primariary used for storing static objects only, there meant to contain scene entities be it visible/renderable or not that means just about anything that is in the scene. I suggest spending sometime through this.

Wow! thats a great thread and needs to be stickied or put into a stickied graphics resource thread.

After reading a bunch of those links, I still have a problem with spatial org. If I use a quadtree, it is seperate from the scene graph, but it's leaves contain n pointers to scene graph data(such as objects, and terrain).

Quote:Original post by joanusdmentia
Let's consider your example, the person with the backpack. If the person isn't on the screen does that mean they're backpack isn't? No, it doesn't, the person may be just off the edge of the screen with the backpack still visible. In more general terms, just because a node in the scenegraph isn't visible DOESN'T mean that its child nodes aren't visible. This means that you have to traverse THE ENTIRE TREE in order to find out which objects should be rendered.

Ok, do I create the initial quad/octtree by recursivly going into the scene graph and checking the resulting position after every position node and placing it in the correct QT/OT node? Then if something moves ( such as a player with a backpack ), check it's new position and move it, and possibly its children in the quad/octtree? (this was my main question and seems closer to the correct answer then before)


But, seeing the advantages of render sorting would you make a scene graph for render states AND hierarchy and use them both? or, when rendering, would I insert the pointers to the objects that need to be rendered into a list, then iterate through the list looking for the same texture / shader / state(alpha), render and delete them from the list and then get a new type, and do this until the list is empty?

sorry for being the pest, but I think I am finally starting to get it [wink]

[Edited by - Valor Knight on March 4, 2006 6:05:26 PM]

Is this what it should end up looking like (there is a transform node in front of each node)?

Scene|-->terrain (the class instance - no need to worry about nodes - quadtree takes care of that)|        |---->Player|        |       |->backpack|        |       |->Weapon 1|        |       |     |->cool fx for weapon|        |       |->Weapon 2||        |----->Static object|        |         |----->Particle fx||        |------>torch (player pickupable object)|        |         |-->Fire fx|        |         |-->Smoke fx|        |         |-->light source

Quadtree|------>node 1|         |---->node 2|         |       |-->pointer list (pointer to player scene graph data so using render() would recursivly render all children of player as well)|         |       |--> Also in pointer list is static object||         |---->node 3|         |       |-->pointer list that stores pointer to torch node struct/class

Thus, if the player aquires the torch, then the torch gets re-parented to player, and the children of torch go with it.

Scene|-->terrain (the class instance - no need to worry about nodes - quadtree takes care of that)|        |---->Player|        |       |->backpack|        |       |->Weapon 1|        |       |     |->cool fx for weapon|        |       |->Weapon 2|        |       ||        |       |->torch (player pickupable object)|        |             |-->Fire fx|        |             |-->Smoke fx|        |             |-->light source||        |----->Static object|        |         |----->Particle fx

If the player moves around, it is solely on the quadtree to worry about.

Am I presenting this in a correct way now?

How would I sort for render states?

When rendering, would I insert the pointers to the objects that need to be rendered into a list, then iterate through the list looking for the same texture / shader / state(alpha), render and delete them from the list and then get a new type, and do this until the list is empty?