【Ogre编程入门与进阶】第四章 Ogre的设计理念与特色

4.1 Ogre的设计理念

        Ogre内部结构非常的复杂，它是一个庞大的对象和模块的集合，Ogre具有很好的封装性，绝大多数的细节对程序员来说是透明的，即系统底层的细节都被封装起来，程序员无需知道具体的细节是什么，只需要简单的调用Ogre提供给我们的函数接口就可以实现我们想要实现的功能。对于OpenGL或者Direct3D这种底层API来说，是不具备这种封装性的，如果想要利用OpenGL或者Direct3D这种底层API来实现一个简单的功能，过程往往十分繁琐，对系统底层的操作都需要程序员“亲自”利用代码完成，这动辄上百行代码的工作量，严重影响了程序员的工作效率。

         Ogre的设计是完全面向对象的，我们可以直接对场景中的物体（包括模型、灯光、摄像机等）进行操作，这些操作包括平移、旋转、放缩等，而不需要关心诸如矩阵是如何变换的这些底层概念。换句话说，Ogre面向对象的设计，让我们从“调用系统底层API”的复杂操作中跳脱出来，底层复杂的操作，Ogre会替我们完成，我们要做的，就是把更多的精力放在诸如“如何设计场景”这类“高级”的事情上来。 

        在前面章节中，我们曾经介绍过，Ogre是一个用C++开发的图形库，它隐藏了底层系统库（如：Direct3D和OpenGL）的所有细节，让开发一个3D程序不再那么复杂，程序编写人员可以调用已经封装好了的Ogre类来轻松实现需要的功能，可以说，Ogre让开发一个复杂的3D程序变得非常简单和容易。也就是说，Ogre将系统底层（OpenGL或者Direct3D）的API进行了二次封装。另外，Ogre实现了场景内容与场景图的完全分离；而且，它还使用了插件系统，将用户希望使用但是Ogre核心中又没有的功能作为插件的形式添加进系统，而且一旦使用完毕这个功能只需简单的将这个插件删除即可。有关插件的内容我们将在下文详细介绍。

4.2 Ogre的设计特色

        这一章中，我们将在一个比较高的层次上向大家介绍Ogre的设计特色，可能对于初学者而言，并不能完全的理解，没关系，本节只是整体的介绍Ogre的设计特色，具体的内容将会在后续的章节中详细介绍，读者也可以在学习完后续章节后再回过头来看本小节，相信这样一来，您对Ogre的设计理念与特色会有一个更深层次的理解。

 

4.2.1 “设计模式”思想

        设计模式（Design pattern）类似于一套模板，这个模板包含了用于实现特定功能的代码，设计模式可以被反复的使用，设计模式使软件开发工程化，是软件工程的基石。

Ogre中使用设计模式来提高程序库的可用性。Ogre的设计中成功的实现了多种通用的设计模式，这样一来就大大增强了Ogre的运行效率与灵活性。举例来说，Ogre中使用了多种模式，包括观察者模式、单件模式、迭代器模式、访问者模式和外观模式以及工厂模式。我们可以把这每一种模式看作是一个“设计模式”，每一种模式提供了一种特定的功能，它们相互独立，而且彼此又具备相对完善的功能。换句话说，每一种模式都可以看做一个特定的模板，都具有特定的功能，而且彼此互不影响。如果大家曾经学习过设计模式的相关概念，对于理解Ogre的设计想必会有很大的帮助。

 

4.2.2 实现了场景节点与场景内容相分离

        在传统3D引擎的设计中，往往没有将场景节点和场景内容分离，而是将场景内容作为场景节点的子类。这可以说是一个非常失败的设计方案，因为这种设计方案会使对场景的维护变得非常困难。例如，在设计完一个场景之后，如果我们要对其中的场景内容进行修改，就必须对所有的子类进行修改，可谓牵一发而动全身，非常不利于维护。

        在Ogre中，场景节点和场景中的内容是两个完全分离的概念，Ogre中引入了实体的概念，实体是场景中可以被渲染的物体，我们可以把场景中的任何一个3D模型都看做实体。但是，实体不能直接被放置到场景中，它需要与场景节点绑定后放入场景，这样，这个实体才能够被渲染；同样，一个场景节点也不能单独的在屏幕上显示出来，只有与一个实体绑定后才能在屏幕上显示，场景节点记录了绑定在上面的实体的信息。

