深入分析游戏引擎.doc

深入分析一款游戏引擎在分析任何一款游戏引擎之前，我们首先需要明白一个问题，即什么是游戏引擎？作为一个不怎么玩游戏的女孩子，听到“游戏引擎”四个字，立马会猜想：游戏引擎大概就像汽车发动机一样，有了它，整个游戏才具有生命力，汽车失去发动机就只能成为摆设了吧。根据维基百科等的解释，游戏引擎的概念大致如下：首先，它是一些已经编写好的可编辑的电脑游戏系统或者一些交互式实时图像应用程序的核心组件；其次，它为游戏设计者提供各种编写游戏所需的工具，让游戏设计者能够在一定基础上方便而又快速地开发新产品；再次，游戏引擎包含诸多系统，如渲染引擎、物理引擎、碰撞检测系统、音效脚本引擎、电脑动画、人工智能、网络引擎以及场景管理等等。由于它提供了游戏开发者一套凌驾于硬件层与用户界面之间的可重用的全功能封住，减少了独立开发费用和时间，所以游戏引擎也被称为“游戏中间层”。另外，它也经常被用于其他所需的互动领域，如商业产品介绍、模拟训练以及建筑效果预览等。 通过几天在游戏开发网站上的浏览和学习，我将深刻分析其中一款游戏引擎OGRE，即Object-Oriented Graphics Rendering Engine(面向对象的图形渲染引擎)。我选择分析介绍该游戏引擎是基于以下几个原因：首先，它具有悠远的历史，是目前开源领域排名第一的图形引擎，具有一定的代表性。其次，它几乎拥有了商业3D渲染引擎的全部特性，甚至在某些方面超越了它们。三、最后，经过老师的推荐，这是一款值得我们去学习和探索的游戏引擎。在分析该款游戏引擎之前，首先我们要对它的相关概念有一个充分的了解。什么是Ogre？如前所述，它是一款面向对象的图形渲染引擎，也被称为Ogre 3D，是一个用C+开发的面向场景、非常灵活的3D引擎。在这里，我也很困惑Ogre到底属不属于一款游戏引擎。据百度百科等相关资料的显示，它被用于开发游戏，但实际上不是一个游戏引擎。主要原因在于Ogre缺少游戏引擎的一些部分，只能被称为一款图形引擎；如果你想通过它来开发游戏，还需要其他开发库的结合（声音、网络、输入、碰撞处理等）。综合起来考虑，Ogre还不是个完整的游戏引擎。这个拥有怪物头Logo的图像引擎，为游戏设计者提供了一个很好的开发平台，代码开源，在业内具有赫赫大名。当人们提到有哪些开源游戏引擎时，Ogre的名字是不可能被遗忘的，而且对它的评价也很高。几天前我从ogre3d官网上下载并安装了Ogre。亲身体验过Ogre之后，明显能感受到它的优异特性，尤其是它的那些Demo。与其他的游戏引擎相比，Ogre具有很多优势。首先，作为一款商业引擎，它比gamebryo等其他游戏引擎都具有更强的图形渲染功能。其次，它的代码是免费而开源的，面向对象的，并且高效。再次，它抽象化了不同的API和平台，可以以场景为对象来使用物体，支持多种场景，已经被成功地应用于诸多三维仿真领域，包括网络游戏和三维仿真项目。最后，它能让开发者方便和直接开发基于3D硬件设备的应用程序或游戏。仔细考究，Ogre有多方面的特点。从平台和3D API支持上来看，它支持多个平台，如Windows、Linux等，并支持从PNG、JPEG或TGA这几种文件中加载纹理，自动产生MipMap，自动调整纹理大小及坐标等。从网格Meshes方面来看，它具有高效的网格数据格式，支持用Bezier样条实现曲面和骨骼动画，并提供插件支持Milkshape 3D导出Ogre本身的.mesh以及.skeleton文件格式。从场景特性方面来看，它可以通过包围体、包围盒来实现视域剪裁，通过二叉树场景管理器插件加速室内场景的渲染，拥有高效率和高可配置性的资源管理器来支持多种场景类型。从特效方面来看，它可以支持Billboard以实现特效，支持天空盒、天空面、天空圆顶等，使用起来非常方便。最后，其他特性方面，支持资源管理和文档加载，支持高效插件体系结构等技术。现在，我将详细从五个方面来分析Ogre引擎。1、 Ogre消息机制 消息的产生地即从各种输入设备读取数据。消息在被处理之前会先被发送给Listeners，改变消息处理的默认行为。真正处理消息的地方是EventListener,而消息的代理分发是通过EventDispatcher。从消息处理整个过程来看，程序进入Root:startRendering()后，开始进行消息循环；EventProcessor将队列中所有的消息通过EventDispatchers分发给EventTarget处理。总体过程简化为：InputReaderEventProcessorEventDispatcherEventTargetEventListener。2、 Ogre文件系统 Ogre文件系统可以分为目录管理和文件管理两大类。它不仅可以读取普通的文件，也可以读取Zip压缩文件。从应用层次上，Ogre提供了配置文件管理、日志文件管理和资源文件管理等。从配置文件来看，它的配置文件以key/value形式保存，保存各种自定义数据，如插件目录和插件文件等。Ogre文件系统的核心是Archive和DataStream，前者是文件容器，可以是文件夹也可以是压缩包；后者则可以读取普通文件、压缩文件和内存文件等。资源管理对于游戏的开发很重要，Ogre在这方面提供了很强的支持。Ogre：Resource定义了各种资源的读取方式，Resource可以通过类Ogre：Resource提供的方法加载和卸载，但Resource的最终销毁却由Ogre：ResourceManager来管理。3、 Ogre设计模式 Ogre的设计模式有多种，结构都十分清晰。其中，Singleton模式是Ogre最广泛的设计模式。这个模式本身很简单，如Gof提到的实现方式，实现的方式多种多样。Abstract Factory提供用于创建一系列相关或者相互依赖对象的接口，这样使得使用者无需关心使用的是何种具体对象，为使用者带来方便。所以，在Ogre中，该模式体现出了它的Plug-in机制。通过该机制，一方面把与平台相关的部分和与平台无关的部分分离开来；另一方面便于系统功能的扩充。而另一个设计模式Factory Method在本质上被认为是代理了某个类的实例化过程，即封装了一个new的语句。当一个类的构造函数的参数很多，其中有可以提供默认值的时候，用Factory Method还可以简化对象的创建。Bridge最大的特点是能够使抽象部分与它的实现部分相分离，两部分被分离之后就都可以独立变化提高可扩充性。该模式可以在实现跨平台、程序换肤、文件版本演化等多种情况下使用。当然，我们可以根据实际情况来选择相应的模式，同一个问题有不同的解决方案，模式的使用可以说是仁者见仁，智者见智。4、 Ogre场景渲染我们知道渲染过程大致如下：1、OGRE的渲染起点是renderScene，它的每一帧都会调用函数来开始渲染的过程。2、updateSceneGraph和findVisibleObjects属于常见的场景管理，会将相机camera视角下的所有Node准备更新，并形成最终需要渲染的RenderQueue；Overlay有自己的find函数。3、renderVisibleObjects，函数会对场景节点进行递归遍历，用来找到场景中的叶节点的可见Renderable对象，把它们add到之前介绍RenderQueue中，即addRenderable方法。RenderQueue的主要作用，其实就是为了减少由于渲染状态的改变带来的driver中状态管理以及violation的CPU时间以及重置GPU 状态的时间，把相同Pass的Renderable放在一起渲染。写到这里，不难发现，场景渲染的这个流程跟我们用D3D写一个简单程序的流程基本是一样的，在这个流程的基础上，再去看具体的实现，如怎么样设置纹理，怎么样调用你熟悉的D3D或 OpenGL的API来渲染物体，应该会简单得多。 五、Ogre场景管理 场景管理有很多种方法，如四叉树、八叉树、BSP、模糊K-D树、包围球层次结构等。在管理场景中的对象以及几何体的管理功能方面，Ogre中的场景图与其他的引擎实现的功能没有什么本质的区别。不过Ogre并没有使用“一个”场景图，通过引擎所使用的插件机制，Ogre通常会使用一些外部“插入”的场景图算法来使用。Ogre中提供的SceneManager类只不过是场景图的接口，你可 以通过它来调用Ogre本身提供的几个不同的场景图算法，也可以在网上找到一些Ogre场景算法的其他实现，其中包括商用的内存分页场景管理器以及商用收费/非商用免费的场景管理器等。 Ogre引擎也有一部分的劣势和不足。 一、无法干预的渲染流程 由于Ogre 把其渲染流程封装到了底层，这为用Ogre开发的人员提供了便利。很多绚丽的效果，我们通常只需要写一行代码就可以完成了，而不需要写大量的OpenGL或者Direct3D的代码。但是，这也成为我们开发的一个障碍，比如我们想加一些特殊效果，就只能用Shader来实现。 二、有些逻辑经不起推敲 由于FrameListener是异步加入即FrameListener必须在渲染一桢后才被加入到引擎中，所以当我们在Root里加入一个FrameListener，然后在未出函数体之前将其Remove，就会导致死机现象。但是，通常来说将一个对象加入到另一个对象，然后删除才应该是符合正常逻辑的，最起码不应该出现死机的情况。如果找从SceneManager中取一个不存在的Entity，Billboard等会抛出异常，但是引擎中并未提供该对象判断 是否存在的方法。 三、设计方面 Ogre在设计方面采用插件机制，但是用的不彻底，导致其上层模块过于庞大。读者可以看到Ogre.dll 库几乎囊括了渲染系统，读写系统，控制系统等等，如果能把这些东西从中分解开来，以插件的形式实现之，而上层的类统统以虚接口的形式给出，这样就更加完美。笔者曾经做过从3DMax中导出ogre支持的mesh模型的插件。虽然ogre也提供了这种插件，但是必须要将模型转为XML文件，再转为Mesh 文件，如果模型比较简单，这样做