场景管理是3D引擎的一个核心部分，因为它是引擎的用户每天都要用到的一个特性。通常的做法是通过场景图（可能这样称呼不太准确）来实现，场景图就是一个数据结构，有：层次结构（火炬在英雄的手中），空间结构（一个兽人在英雄的旁边）以及状态结构（火炬当中的火是alpha混合的）。
这样一个结构的问题是，它试图成为一个万事通，但是最后在任何一方面都没有优势。互联网上已经有过许多对此的讨论，一般的共识是这样的一个超级场景图应该被舍弃。当代的一些游戏当中有些也根本没有场景图，也没有任何表示场景的层次结构。这样做也许对某一个类型的场合工作的很好，但是当一个引擎需要适应更多的场合来减轻其用户的工作压力时，拥有一个场景图可能是你想要做的。
拿上面的例子来分析：英雄的手中握着火炬，当他的手移动的时候，火炬也必须跟着移动，因为在这个层次结构中，火炬节点是手臂节点的一个子节点，因此这种跟随移动将自动进行。全能的场景图的问题是试图通过一次性的解决所有问题而导致对子问题的处理不是很优秀。两个相邻的物体可能在场景图中的不同分支下，因为它们分别在两个不同的层次结构中。还有当两个具有相同属性的物体需要渲染时......
我们来想象一下下面的场景：两个战士通过具有魔法的剑来进行战斗，这两把剑都通过粒子效果来展现他们的魔法效果。很明显，这两把剑将会相互撞击到一起去，所以会空间上会非常靠近；但是他们又是分别握在不同的英雄的手中，因此他们属于两个不同的层次结构（外层次结构关系），而显示两把剑的魔法效果的粒子效果是相同的，是通过复制实现的。
因此一个数据结构无法一次性解决所有的问题，而只能解决一个问题，因此自然地引导我们去为每种不同的关系设计特定的数据结构。如果按照最近的一篇论文中介绍的，引擎使用的数据结构成为视图，数据成为物体，那么这个引擎将具有下面三个视图：
场景树：整个世界的一个层级结构视图（用于处理层次结构的动画）
空间图：世界的一个空间视图（用于对相邻物体进行分组以拣选）
渲染图：世界的一个最佳状态图（用于按照状态对物体进行分组，例如着色器，材质等）
从引擎的作者的角度来说，这听起来非常不错：为了不同的任务设计了不同的数据结构，每个结构都是为了优化性能特性设计的。但是从引擎的用户的角度来说，同时操纵这三个数据结构显得相当笨重。
幸运的是，这不是用户的负担，因为这一切都隐藏起来了。用户只需要一个函数接口来操纵一棵树：场景树，也许用户会收到引擎内部的一些提示和警告。当物体创建的时候，他们将会自动的插入到空间图中渲染图中去。还是上面的例子，两个英雄手中的剑会在同一个节点（通过空间图）中，并且由于它们相互接触了，它们的层次结构的动画也会正确展现处理（通过场景树），而且它们会分享使用同一个特效的粒子系统（通过渲染图）。