场景图与场景内容分离
虽然没有得到权威的论证，但我还是坚信场景图和场景内容的分离的设计一定是整个Ogre项目中最亮眼的地方。虽然看起来它是一个如此的简单易懂，不过对于那些仍然坚守“传统的设计方法”来完成场景图设计的人仍然会难以理解。
在传统设计中（就是很多商业和开源3D引擎所采用的）将场景内容和场景结构放到一个继承体系中，并将场景内容生硬的作为场景节点的子类。我断言这是一个极其失败的设计方案。如果不修改所有的子类，基本上是没有办法更改或者扩充图形算法的，因此让修改基类的接口非常困难，进而导致以后的维护工作变得举步维艰。此外这种“所有节点源自同一节点类型”的设计思想会让整个程序变得凝固且难以复用（至少从维护的观点看）：当增加新的基类功能方法或者属性的时候，不管是否真的需要，这些都强迫的塞入所有子类。最后导致哪怕是对基本功能做很小的修改，都会牵一发会动全身, 导致开发维护最终变得难与控制。这种糟糕的设计理念让陷入的人们痛苦不堪，从而希望摆脱这种逻辑采用全新的设计方法。
Ogre做到了。首先，Ogre对场景图的操作维持在接口级别；它并不关心去操作图形的具体算法实现。换言之，Ogre只是通过信号（它们的方法）来操作场景图，进而忽略了具体的算法实现。其次，Ogre的场景图接口只负责维护场景结构。节点中没有包含任何固有的内容和管理方法。具体的内容被放置到一种可渲染（Renderable）对象之中，它提供了场景中全部几何图形（包括活动的的或者其他所有的）。它们的渲染的属性（也可以说是材质）被包含在实体（Entity）对象中，在实体对象里面同样包含着一个或多个子实体（SubEntity）对象，这些子实体才是是真正可以被渲染对象。图3-1 展示了场景图结构和场景内容之间的关系。注意：尽管场景节点挂接到场景图上面；但场景图仍然没有任何节点状态的直接操作。
图3-1：Ogre中场景图和场景内容关系描述
其中活动对象MobeableObject可以直接操作所有几何体和渲染属性。它并不是场景节点的子类，而是挂接到场景节点中（可以理解为通过组合代替继承）。这意味着如果你需要，程序中的场景节点可以不用了解与之相关的可渲染对象的任何细节。也意味着你可以扩展，改变，重写，或者其他改变场景图的实现，而不会影响场景内容接口的设计和实现；他们彻底独立于场景图。场景图甚至可以完全修改而不会影响任何内容类。
反过来说也同样适用：场景图同样不需要对所挂接的场景内容节点有任何了解，只要通过所用的接口来通知就可以完成所需要的功能。因为这些出色的设计，Ogre甚至可以完成对“用户自定义（user-defined）”内容节点的挂接。如果你决定构造一个拥有环绕立体声的场景，你可以把各种音效实现自定义节点，然后无缝的挂接到场景中。自定义的场景节点只需要实现一个简单的接口，就可以把定制数据挂接到场景中任意的节点上。