图4-1

        正如上图（图4-1）所示，根节点下绑定场景节点，场景节点上可以再绑定场景节点，实体绑定在场景节点上，而且，一个场景节点上可以绑定多个实体。在场景中，被渲染的对象是实体，而不是场景节点，场景节点中只包含了绑定在上面的实体的方位等信息。例如，当我们移动节点2，实体3就跟着移动；当我们移动节点1，实体1和2就跟着移动。这就好比场景节点是实体的“代言人”，对实体的移动、旋转、缩放等操作，其实是通过实体绑定着的场景节点完成的。另外，实体是场景中被渲染的对象，它包含了纹理、材质等信息，而场景节点却不必包含这些信息。这也就意味着，Ogre实现了场景节点与场景内容（即实体）的分离。

      

4.2.3 灵活丰富的插件体系

        Ogre除了本身具有的功能以外，还可以通过插件的形式对其功能进行扩展，通过插件的形式，可以使得Ogre的功能横向的延伸。读者可以灵活的在Ogre中添加插件或是卸载插件，完全根据自己程序的需要。可以说，Ogre的拥有一套十分灵活而且丰富的插件体系。在Ogre中，Ogre安装目录下的plugins.cfg配置文件掌控了整个插件体系，如图4-2。

图4-2

        用记事本打开plugins.cfg文件，可以看到其中的内容（如图4-3）：

图4-3

        读者可以通过改变这个文件的内容来达到配置自己程序中使用的插件的目的，当读者朋友有能力查看Ogre源代码时，就可以一睹Ogre中各种插件的实现方式了。这里的文件名不一定要用 “plugins.cfg”，可以根据自己的喜欢随意取名。注意：默认情况下，系统采用的插件配置文件的名字为：“plugins.cfg”。在plugins.cfg配置文件中：第4行的PluginFolder标签的值用来设置Ogre要使用的插件的所在目录。从第7行开始，“Plugin=”后面列出的内容，就是当前的Ogre应用程序中所有要使用的插件。

 

笔者注：         “Plugin=”后面列出的内容是Ogre要使用的插件的名称，但是，这个名称并不包含扩展名，这么做的好处是，可以让Ogre中的插件兼容在不同的平台上。（因为不同平台上的扩展名是不同的。）

 

        Ogre的这种插件体系使得我们的应用程序的功能可以以插件的形式灵活的添加或是删除，这大大增强了程序的灵活性，而且，添加或是删除某个插件的操作非常简单，只需在上面的文件中添加或移除相应的一行代码就可以。也就是说，Ogre将自身非必要的功能都设计成插件的形式，例如粒子系统、公告板等，用户可以安全根据自己的需要对这些功能进行添加或卸载。

        而且，当我们将新的插件添加到系统中去之后，我们不需要对Ogre的程序库重新编译生成。我们需要做的，仅仅是将我们的插件文件放入指定的目录即可。Ogre会自动为我们处理好剩下的工作，包括诸如如何与新添加的插件建立联系、如何调用插件的功能等。Ogre的这种透明性也大大降低了程序开发人员的工作量，提高了开发效率。

 

 4.2.4 硬件加速特性

        Ogre是一种支持硬件加速的图形渲染引擎，它不能单纯的依靠软件进行渲染，因此它必须借助一种或多种硬件，即图形处理器（常用NVIDIA，也可以使用ATI出品的图形硬件）来进行图形渲染。也就是说，Ogre利用硬件对自身进行“加速”。

        Ogre的这种设计特性大大提高了其自身的性能。它支持大多数的硬件加速特性，可以通过可编程着色语言的使用达到3D渲染引擎所需要的效果。

 

笔者注：         目前，Ogre几乎可以做到其他大多数引擎可以做到的功能。虽然，目前的Ogre版本尚不支持某些离线状态下使用的高级算法（例如：Direct3D中所支持的环境光吸收、预计算辐射传递技术等），不过，由于是离线状态下的算法，不用考虑它的实时性，因此也不会对Ogre程序的功能和效率产生太大的影响。

 

        目前的Ogre版本只支持Direct3D 9和OpenGL这两种渲染系统。由于这两种API是目前最广泛使用的API，Ogre官方将一直保留对这两种API 渲染系统的支持。

4.2.5 灵活多变的渲染队列

        渲染队列在Ogre中是一个重要的设计，它在对场景中不同物体的处理方面发挥了重要作用。在场景中的所有需要渲染的物体在绘制之前都被放到一个特定的渲染队列中，队列也按自己的顺序排好，然后Ogre分别渲染每个队列。

        Ogre中的渲染队列主要起到两个作用：1.确保正确的绘制顺序，比如先绘制背景再绘制其他物体（如图4-4所示）；2.提高渲染效率。图4-3为Ogre渲染队列的直观图：