It was very popular in the 90's. Then people realized that using one common tree structure to try and solve multiple problems was a stupid idea, and now the very phrase "scene graph" makes people shudder.

In that traditional model, you could apply almost anything to a node, and it's children would inherit the value.
Transform a node and it's children also transform, put a blue texture on a node and it's children become blue, add a light to a node and it's children get lit.
Some variations of these kinds of systems had 'overrides' and 'defaults' when setting node properties -- so a parent node could set it's children's *default colour* to blue, which would only take effect if the child nodes didnt set their own default value (or explicitly override it).

These days, you instead have many structures for different purposes. You might have a linear array of scene objects for managing lifetimes (a "scene vector"?), a directed-acyclic-graph (ideally linearized into a vector) for propagating transforms through a hierarchy of bones, traditional composition/linking of materials/meshes/etc from scene objects, a bounding vokume hierarchy (or oct-tree/etc) for culling/spatial queries (a bounding volume instance might point to a scene item, or a list of them)... etc.

ECS is a family of ideas for making frameworks that revolve around composition. OOP also teaches that you should use composition, so this isn't specific to ECS, no.

This link gives a pretty detailed introduction into the history and evolution of scenegraphs:

http://www.realityprime.com/blog/2007/06/scenegraphs-past-present-and-future/

As people itterated on the concept they ended up trying to leverage it for too many things that it wasn't optimal for, so implementations became bloated and inefficent messes many times. All that gave using the word 'scenegraph' somewhat a less than positive connotation.

Even if they don't call it a scenegraph most engines have something that still fits the basic description of the concept. Yet good implementations keep them directed to a task, being smart about reserving it for what it's does well and avoiding the temptation of a one-size fits all needs approach.

Today most wouldn't store the data in the graph, as a graph's best use is to optimize traversal of a hiearchy vs. efficency of data storage for varied types of objects. Instead you can use specialized graphs that are organized in a way that's ideal for the task that graph needs to solve, they reference objects/entities that are constructed in a way provides things like composition and that references data that's stored in the way that is most effecient for the processing, transfer and storage of data vs. forcing everything to couple to a representation that's good for graph searches and/or object composition.

Scene Graphs


L. Spiro

fwiw, the term "transform hierarchy" is becoming preferred in my experience over "scene graph" due to the aforementioned shudders that Hodgman mentioned.

Another thing to keep in mind is that far fewer things are in the transform hierarchy than one might think. Physics and constraints keep many objects attached in many of today's games rather than the (graphics-only) transform hierarchy.

Also note that the transform hierarchy is often separate from the spatial structure used for object culling during rendering. The hierarchy is made for fast updates of transform data while the spatial structure is used for fast frustrum intersection tests, and are generally best served by very different data structures and algorithms. There may even be different data in both structures since there are items you probably want in the transform hierarchy that aren't even rendered (attachment points controlled by skeletal animations, camera locations, etc.).