• 15
• 15
• 11
• 10
• 9

# Scene Graphs and Rendering Them

This topic is 4884 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Karate Chop *POW* ok, so i've been trying to get something on paper in terms of design for an engine i'm planning on building. i was wondering, is it a good idea to do actual rendering when a scene node's render function is called? what i mean is do i actually execute the API commands? what i am used to doing is when a render function is called i add the scene node's mesh data, vertbuffers etc. and all its info, such as materialID(shader), transform matrix etc etc to what i like to call a Render-Graph (RG), then once the RG is formed i do a one-time scene flush where the actual low-level rendering commands are called. the advantage of this is it seperates the scene-graph from the rendering and it also alows for a well sorted RG (node insertion into the RG is sorted, this sorting is controled by zbuffer state and shader/texture id) is this a good idea??? something inside me _really_ wants to do this, but will it be too slow? also, im having a little trouble trying to figure out where to draw the line in terms of where to stop with scene-node granulity. eg. do i want this:
Root
|
+---- Player: ISceneNode
|
+--- Gun: ISceneNode
|     |
|     +--- Mesh: ISceneNode
|     |
|     +--- MuzzleFlash: ISceneNode
|                |
|                +--- Mesh: ISceneNode
|
+--- Model: ISceneNode
|
+--- Mesh: ISceneNode

do i want everything that works with the engines internals to be a scene node or do i want the Meshs to be members of the Player entity, rather than actual Scene Nodes? eg.
Root
|
+---- Player: ISceneNode
|
+--- Gun: ISceneNode
|     |
|     +--- MuzzleFlash: ISceneNode
|
+--- Model: ISceneNode


Cheers -Danushka PS. Malcolm, feel free to jump in if you see this one

##### Share on other sites
Quote:
 Original post by silvermacei was wondering, is it a good idea to do actual rendering when a scene node's render function is called? what i mean is do i actually execute the API commands?

I would say no, a scene graph is a little inefficent for direct rendering as it is, you'll most likely wont to iterate the scene graph/s in a couple of passes, on the way down frustum culling, concatenation of transforms, grouping & sorting render state, on the way back up updating bounds.

Quote:
 Original post by silvermacewhat i am used to doing is when a render function is calledi add the scene node's mesh data, vertbuffers etc. and all its info, such as materialID(shader), transform matrix etc etc to what i like to call a Render-Graph (RG), then once the RG is formed i do a one-time scene flush where the actual low-level rendering commands are called. the advantage of this is it seperates the scene-graph from the rendering and it also alows for a well sorted RG (node insertion into the RG is sorted, this sorting is controled by zbuffer state and shader/texture id)is this a good idea??? something inside me _really_ wants to do this, but will it be too slow?

hmm.. this sounds fimillar, did you get the idea from this? i don't know of anyone doing this except i think java3d does for its internal representation but as you may or may not know java3d is more general graphics api than a graphics engine for a game.

Quote:
 Original post by silvermacealso, im having a little trouble trying to figure out where to draw the line in terms of where to stop with scene-node granulity.eg. do i want this:Root | +---- Player: ISceneNode | +--- Gun: ISceneNode | | | +--- Mesh: ISceneNode | | | +--- MuzzleFlash: ISceneNode | | | +--- Mesh: ISceneNode | +--- Model: ISceneNode | +--- Mesh: ISceneNode

just a slight change:

class hierarchy:
     Bounds        |   BoundingSphere <- - +                       |                       | //<------ Aggregation, has-a (this gives a sort of BVH)    SceneNode - - - - +      | |  ^         | |  |         | |  | //<---- Association, associates with self (parent pointer)             | +--+         |       +---- Group //<----- all groups are composites (they are containers of scene nodes and are scene nodes at the same time)      |       |      |       +---- Switch      |       |      |       +---- Transform      |       |      |       +---- LOD      |      +----- leaf              |              +---- Geo //<-- not alway the case but most commonly doneitalics are abstract typesbolds are concrete types.

The above is typically known as a composite design pattern, well an instance of a composite pattern that is.

Player: Group node (Group is-a ISceneNode)   |   +--- Gun: Group   |     |   |     +--- Mesh: Leaf node (Leaf is-a ISceneNode)   |     |   |     +--- MuzzleFlash: Group   |                |   |                +--- Mesh:  Leaf   |   +--- Model: Group         |         +--- Mesh: Leaf

Quote:
 Original post by silvermacedo i want the Meshs to be members of the Player entity, rather than actual Scene Nodes? e.g.

I'm not sure what you mean, but if i understood correctly, then you can do either where the latter is most commonly done.

[Edited by - snk_kid on November 8, 2004 3:53:46 AM]

##### Share on other sites
Quote:
Original post by snk_kid
Quote:
 Original post by silvermacewhat i am used to doing is when a render function is calledi add the scene node's mesh data, vertbuffers etc. and all its info, such as materialID(shader), transform matrix etc etc to what i like to call a Render-Graph (RG), then once the RG is formed i do a one-time scene flush where the actual low-level rendering commands are called. the advantage of this is it seperates the scene-graph from the rendering and it also alows for a well sorted RG (node insertion into the RG is sorted, this sorting is controled by zbuffer state and shader/texture id)is this a good idea??? something inside me _really_ wants to do this, but will it be too slow?

hmm.. this sounds fimillar, did you get the idea from this? i don't know of anyone doing this except i think java3d does for its internal representation but as you may or may not know java3d is more general graphics api than a graphics engine for a game.

It isn't an uncommon idea, sounds similar to something I eventually crapped out after trying some other stuff in the game I'm writing.