in a game (or in general), a scene graph is just a list of what to draw, correct?
what is a scene graph ?
Moderators - Reputation: 26986
Posted 28 August 2013 - 07:51 PM
There's a few different structures that people tend to call "scene graphs"... However, a list of drawables isn't one -- a scene graph generally is a tree structure.
e.g. world has houses, houses have rooms, rooms have drawables.
By traversing this graph, you can generate a linear list of drawables.
It was once fashionable for the scene graph to try and do everything - "one graph to rule them all".
The graph wouldn't just hold renderables, but also state changes / render settings.
e.g. a texture could be a node in the tree. Any meshes that appear as children of this node will be drawn using that texture.
It was assumed that there would be some optimal order to traverse the graph that would then produce a minimal amount of state changes.
However, the graph was also used for other purposes, like animation and transform-hierarchy. E.g. if you want to attach a gun to a character's hand, you'd just make it a child node, and the scene graph system would do the rest. The gun's position would be specified in coordinates relative to it's parent node, so when the hand moved, the gun would also move by the same amount.
These days, this idea has fallen out of favour, with most people now having many different structures for different purposes, instead of one uber-graph.
e.g. you might still have a tree structure for transform-hierarchies, so you can attach models to other animated models, but that's all that this graph is for.
You might have a different graph structure (perhaps a cyclic graph) for determination of the potentially-visible-set of objects.
You might have a flat list (array) of game object, not organized into any hierarchy... etc.
Crossbones+ - Reputation: 1835
Posted 29 August 2013 - 05:55 AM
thanks for the info.
i had heard of them with respect to vector drawn graphics packages, but only once with respect to nested transformation hierarchies as far as games goes. So i was constantly looking at some type of list of drawables or list of renderables and going "is that a scene graph?".
looks like the data structure i'm interested is a "list of renderables", as opposed to some sort of BSP octtree "world / level map".
Rockland Software Productions
"Building PC games since 1988"
Members - Reputation: 799
Posted 29 August 2013 - 06:32 AM
In 2007 I wrote a series of articles (that really need an update) about 3D engines, in which I talk about SceneTree, SpatialGraph & RenderingQueue...
(Although they got published over time I wrote the whole series in a week-end in September 2007.)
I hope it will help you.
Members - Reputation: 1408
Posted 29 August 2013 - 08:45 AM
- indexing everything in the 3d scene
- having indices on meshes, mesh instances, materials, effects etc
- sorting and indexing them in a way that I can render the scene with minimal buffer/material/texture changes and state changes
My scenegraph also takes care of sorting alpha blended mesh instences, culling visible point lights affecting mesh instances etc.
@ingenu: thanks, good stuff for reading and gaining more knowledge/ freshening up
Members - Reputation: 130
Posted 29 August 2013 - 09:34 AM
It's a graph that describes a scene. The word 'graph' is used in the mathematical sense. I think in the case of a scene graph it is usually (or always?) a directed acyclic graph.
The graph is just the data structure for holding all the scene data. The main things you want to achieve with it are view frustum culling and state sorting because those will make rendering *much* more efficient. These are done by all the helper routines that operate on the graph. A good scene graph will come with a lot of extra helpers, such as level-of-detail switching, depth sorting for rendering transparent objects, shadow map rendering, etc...
Members - Reputation: 980
Posted 30 August 2013 - 01:54 PM
Pretty much what has been said before but maybe to show it in a more "visual" and direct way:
As an example of how the structure (and also most importantly the transformations) of a character or skeleton might look like:
Root (could be just an origin location in the center somewhere)
-> Head (is relative to the torso)
-> Left Eye (is relative to the head)
-> Right Eye
-> Left Arm
-> Right Arm
-> Left Leg
-> Right Leg
So we can easily build a dependency structure that holds our skeleton together.
You could then define the Head's transform relative to the torso's transform which is also relative to the root's transform (location)
global_head_transform = * global_root_transform * global_torso_transform * global_head_transform
hope I got the order right...
Edited by lipsryme, 30 August 2013 - 01:55 PM.