Scene graphs: recursion or iteration?

Question

A colleague and I are talking about how scenes are typically rendered in complex games. He believes the world is rendered recursively in the truest object-oriented fashion, with the world's many actors each overriding a virtual function like Actor.Draw() (e.g. Koopa.Draw(), Goomba.Draw()).

By contrast, I imagined that complex games today would iterate over their scene graph, avoiding virtual function overhead and allowing more flexibility for specialized iterators (e.g. near-to-far vs. far-to-near, skipping certain objects in the tree, etc.) And my experience with OpenGL and DirectX suggested to me that they tend to draw objects in batch, and passing a batch context through a recursive call (i.e. the batch into which a class's Draw() function would draw) seemed like additional parameter-passing overhead that could be avoided with iteration.

Is one method favored over another nowadays? If so, why?

Answer 1

Updating parts of a scene graph might be done recursively. But drawing it is usually done via some spatial partitioning data structure and geometry/render-state batcher in order to prevent overdraw (by drawing front to back), and minimize state switches of the rendering pipeline (batching up data, draw calls that use similar resources and render states). Usually this drawing part is in a way, iterative.

You have to take into account how complex the scenes are, their composition, and how many objects are being drawn. For projects with simpler scenes or where you have certain information beforehand, sequencing your rendering (near-)optimally will not be worth the actual cost of calculating the drawing sequence or batching.

In the end the "favored" method would be project-specific.