转自:http://www.tuicool.com/articles/QbMjUn

游戏中通常有大量资源,如网格、材质、纹理、动画、着色器程序和音乐等,游戏引擎作为做游戏的工具,自然要提供良好的资源管理,让游戏开发者用最简单的方式使用资源。游戏引擎的资源管理包括两大部分:离线资源管理和运行时资源管理。本文仅对前者进行简要介绍,并结合Unity3D和OGRE进行分析。

资源创作与导出

游戏中的资源由各种数字内容创作工具(DCC, digital content creation)进行创作,如:

  • 三维模型:3ds Max,Maya等;
  • 纹理:Photoshop等;
  • 音乐:Sound Forge等;
  • ………………

DCC往往支持多种导出格式,如:

  • 3ds Max:3DS、AI、DDF、DEM、DWG、DXF™、HTR、FBX、IAM、IGES、IPT、LP、LS、MTL、OBJ等;
  • Photoshop:PSD、TIFF、EPS、PCX、GIF、JPEG、PNG、PICT、TGA等;
  • ………………

游戏引擎一般会支持指定DDC的部分导出格式,例如Unity3D支持3ds Max导出的FBX格式;或者针对特定资源创作工具编写导出插件,例如OGRE有多种三维建模软件的      导出插件      。      虽然基本上所有DCC都支持多种导出格式,但是很多情况下这些格式都不适合游戏引擎,因为

  • 导出的内容过于复杂,游戏中只用到其部分数据,而游戏往往对性能的要求比较苛刻,所以需要去除冗余数据;
  • 许多DCC导出的格式读取比较慢,而且还有一些是封闭格式导致引擎无法读取。

因此,在DCC导出资源后,需要引擎进一步处理,将资源转换为引擎的内部格式,这种处理被称作Asset Conditioning Pipeling。使用Unity3D的童鞋应该会发现,每次导入资源的时候都要读条,就是在进行Asset Conditioning Pipeling;OGRE在这方面的支持不够完善,这部分工作由自定义的导出插件完成。

资源的“编译”与“链接”

由于导出的资源存在一些问题,需要进行一定的转换,这个转换被称作Asset Conditioning Pipeling,包括2个步骤:

  • 资源“编译”

读取单个资源的数据,将其转换为游戏中可以直接使用的格式(使用效率最高或较高的格式),例如重新对Mesh的顶点进行排序,或使用BC5等压缩算法对纹理进行压缩。这个过程与C语言的编译有些类似,因此取名为“编译”。当然,如果导出的资源可以直接使用,那么可以跳过这一步。

  • 资源“链接”

在游戏中,许多资源并不是单独使用的,例如三维模型,它引用的材质和纹理是单独存在的资源。在上一步中,引擎对单个资源进行“编译”,将其转换为可以直接在游戏中使用的格式;这个步骤将所有的资源进行“链接”,使得游戏在运行时可以找到每个资源所依赖的所有资源,例如三维模型可以正确的找到其需要的材质和纹理。这个过程与C语言的链接有些类似,因此取名为“链接”。当然,如果导出的资源可以直接使用,那么也可以跳过这一步。

Unity3D对这部分提供了比较完善的支持,因此只需要导出引擎所支持的标准资源,并放入Assets文件夹,引擎会对其进行“编译”和“链接”,结果就在Library文件夹中(里面乱七八糟的,虽然我们看不懂,但是Unity3D很喜欢);OGRE没有提供专门的Asset Conditioning Pipeling工具,因此所有操作都在资源的导出插件中完成,没有进行单独的“编译”和“链接”。

资源管理数据库

在资源通过Asset Conditioning Pipeline之前,引擎需要存储处理该资源的方式,一般使用metadata(元数据)来描述,例如指定某个纹理应该是以何种方式压缩。引擎通过资源数据库来管理metadata,资源数据库既可以简单的使用XML文件进行描述,也可以使用MySQL等数据库。游戏开发者通过引擎提供的接口实现资源的重新配置,例如在Unity3D编辑器中可以修改Mesh的压缩方式,选择是否优化Mesh等。

游戏引擎的资源数据库一般要提供如下功能:

  • 创建和删除资源;
  • 查看和修改现有资源;
  • 将资源移动到其他路径;
  • 支持资源的相互引用,并且在被引用资源移动路径后,保证引用有效;
  • 提供多种便捷的查找资源的方式。

使用Unity3D的童鞋可以发现,Unity3D提供了比较完善的资源管理的功能,使用起来比较轻松。

资源读取(运行时)

在开发过程中,所有原始资源以单个文件形式进行保存,以方便修改,但是在游戏运行读取资源的时候,为了加快读取速度,一般会将资源打包成一个或多个文件。打包的原因很简单,从硬盘中读取文件的时间中,主要由三部分组成:

  1. 硬盘寻道时间;
  2. 打开文件的时间;
  3. 读取文件的时间。

      最后一项是不可能改变了,除非使用速度更快的存储介质;但是将多个文件打包成一个文件,可以缩短前面两项的时间。Unity3D在发布游戏的时候,会将资源进行打包;OGRE没有自定义打包资源的方式,一般打包为      一个或多个ZIP文件,或不打包资源      。   

实例分析

Unity3D

拷贝Unity3D工程的时候,一定要拷贝“Assets”、“Library”和“ProjectSettings”文件夹。资源都在“Assets”,设置都在“ProjectSettings”,“Library”是来打酱油的?非也!如果不拷贝“Library”,打开工程以后你一定会大吃一惊,之前的设置全没了?!而且场景文件里的东西也是乱成一团!结合上文,则很容易理解这种诡异的现象,明白为什么少不了这个“打酱油”的“Library”。

将资源放入“Assets”文件夹,切回Unity3D,则进入Importing Assets状态(进行Asset Conditioning Pipelining),如下图

导入资源

在这个步骤中,Unity3D针对所有的资源生成metadata,并进行“编译”、“链接”,转换为游戏可以直接使用的资源。转换前的资源保存在“Assets”中,转换后的资源保存在“Library”中,所有的资源在Inspector面板中可以修改metadata的数据,如下图

“Library”文件夹

Inspector

如果使用SVN等版本控制器,需要同步所有资源及其metadata。打开Edit->Project Settings->Editor,将Mode修改为“Meta Files”(默认“Disabled”),如下图

选择“Meta Files”

Mode修改为“Meta Files”后,回到资源文件夹,会发现每个资源都多了***.meta文件,如下图,而这些.meta文件保存了这些资源将如何被Asset Conditioning Pipeline处理。

带metadata的资源文件

现在Assets文件夹中不仅有所有的资源,而且还有对应的metadata,“Library”彻底打酱油了,此时在拷贝工程或使用SVN同步工程时才可以忽略“Library”文件夹。

在发布的游戏中,资源文件如下图所示。可以发现,Unity3D对资源进行了打包,以减少资源载入时间。

发布后的游戏资源

总的来说,从导入资源,生成metadata,“编译”、“链接”资源,再到发布游戏时打包资源,Unity3D都封装好了,以最简单的方式提供给我们使用,极大的提高了游戏开发者的工作效率。虽然可能第一次在用的时候只是感觉Unity3D用的比较简单,但它确实在背后做了很多工作,只是我们没注意而已。

OGRE

OGRE在这方面的支持与Unity3D相比差距比较大,只提供了资源的导出插件;发布的游戏中,可以使用ZIP对游戏资源进行打包,未提供自定义资源打包方式。当然,总体来说,它是一个相当不错的图形引擎,最重要的一点是,它是开源的。