This article does not have a corresponding language version

凌乱的美术流程资源标准

参考来源：taecg - 知乎，不用于商业盈利，仅供个人学习复习。

首先，在项目的前期，TA 是需要制定很多标准的，大致可以分为：

  1. 美术资源的标准化，方便管理
  2. 美术资源符合策划与程序要求的规则，这样便于他们使用，当然这里也并不是说要一味的去满足他们的需求，同时也要为美术考虑，不能给美术增加过多的工作量，这中间的平衡点要把握好
  3. 美术资源性能方面的优化标准，这点很重要，一不小心就容易出现大量返工的情况，这会给项目带来很大的成本开支以及延长开发周期

所以前期的标准制定非常重要。

项目的文件夹结构

文件夹结构相当于建筑的地基，如果没有打好，楼是不会倒下，但是会让建筑工程师们建造的很痛苦。

文件夹结构示例

Assets 是资源根目录，我们将美术需要用到的文件夹分成两大类：

1. 原始资源文件，存放在 Assets/Arts 目录下，这里的"原始"并不是指 .max 或者 .ps 之类的文件，而是指资源导入引擎后的原始文件。在 Arts 目录下可以按美术工种模块来分为：

  • UI（界面）
  • Character（角色）
  • Map（关卡地图）
  • Fx（特效）
  • Shader（着色器）
  • TA（技美）
  • Sounds（音效，要不要放在美术文件夹根据各个项目需要）
  • ThirdPlugins（第三方插件）

每个文件下又可按自己项目的需求再细分多个文件夹。其中 TA 中主要用于存放 TA 为项目开发的插件以及脚本之类的。

2. 程序调用资源，存放在 Assets/Resources 目录下，命名为"Resources"的文件夹（可多个）会被 Unity 自动识别，我们可通过 Resources API 在程序运行时进行资源加载与卸载。有一点要注意的是，Resources 目录下的所有资源都会被打包进游戏中，不管实际有没有用到，另外如果资源过多，也会大大的影响游戏打包时间与游戏启动时间。所以此目录内的内容最好事先与程序协调沟通好如何存放需要的资源。

推荐做法

在正式项目中，官方也是不推荐存在 Resources 文件夹的，但是在开发期间保留 Resources 目录便于调试，打包后游戏运行时采用 AssetBundle 的加载方式。也就是说需要程序在开发期间支持两种模式，打包时删除 Resources 目录（此时 Resources 目录中的资源全部打 AB 包）。

命名规则

资源本身的命名也是非常重要的，特别是 Prefab 的命名，因为游戏内使用某个美术资源时就是通过加载 Prefab 来实现的，至于说是直接加载还是通过策划配置成相应的 ID 来加载，这个要看程序怎么规划。总之不管哪一种，命名统一、方便、直观，将给项目带来很大的便利性。（这个非常重要）

  1. 命名中尽量只包含英文字符与数字，以及 _（下划线）和 .（主要用于动画片断识别）。其它符号尽量不要出现
  2. 大小写统一，常用的有小驼峰和大驼峰：
    • 小驼峰：第一个单词首字母小写，其它单词首字母大写，如 myTestExample
    • 大驼峰：每个单词首字母都是大写，如 MyTestExample
  3. 语义清晰，看到文件命名时能直观知道这个资源是什么。可以用拼音也可以用英文语义，根据过往经验，大多美术英文都不太好，不如索性直接用拼音，只要大小写统一定好，在阅读命名时会轻松一些

团队协作

在团队合作开发的项目中，最常用的协调工具就是 SVN 和 Git（现在虚幻项目太大，可以使用 P4V 管理方便）。很多美术对这类工具不太熟悉，作为 TA 要耐心地教一下他们，否则在项目进行的过程中会出现各种各样的状况需要补救。

有一点要重点说明：一定要保证美术提交到 SVN 或者 GIT 上的资源符合之前定的标准。建议 TA 为美术制定一些批量处理工具，或者制作一个提交 SVN 时进行资源检测的工具，如果有哪个资源不符合标准则进行提示，并且不能提交。虽然霸道了点，但是真的很有必要！

模型篇

先来梳理下模型进入游戏的整个工作流程，然后再依次分析有哪些标准与规则：

  1. 美术在 DCC（Digital Content Creation，数字内容创作）软件中进行模型创作
  2. 制作完成后，从 DCC 软件中导出 FBX 格式
  3. 导入 Unity 引擎并设置导入的相关选项
  4. 生成 Prefab 供程序使用

