in a game (or in general), a scene graph is just a list of what to draw, correct?

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.

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".

In 2007 I wrote a series of articles (that really need an update) about 3D engines, in which I talk about SceneTree, SpatialGraph & RenderingQueue...

http://www.beyond3d.com/content/articles/98/

http://www.beyond3d.com/content/articles/102/

http://www.beyond3d.com/content/articles/109/

(Although they got published over time I wrote the whole series in a week-end in September 2007.)

I hope it will help you.

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)

-> Torso

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

e.g.

global_head_transform = * global_root_transform * global_torso_transform * global_head_transform

hope I got the order right...