云风的 BLOG

如果公司有多个成熟的类似项目，整个美术的制作流程被流水线化了。那么久而久之，自然有一套目录结构和命名规则的规范可以遵守。但是由于项目的多变性，而技术的改良，这个规范也不是一成不变的。

这里说的技术，不能狭义的看成是 3d 渲染技术。关于资源的管理，复用等也是 3d engine 技术的一部分。

最近的一段思考，让我觉得，强制的目录结构在制作流程流水线化的同时，带来了极大的不便。很少有美术会在制作工程中严格遵守目录结构和文件命名规则。实际上，都是最后将文件按规范复制到指定的位置。这和我们程序可以自然的在 cvs 或 svn 下在仓库的一支下工作是不太一样的。

而我们 client 在运行时调度资源时，大多不太关心文件在目录结构中的实际位置，而更关心的是相关文件的互相关联关系。而资源文件的打包，完全可以丢失所有文件名和路径信息，给文件赋予唯一 id ，再记录下发生关联的文件的关联信息就够了。所以，原始的文件目录结构状态和文件名的规范，并非必要的。

我们现在采用的方法是，给资源文件定一个 root ，定位方法可以效仿 bjam 。bjam 在 root 目录下放置一个特殊文件名的文件叫 project-root.jam 。任何一个文件需要描述一个关联文件的时候，都先逐级向上找到 root 的位置，然后关联文件均以 root 开始为路径记录位置。这种以 root 开始定位的方法，比相对当前路径定位有不少好处，这里不展开叙述。

如果是小项目，一个美术来制作所有的资源，那么作为个人其实既然会按某种规范来组织文件。如果有几个人，我们可以每个人自己建一个以自己名字为名的资源路径，放在 root 下。如果需要引用别人的资源，尽可以通过同事的名字去找到。比如 B 的模型用到 A 的贴图，而 A 把贴图都放在他自己的 texture 目录下，那么 B 就可以链接 A/texture/xxx 去使用 A 的贴图。为了防止使用别人的资源，而得不到资源被删除或移动的通知。我们可以再每次引用文件时，同时记录下被引用文件的 MD5 。在产品发布，资源打包时，去掉这些校验信息即可。

这样，资源路径下，第一级目录则是每个制作会维护人的名字作为索引。再往下才是更细的分类。每个人可以拥有不同的分类方案。每个人维护自己的作品，这是一种人性化的做法。

把最终发布版的资源管理，交给文件打包和操控的模块吧，它们将把以原始字符串映射(目录/文件名)的资源改变成另一种更为高效的资源检索方式。我想这也是 google 搜索替代以前 yahoo 式网络分类目录的一种精神的体现 :) 至于具体的方案，和待解决的问题，这里就不再细说了。