从以上流程可以看出，游戏最终使用的是模型的 Prefab（不用 Prefab，直接上模型行不行？答：可以，但是你一定会后悔的！）。所以先与程序讨论确定 Prefab 是以什么样的内容给到程序的，比如层级结构、文件命名、组件都需要添加哪些等等。不过这块标准与模型本身的关系不是特别大，更多的是 TA 与程序间的标准确认，Prefab 所引用的原始资源才是 TA 的重点关注对象，这其中又大多与性能优化息息相关。

单位统一

在项目之初首先要定的就是模型单位，如果单位没有统一，那么在引擎中的比例就会不一致，这会给项目带来很多后续的烦恼。

在 Unity 中其实是没有实际单位的，如果我们设置游戏内 1 米 = 1 个单位的话，这恰恰与 Unity 内的物理系统所期望的正确结果保持统一。所以想要单位统一的话，只需按上面的进行设置即可。

方向

单位说完，我们再来说下方向，方向不统一的话会导致 Prefab 上的旋转值很混乱，这就会给程序带来诸多不便。

方向其实就是坐标轴，在定方向前我们先来了解下两个概念：

  • 左手坐标系：左手的大拇指表示 X 轴正方向，食指表示 Y 轴的正方向，中指表示 Z 轴的正方向
  • 右手坐标系：右手的大拇指表示 X 轴正方向，食指表示 Y 轴的正方向，中指表示 Z 轴的正方向

Max 是右手坐标系，而 Unity 是左手坐标系，两者不能完美转换，总是会有一个轴是反过来的。

我们回到 Unity 中定下我们想要的结果：Y 轴朝上（头顶方向），Z 轴正方向是前方（人物朝向）。

然后回到 Max 中，以茶壶为例，壶嘴表示前方，按以下步骤进行操作：

  1. 先将坐轴系设置为 Local，我们只需关心模型的自身坐标轴
  2. 在层级修改面板，点击 Affect Pivot Only，旋转茶壶的坐标轴，将其调整为 Y 轴朝上，Z 轴朝壶嘴方向
  3. 退出修改，塌陷几何体，并导出
  4. 导入 Unity，直接将模型拖入场景并将其 Rotation 全部归为 0
  5. 完成，这样方向既保证了正确性，Transform 组件中的 Rotation 也都是默认的 0

顶点数与面数

这点与优化息息相关，可能有些同学觉得只要控制好面数就行了，其实不然，顶点数也很关键。

在渲染一个模型的时候，Shader 层面会有两块计算量：一个是顶点着色器，一个片元着色器。顶点数越多，顶点着色器消耗就越大。

在 Max 中创建一个 Cube（长宽高段数都为 1）并导入 Unity 中，与 Unity 中默认的 Cube 对比：

  • Max：顶点数 8，面数 12
  • Unity：顶点数 24，面数 12

面数一致，为什么顶点数多了这么多？

  1. 模型的 UV 顶点数增加会直接导致引擎中顶点数增加，因为同一个顶点被切成多个 UV 点时，在引擎中会被认为是多个顶点
  2. 不同光滑组的面会导致它们的共用顶点属性信息不能共享，所以在引擎中也会被认为成多个顶点。但如果这些面虽然光滑组不一样，却又是在一个平面上，只是被强制设置成光滑组不一致，引擎会自动优化，从而不会产生额外的顶点数
  3. 如果某 1 个顶点，它既是多个 UV 点，也是两个不同光滑组的共用顶点，那么它在引擎中会是 2 个顶点，而不是 4 个
  4. Max 与 Unity 显示的顶点数原理不一样，请以引擎为准

所以回到一开始的问题：因为 Cube 有 8 个顶点，每个顶点会在 UV 中被分成 3 份，所以在引擎中就是 8 × 3 = 24 个顶点。

顶点属性

每个顶点上可以存储多个属性信息以便在引擎中使用。从模型上来讲，属性信息越少就代表着模型的容量越小，同时它所占用的内存也就越小。所以要明确模型应该带有什么属性，不需要的都要清除掉，保证美术资源只含有必须要的内容。

Unity 中模型上可以认到的属性：

属性 说明
顶点数、面数 模型的基本属性，必有
UV1 不可缺少，否则无法显示贴图
UV2 需要烘焙的模型必须有，可自动生成或 DCC 中制作；不需烘焙则清除
UV3 / UV4 大多情况下用不到，建议清除
顶点色 用法较多，有需要则保留，没有则清除
法线 / 切线 可在 DCC 中生成或在引擎中自动生成

有些属性在引擎中是不能清除的（只能通过插件修改本地 FBX 文件），比如 UV 和顶点色，所以如果要清除只能回到 DCC 中清除完后再导回来。这也是前期定好标准的好处之一，避免了今后做优化时美术更改的痛苦。

清除掉 100KB，在量级堆上去了之后这些优化也可以省下不少内存，尤其是移动端，内存寸土寸金。