云风的 BLOG: 游戏开发中美术资源的管理

今天，公司的同事在 popo 群中讨论 svn 管理美术资源的问题。当资源量大了以后，工作起来效率特别低。因为 svn 储存的是压缩过的文件 diff ，对于大文件，计算最终结果的时候比较消耗 cpu 。

我认为 git 会好一些，但是 git 不满足权限管理的需要。不过更换同质工具并没有解决本质问题。就这个，我想了一下。或者应该换个思路，从工具入手，可能会更适合 3d 游戏的开发。当然，前提是，要有足够的引擎开发和改造能力。对现有工具做适量改进。

我希望从模型编辑器入手。这个工具通常是资源处理环节的最底层，直接面向美术人员的生产工具（max maya 等）。资源在这个工具中被转换到 engine 可用的状态，然后在其它开发工具中被加工。

这个工具，或在这个工具之下建立一个层次，制作成 C/S 结构，并直接集成版本管理工具的功能。即，Server 负责收集美术提交的原始资源。最好能直接让美术提交 max 文件，由工具去收集相关的贴图，然后置入数据库。Server 按照 engine 需要，转换制作成 engine 能用的格式。如果要服务于多个 engine 也没有问题。

美术开发人员，通过 tag 去标识他们上传的资源。比如可以自动把作者 id 作为 tag 打上。这些 tag 仅供事后检索使用。Server 同时也负责合并相同共用的贴图等。最终为每个独立资源生成唯一的 uuid 。我想说，这套东西可能很接近 Alien Brain ，但我需要的是和 Engine 其它部分集成的更好的 Alien Brain 。

其它工具在使用资源的时候，一律引用 uuid 。当然，在工具使用过程中，使用者检索资源的时候，是通过 tag 。但底层引用则使用 uuid 。在资源管理的层次的 Client ，除了负责上传资源原始文件外，也负责建立本地 cache ，提交检索请求。甚至提供浏览。一切工具需要加载资源，都通过 IPC 协议去获取数据。也可以退一步，由这个 Client 同步到新版的资源文件，并返回 cache 中的文件名。

当然，最终的游戏也可以通过相同的资源获取协议达到及时网络加载的特性；同样也可以不用这个特性，从由资源管理器最终打包好的资源包中读取。

这个系统设计成和 Engine 以及其它工具尽量功能正交化。适合独立开发维护。本文只是一个思路，设计方案还需要斟酌。

嗯，总结一下需求要点：

美术资源和程序代码不一样。不是每个人都需要一份完整的数据仓库的最新版镜像。需求只在他所维护的一部分素材以及当前项目需要的一部分。而整个美术素材仓库往往很大，没必要同步同步下来。这是和 svn 这样的版本管理工具处理的问题不同的。

美术资源原始素材和最终运行环境用到的数据不同，好比源代码和目标文件。协同开发时，程序员需要其它程序员的源代码帮助编译调错。但美术人员几乎不会用到其它人员的原始文件。因为场景中的一颗树和一张桌子中间没有什么会相互影响的东西。

美术资源大多交叉关联，并非树状结构。一个模型很可能由许多文件构成，但开发人员往往只关心顶层的个体。且在使用这些个体的时候，对它是什么更关心，对它在文件系统的那个位置不太关心。tag 会是对人更友好的检索方法。

开发工具多为自行开发，或有二次开发需求，以适合自己的游戏项目。集成少量资源管理接口难度不大。

Comments

工具很重要，除了AB和Perfoce还有什么可以用的。对一个普通的公司来说，根本没人像去买AB或者Perfoce吧？那就是说我们必须要用万恶的AB7？还是Perfoce 2007？

Posted by: 毛熊熊 | (18) November 12, 2011 11:07 PM

当然对于游戏制作中，一般都有自己的图片或者模型编辑器，这样还是很容易集成进去的。但对于用max或者photoshop这种商业软件，还得另辟蹊径

Posted by: Silence | (17) August 3, 2011 11:35 AM

最近看了一篇关于图像版本控制的文章"Nonlinear Revision Control for Images(Siggraph2011)",它主要针对二进制文件中的图片来进行版本控制，并且集成到了GIMP中，类似的也可以推广到其他的二进制文件如mesh，video中，但它有个缺点是不能做到对一般的图片编辑软件有效，要制作成类似插件的东西集成进图像编辑软件。我在想如果能做成对一般性的图片软件都能适用应该不错，而不是类似插件形式的。

Posted by: Silence | (16) August 3, 2011 11:31 AM

不错，

Posted by: cheap Jordan sneakers | (15) July 2, 2011 04:26 PM

学习了，了解下

Posted by: nike shox r4 | (14) June 19, 2011 11:25 AM

谢谢楼主分享了啊

Posted by: 防水板 | (13) June 11, 2011 02:54 PM

对于非文本的，普通操作人员的二进制文件的版本管理，深有同感。

Posted by: Damon chen | (12) June 10, 2011 02:38 PM

写的不错感谢分享了

Posted by: 启服 | (11) June 4, 2011 11:36 AM

历史记录也是一个问题，有时候某个文件被修改或删除了。过几个月才发现，要想办法找回老版本。alien brain对删除文件的恢复实在不方便。svn管理大量大体积的文件确实又很慢，一个svn st都要等半天。

Posted by: arnan | (10) June 3, 2011 10:40 PM

Git可以用pull来控制权限，某些神圣repo只有特定人来维护会好一些。

Posted by: mikecool | (9) June 2, 2011 11:39 AM

有专门用于美术资源管理的软件，不过是收费的

Posted by: Sparkle | (8) June 1, 2011 03:06 PM

请教一下，为什么说git不符合权限管理的需要？

Posted by: Crhan | (7) June 1, 2011 09:57 AM

我们现在正是这么做的，跟云风老师交流一下版本控制工具用的是perforce，带权限管理的功能，用什么工具不重要，重要的是整个数据流水线流程。首先artist将资源提交到p4上去，然后通过一些CIS工具（我们用hudson）让build machine将这些资源自动导出成engine用的文件，比如maya的模型和动画文件转成fbx文件，并且放到一个服务器上的共享文件夹下，因为美术资源不影响游戏逻辑，programmer和designer没有将资源转到某一版本的需求，他们总是只需要最新的美术数据，所以programmer和designer只需要用工具将共享文件夹下的engine资源更新到本地即可（我们用的是基于beyond compare自己写的插件工具）

Posted by: 鱼雷 | (6) May 31, 2011 08:19 PM

万恶的svn

Posted by: 枫之羽 | (5) May 31, 2011 07:44 PM

svn管理资源确实又慢又没效率，每次checkout光。svn文件比原文件都多，烦躁。

Posted by: Siney | (4) May 31, 2011 04:25 PM

dropbox

Posted by: Anonymous | (3) May 31, 2011 04:20 PM

说个题外话，git的权限管理可以用gitolite

Posted by: 不正直的人 | (2) May 31, 2011 03:17 PM

深有同感

Posted by: makej2me | (1) May 31, 2011 01:39 PM