场景图：递归还是迭代？

Question

我和一位同事正在讨论在复杂游戏中通常如何渲染场景。他相信世界是以最真实的面向对象的方式递归呈现的，世界上的许多演员都覆盖了一个像 Actor.Draw() 这样的虚拟函数（例如 Koopa.Draw()、Goomba.Draw( ))。

相比之下，我想象今天的复杂游戏会迭代他们的场景图，避免虚函数开销，并为专门的迭代器提供更大的灵活性（例如，near-to-far vs. far-to-附近，跳过树中的某些对象等。）而我对 OpenGL 和 DirectX 的经验告诉我，他们倾向于批量绘制对象，并通过递归调用传递批处理上下文（即类的 Draw( ) 函数会绘制) 似乎是可以通过迭代避免的额外参数传递开销。

如今，一种方法比另一种更受青睐吗？如果有，为什么？

Answer 1

更新部分场景图可以递归完成。但是绘图它通常是通过一些空间分区数据结构和几何/渲染状态批处理器来完成的，以防止过度绘制（通过从前到后绘制），并最小化渲染管道的状态切换（批处理数据、使用相似资源的绘制调用和渲染状态）。通常这个绘图部分在某种程度上是迭代的。

您必须考虑场景的复杂程度、它们的组成以及正在绘制的对象数量。对于场景更简单或您事先拥有某些信息的项目，以最佳方式（接近）对渲染进行排序将不值得计算绘图顺序或批处理的实际成本。

最后，“首选”方法将是特定于项目的。