第二部分 OGRE 图形引擎的基本构成
第二部分所需所有图片
OGRE（Object-oriented Graphics Rendering Engine，面向对象的图形渲染引擎），是国际上比较知名的开源图形渲染引擎。OGRE是用C++开发的面向对象且使用灵活的3D引擎。它的目的是让开发者能更方便和直接地开发基于3D硬件设备的应用程序或游戏。引擎中的类库对更底层的系统库（如：Direct3D和OpenGL）的全部使用细节进行了抽象，并提供了基于现实世界对象的接口和其它类。
OGRE系统主要包括：Render系统和Render插件、Material系统和Material脚本、Entity（主要是物件系统）、GUI系统和Overlay脚本、Texture和图片解码器、Archive系统和文件解码器、Scene插件（主要是地形系统）、粒子系统、日志、Dll动态导入和插件系统等等。而最后所有的系统全部归一个总管管理，这个总管就是Ogre::Root。
下图是Root的关联关系， Root是整个OGRE的核心部分，它关联着其他所有的组件，并把这些组件封装其中。
图2－2 OGRE核心部分框图（引用自OGRE的开发框图）
图2-2是整个OGRE的核心成分框图。下面我们引用Mage小组的《Ogre使用指南》里对这个框图的描述：
“
Root：整个Ogre系统的入口点和管理器，它必须第一个被创建，最后一个被消毁。通过Root对象你可以配置系统，还可以获得系统内的其它对象。
RenderSystem：3D API的抽象层，它负责设置所有的渲染属性，并调用3D API执行渲染操作。
SceneManager：场景管理器，它负责组织组织场景，包括场景中Material、Light、Movable Object（Entity）和场景本身。
Material：定义场景中几何体的表面属性。
Entity：场景中的可运动物体。
SceneNode：代表位置和方向，Attach到SceneNode上的Entity可以继承其位置和方向。场景中的SceneNode以树的形式来组织。
Camera：场景中的视点。
”
使用OGRE很简单，因为OGRE提供了自己的Application Framework，如果有兴趣可以参考一下附录里面一段使用OGRE Application Framework的标准代码：（示例来自OGRE自带的地形Demo：Terrain）
但细细分起来使用Application Framework开发，需要写的代码主要还是集中在下面三个方面：初始化、处理输入以及运行时帧循环。大部分时候，我们所需要做的主要是初始化和输入处理，而对于帧循环几乎不必要改动。
既然Application Framework本身封装的就这么好，为什么不能直接使用Application Framework来做游戏呢？来看看Application Framework里面都是些什么吧：
图2－3 Ogre Application Framework 工程
我们从中可以看到高层的封装包括有：一些物件类（AppBox、AppBall等）、物件碰撞检测支持（ODE，一个国际知名的开源物理引擎）、以及一个简单到不能再简单的RefAppWorld（这里面的World类似于我们前面讨论的场景系统），这种封装很难以满足我们的要求。不过看来OGRE的作者似乎也察觉到了OGRE本身的场景系统不能满足需要，因此在Application Framework中又重新构建了我们意义上的场景系统，这种场景系统对于单个场景的演示和Demo是够用了，但是在游戏普遍要求的多场景、甚至是大量场景前面，这种构架似乎又缺乏说服力。而且把ODE和OGRE放在这一层次硬性结合实际效果也并不好，经常出现碰撞检测错误导致穿墙、撞飞的尴尬场面。曾经我们准备在其基础之上建立自己的游戏框架，最后发现越来越陷入到OGRE为我们框死的条框之中。毕竟OGRE是为了OGRE开发者的目的而开发的，不是为了游戏而开发的，更不是为了我们的目的而开发的。
现在，我们准备彻底抛弃这个构架，转而制作自己新的构架，来亲手实践前面纯理论推导的“高层引擎”。当然，我们用的思路也并不超前，同样是Application Framework中已经利用过的“场景＝地形＋物件”思路，但是我们的构架需要考虑到更多的情况，因为我们所要做的游戏并不只是“第一第二世界”（场景），同时它还包括“第三世界”（规则），这一点是OGRE没有重点支持的。
