浅析游戏引擎的资源管理机制——扒一扒Unity3D中隐藏在背后的资源管理
游戏中通常有大量资源，如网格、材质、纹理、动画、着色器程序和音乐等，游戏引擎作为做游戏的工具，自然要提供良好的资源管理，让游戏开发者用最简单的方式使用资源。游戏引擎的资源管理包括两大部分：离线资源管理和运行时资源管理。本文仅对前者进行简要介绍，并结合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提供了比较完善的资源管理的功能，使用起来比较轻松。
资源读取（运行时）
在开发过程中，所有原始资源以单个文件形式进行保存，以方便修改，但是在游戏运行读取资源的时候，为了加快读取速度，一般会将资源打包成一个或多个文件。打包的原因很简单，从硬盘中读取文件的时间中，主要由三部分组成：
- 硬盘寻道时间；
- 打开文件的时间；
- 读取文件的时间。
最后一项是不可能改变了，除非使用速度更快的存储介质；但是将多个文件打包成一个文件，可以缩短前面两项的时间。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对游戏资源进行打包，未提供自定义资源打包方式。当然，总体来说，它是一个相当不错的图形引擎，最重要的一点是，它是开源的。
