Sign in to follow this  
silvermace

Scene Graphs and Rendering Them

Recommended Posts

silvermace    634
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 this post


Link to post
Share on other sites
snk_kid    1312
Quote:
Original post by silvermace
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?


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 silvermace
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?


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 silvermace
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



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 done

italics are abstract types
bolds are concrete types.


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

Your scene graph instance slighty adjusted.


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 silvermace
do 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 this post


Link to post
Share on other sites
Kibble    504
Quote:
Original post by snk_kid
Quote:
Original post by silvermace
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?


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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this