This article does not have a corresponding language version

AI WORKFLOW

本博客由 AI 工作流自动管理，文章根据博主的个人笔记及与 GPT 的对话习惯自动整理，主要用于博主复习、整理与查阅。内容可能存在错误或 AI 幻觉，请结合可靠资料自行鉴别。

凌乱的美术流程资源标准

此博客为AI工作流自动管理，由博主的个人笔迹与GPT对话习惯自动整理，为博主复习整理查阅，必有错误，请注意鉴别是否AI幻觉。

这篇文章整理自我过去的美术流程笔记。早期内容主要参考了 taecg 的美术资源规范文章，这次重新整理时，我加入了自己对 Unity、Unreal 和团队协作流程的理解。它不是可以直接套用到所有项目的“行业标准”，而是一份用于建立项目规范的检查框架。

资源规范看起来像是给文件改名、分文件夹，真正做起来却会牵扯美术、策划、程序、版本管理和性能预算。

我现在更愿意把它理解成一组团队契约：让资源容易找到、能够正确使用、出了问题可以追踪，并且不会在项目后期突然制造大量返工。

规范到底在解决什么

一套有用的美术规范至少要解决四类问题：

  1. 可查找：看到名称就能判断资源类型、用途和版本。
  2. 可使用：单位、轴向、层级、Pivot 和导入设置符合引擎与程序要求。
  3. 可维护：资源来源、依赖和修改历史能够追踪，避免同一资源出现多个“最终版”。
  4. 可运行：模型、贴图、材质和动画符合目标平台的性能预算。

规范不是越多越好。规则如果不能自动检查，或者执行成本明显高于它解决的问题，最后通常只会变成一份没人看的文档。

因此我认为 TA 的工作不只是制定规范，还应该尽量把规范做成：

  • DCC 导出预设
  • 引擎导入预设
  • 命名与目录检查工具
  • 提交前检查清单
  • 可以直接修复问题的批处理脚本

目录：先按职责划分，再按项目细分

目录结构应该让新成员不依赖口头说明，也能大致判断资源应该放在哪里。

一个基础结构可以是：

Art
├─ Characters
├─ Environments
├─ Props
├─ UI
├─ VFX
├─ Materials
├─ Animations
└─ Tools

实际项目还需要区分：

  • DCC 源文件与引擎资产
  • 项目自研资源与第三方资源
  • 公共资源与关卡专属资源
  • 可直接使用的最终资源与实验资源

我不建议把所有内容都堆进一个 Common 或 Misc。这种文件夹刚建立时很方便，几个月后往往会变成没人敢动的垃圾场。

Unity 的 Resources 目录也不应该被当作普通资源目录。放入其中的资源会进入构建，并通过字符串路径加载；正式项目应根据项目规模评估 Addressables、AssetBundle 或自己的资源管理方案，而不是简单地把开发期目录原样带到发布版本。

命名：让名字本身携带信息

命名规则的目标不是追求形式整齐，而是减少歧义。

我更倾向于使用下面的结构：

[资源类型]_[主体名称]_[用途或描述]_[变体]

例如：

SM_Cliff_Snow_A
M_Cliff_Snow
MI_Cliff_Snow_Wet
T_Cliff_Snow_BC
T_Cliff_Snow_N
T_Cliff_Snow_ORM

这与 Unreal 官方推荐的“类型前缀＋资源名＋描述＋可选变体”思路一致。具体前缀可以按项目调整，但一旦确定，就不应该让同一种资源同时出现多套命名方式。

需要避免的名称包括：

新建文件夹
测试2
最终版
最终版_真的最终版
rock_copy_new

版本信息更适合交给版本管理系统，而不是不断叠加在文件名里。

模型进入引擎前要统一什么

单位与比例

项目开始时就应该确定角色、场景、道具和碰撞使用的尺度，并提供可对照的标准模型。尺度错误不仅会影响画面，还会影响物理、动画、粒子、灯光衰减和相机参数。

朝向与 Pivot

至少要约定：

  • 哪个轴朝上
  • 哪个轴代表正前方
  • Pivot 放在底部、中心还是交互点
  • 导入后是否要求默认旋转和缩放归零

