Why Omoospace?

稍微有复杂度的工作，往往不止一个文件。当文件过多，就需要文件夹去归纳它们。好的文件夹结构可以帮助回顾项目。应该如何设计文件夹结构呢？

应该考虑的点

不同工作流的共性

所有的创作类工作的文件都可以被归到这两大类：

• 资源型文件 指图片、音频、视频、模型等这类被引用、导入的文件
• 制作型文件 指制作中的，软件专属格式的文件

另外，所有的工作流，都可以抽象成这样的一个结构：

graph LR
资源 --> 制作 --> 资源 

软件自带的方案，互相不兼容

能资源导入的软件，大部分会自带整理资源型文件的功能，例如:

• After Effect 的 Collect Files
• Blender 的 Pack Resources
• Cinema 4D 的 Save Project with Assets

还有的软件会提供创建项目文件夹的功能，例如:

• Maya 的 Set a Project
• Houdini 的 $JOB。

这类功能确实很棒，但是问题在于各家整理方式不同，生成的文件夹结构也不同。这导致，一旦需要多软件协同，就难以互相兼容。

需要地方记录一些信息

归档的项目，用新版本软件打开很可能会出错，所以需要一个地方去记录当时用的是什么版本。 除此之外，还有参与的人员、作品的信息，项目的客户等等都可能需要记录

要维护，但尊重懒惰

少有人能坚持维护复杂的项目文件夹，也不会有很多精力写注释，所以如何以最小的操作量来完成项目的“自释”显得尤为重要。为此，我认为可以做这些：

• 文件名替代注释。
  不可能给每个文件写说明注释，那么就要求文件名足够直白清楚，名字是最基础的说明。   

• 用前缀和后缀来补充说明。例如：

  • Sc010_的场景编号语境前缀
  • .v001的版本修饰后缀
  • .480p的分辨率修饰后缀
  • .low低面数修饰后缀

• 统一输出路径。例如：

  • 渲染的输出路径都统一在 Renders 下
  • 视频剪辑的输出路径都统一在 Videos 下。

• 不重要的，接受混乱。
  但反之，如果重要，那么也别太随便了，不然苦的未来的自己🥲

太随意导致引用失效，太固定又不灵活

我们先看下面这种情况

项目根目录/
├── 道具01/
│   ├── 道具01.blend      # 被引用的资源型文件
│   ╰── 道具01.WIP.blend  # 建模中的制作型文件

随着道具资产变多，我想把道具01/文件夹放进资产/文件夹。但如果这样做，引用道具01.blend的其他文件势必会出现引用丢失。这就要求从一开始就预判到后面的情况，提前定好资产/文件夹。

有没有可能兼得灵活性和稳定性？在项目刚开始能轻装上阵，随着项目扩大再逐渐把文件夹结构变复杂，但同时又能不导致引用问题。

Omoospace 心法

眼下，没有一个单一软件能覆盖所有工作流，而且工作流也因为技术迭代一直在变化中。需要一个统一的方式去指导如何存文件到硬盘，由此，Omoospace 心法诞生。

隔离资源型文件和制作型文件

为了解决上述中“灵活和固定”的冲突，核心点在于，谁需要灵活？谁需要固定？

没错！答案很清楚：资源型文件需要固定，而制作型文件需要灵活。它们在一起势必会导致矛盾。迁就静，就导致文件夹结构死板。迁就动，就导致引用失效。因此，他们需要分开放。这就是 Omoospace 的核心思想。

仅指导方向，提供合理依据

Omoospace 不提供具体的结构，更不是管理工具（虽然有插件协助）。它更像是一个心法，在你疑惑该以何种方式摆放文件时候，提供一个方向。它只有四条法则：Omoospace 心法