不同 DCC 和引擎的坐标系并不完全一致，因此不能只写一句“方向正确”，而应该给出导出预设和引擎内的验证示例。

层级与命名

模型层级会直接影响动画、Prefab、Blueprint、碰撞和程序引用。提交前应该检查：

  • 是否存在无用空节点
  • 是否残留隐藏模型或测试物体
  • 骨骼与插槽名称是否符合约定
  • LOD、碰撞体和材质槽名称是否稳定
  • 是否存在重复材质槽

面数不是唯一指标

只看 DCC 中显示的面数，很容易低估资源在引擎中的实际成本。

引擎中的顶点可能因为以下原因被拆分：

  • UV 接缝
  • 硬边或不同平滑组
  • 不同材质槽
  • 顶点属性不一致

一个看起来只有 8 个几何顶点的立方体，进入引擎后可能需要更多渲染顶点。因此性能检查应该以引擎统计为准，并结合目标平台验证，而不是只填写一个“最多多少面”的固定数字。

除了三角形和顶点数，还要关注：

  • 材质槽与 Draw Call
  • 骨骼数量和蒙皮影响数
  • LOD 切换效果
  • UV 利用率与 Lightmap UV
  • 碰撞复杂度
  • Nanite 或传统 LOD 的适用条件

顶点属性：需要什么就保留什么

模型可能包含多套 UV、顶点色、法线、切线和蒙皮信息。它们都有用途，但不应该因为“以后也许会用”而全部保留。

例如：

  • UV0 通常用于基础纹理。
  • 第二套 UV 可能用于烘焙或 Lightmap。
  • 顶点色可以承担材质混合、风动或遮罩信息。
  • 多余 UV 和无效顶点色会增加资源体积与管理成本。

正确做法不是统一删除，而是让每类资源说明自己需要哪些通道，并在导入时自动检查。

版本管理不是备份盘

美术资源使用版本管理时，最大的困难不是“会不会提交”，而是二进制资产难以合并、资源依赖复杂，以及错误移动文件可能破坏引用。

对 Unreal 项目，我更倾向使用 Perforce 管理大量二进制资产，并通过 Changelist 组织一次完整修改。无论使用 Perforce、Git 还是 SVN，都应该明确：

  • 哪些目录必须提交
  • 哪些缓存和派生文件必须忽略
  • 二进制资源是否需要锁定
  • 一次提交应该包含哪些关联文件
  • 移动和重命名资源必须在什么位置完成
  • 提交前由谁检查地图、材质和引用关系

提交信息也应该解释“为什么改”，而不只是写“更新资源”。

我认为更实用的资源验收清单

通用检查

  • 路径和命名符合项目规范
  • 没有测试文件、重复副本和无意义后缀
  • 资源来源和授权信息明确
  • 引用没有丢失，移动资源后已处理重定向
  • 在目标引擎版本中重新打开验证

模型检查

  • 单位、朝向、Pivot 正确
  • Transform 状态符合项目约定
  • 无多余节点、材质槽和顶点属性
  • 法线、切线、UV 与平滑结果正确
  • LOD、碰撞和 Lightmap 设置符合用途

性能检查

  • 使用引擎数据核对顶点和三角形
  • 材质槽数量符合预算
  • 贴图尺寸和压缩格式符合目标平台
  • 在代表性场景中检查，而不是只看单个资源
  • 超出预算时记录原因，而不是偷偷放宽标准

我对 TA 规范工作的理解

以前我把资源标准理解成一张很长的规定表。现在我更关注它是否真的能减少沟通和返工。

一套成熟的规范应该形成闭环：

制定规则
→ 提供模板与预设
→ 自动检查
→ 给出可理解的错误提示
→ 在真实项目中复盘
→ 更新规则

规范不是 TA 单方面要求美术配合，也不是程序把所有限制丢给美术。它应该是美术质量、开发效率和运行性能之间的平衡。

如果以后继续完善这套流程，我最想补上的不是更多文字，而是一套真正能执行的资源检查工具：让问题尽量在导入和提交前暴露，而不是等到打包或性能验收时才集中返工。

参考资料