一套学生团队的 USD Pipeline：Maya → Solaris → RenderMan + Tractor

原文（英文）：https://mateomarie67.wixsite.com/mateomarie-portfolio/usd-pipeline-presentation-en
作者：Matéo MARIE（与 Raphaël GIMARD 合作）

这份分享讲的是什么

这是一份偏“落地经验总结”的 USD Pipeline 说明：作者团队在 ESMA 毕业短片 Spurs Out、Ratzia 的制作中，围绕 USD / Solaris / RenderMan / Tractor 搭建了一套从资产到镜头的流程，并把几个关键环节做成模板与脚本，降低重复劳动。

他们使用的软件版本大致为：

Maya 2023
Houdini 19.0
RenderMan 24.4
Tractor 2.4

一眼看懂：流程分段

1) 建模与 UV：从 Maya 导出 USD（先学结构，再做优化）

作者团队在 Maya 完成建模与 UV 后直接导出 USD。为了更快理解 USD 的结构，他们一开始选择导出 ASCII（.usda），这样可以用文本编辑器直接观察层级、属性与写法。

导出时他们做了几件“顺手就该定死”的事：

• Output 选择 USD File Format（ASCII）
• Subdivision Method 直接设为 Catmull-Clark
• 取消 USD Preview Surface（从 Maya 侧导出时意义不大）

另外一个比较真实的坑：Maya 不能直接把 USD 写到他们的服务器路径上，所以需要先导出到本机，再复制到项目目录。

2) LookDev：Standard 模板 vs Component 模板

作者在 Solaris 做了两套 LookDev 模板，分别对应两类场景：

2.1 Standard LookDev：适合“单个资产”制作与材质分配

核心思路是把一套固定动作模板化：

• set project（依赖 $JOB 等变量）
• 缩放：把 Maya 的厘米制统一到 Houdini 的米制（scale / 100）
• Material Library 里建 shader
• Assign Material 分配材质
• 输出 USD，供后续 set dressing 使用

2.2 Component LookDev：为“可重复摆放 + 可变体”而设计

第二套模板走的是 Component 思路：让资产天然具备“可被批量摆放、可做材质/几何变体、可用 proxy/hires 切换”的结构。

他们强调了几个关键点：

• 在 Component Geometry 阶段准备 proxy（轻网格）
• 变体主要使用 材质变体（一个材质变体对应一个 Component Material 节点）
• 输出阶段用 Component Output，同时把结果加入 Layout Asset Gallery（Asset Gallery 只存路径，不存数据本体）

由于他们还想在摆放阶段做 Physics（碰撞堆叠等），他们没有用“几何变体”，而是把不同形状直接当成不同对象导出；每个形状再各自挂材质变体。这样资产数量会变多，但摆放更稳定。

3) Set Dressing：结构比技巧重要

Set Dressing 他们没有给“固定做法”，而是强调一个观念：先把层级组织清楚，再考虑工具与节点。

举例来说：

• Kitchen 是父级
• Table / Chairs 是子级
• Plates / Forks 再挂到 Table 下

这个阶段最怕的是“先把东西摆完再补结构”。一旦进入镜头迭代，层级混乱会直接把协作与复用成本拉爆。

4) 绑定与动画：Maya 做动画，USD 用作“可回流的布景”

动画仍在 Maya 完成，但团队希望动画师拿到“正确的布景”。因此会把 Set Dressing 导出的 USD 回导回 Maya：

1. Houdini 侧把 set scale ×100（从米制回到 Maya 厘米制）
2. 用 USD ROP 导出（优先 .usd，比 .usda 更省空间）
3. Maya 里通过：Create → Universal Scene Description (USD) → Stage From File 导入

他们还给了一个“可回流修改”的工作方式：如果动画师要微调布景附件位置，就在 Maya 里创建并保存一个只记录改动的 USD layer（sublayer），灯光阶段再把这个 layer 合进来。

这套方式很实用，但也带来一个现实问题：如果 Maya 仍不能直接写服务器路径，就会出现“改动 layer 保存到本机，再靠人为共享”的协作风险。

最后，作者提到：由于 Maya 的 USD 还不够完美，而 Solaris 对 Alembic 支持很好，所以动画输出统一用 .abc，并用脚本封装 Alembic 导出参数，减少误操作。

5) Groom / Cloth：用 USD 序列缓存换取分布式渲染效率

他们在 Houdini 做 Groom。导出时没有去追求“一个大文件”，而是把 cache 输出成 USD 序列（每帧一个 USD）。

文件数量会很多，但在分布式渲染场景下，避免了单个大文件加载过慢、甚至引起瓶颈的问题。其他仿真也采用同样方式输出。

6) Lighting：模板化导入 + Flatten stage 解决农场卡死

灯光阶段他们同样做了模板，把“重复性导入”交给自动化：

• 快速导入动画提供的 Alembic
• 导入镜头级 Groom/Cloth/Sim
• 通过 take list 管理 render layer（BG/MG/FG/角色层等）

在准备送农场之前，他们会把 Groom caches 临时移除（后面再挂回），并且按 每个 render layer 输出一份 flatten 后的 USD：
flatten 的结果不再引用其他文件，渲染侧只需要加载“自包含”的 USD。

他们这么做的直接原因是：渲染农场里出现过“每张图卡在 98% 不动，需要手动重启”的问题。flatten 能显著降低引用链复杂度，从而减少这类阻塞。

7) Batch：统一批渲模板 + 清理 ghost husk

Batch 模板的思路和灯光模板一致：尽量让“找文件、组装镜头”自动化。

他们提到一个关键节点（Charger_TOUT）：通过搜索对应 shot 的文件，把场景大部分内容快速搭起来；Groom caches 在此阶段“永久回收并挂回”，然后按需要把每个 Groom 的 Graft Stage 放到正确的 render layer（否则可能出现“角色有影子但秃了”的尴尬）。

另外，他们在 Hdprman 节点里嵌了 Python 脚本，主要用来处理一种非常具体但很常见的现象：批渲卡死后残留 ghost husk，即使 resume 继续跑，旧的 husk 进程仍占用 CPU，堆积起来会把机器拖垮。脚本用于在必要时清理残留进程，避免 CPU 被“幽灵任务”吃掉。

8) Tractor 与工具开发：把“送渲染”从手工变成按钮

作者认为 Tractor 集成是他们这套流程里最难、但也最关键的一段：
Houdini 19.0.589 + RenderMan 的组合，没法把批渲请求顺畅地直接发送到 Tractor Dispatcher，只能用很笨的方式“一张一张发”。于是他们做了一个 Solaris Batch Utility：

• 解析 Houdini scene、识别渲染节点
• 生成并发送 hbatch 命令到服务器
• 通过拆分子场景避免多机读写冲突

他们一开始用 husk 直接渲 .usd，但发现对帧段范围不好控制；最终改成：用一个专门的 Houdini 场景引用 USD，然后用 hbatch 跑，hbatch 每帧再派生出 husk。实现上更绕一点，但流程更稳定。

工具安装上也很现实：Windows 环境里用 Install_env_02.bat 安装依赖；需要 pip 安装 PyQt5；同时必须把 Houdini bin 加到 PATH，才能调用 hython/hbatch/husk：

path=C:\Program Files\Side Effects Software\Houdini 19.0.589\bin

8.1 Tractor 优化：自动识别卡死、自动归档、自动重试

在“能跑起来”之后，他们又做了三类维护脚本：

1. 检测“看起来在跑但实际卡死”的 batch，并自动重启
2. 自动找出 Done 的 batch，检查日志，无误则归档，有误则重跑
3. 对 dispatcher 标红的任务做自动重试

8.2 CPU Limiter：让本机算得动，也让人能继续工作

最后一个工具是 CPU Limiter：当本机正在跑 mayabatch / husk 这类进程时，按策略自动调整核心占用，避免“机器算着算着，人完全没法干活”。同时还包含 Nimby 状态控制、批量 kill 等能力；当 30 分钟无人操作时恢复 100% 性能。

结尾：这套流程的价值不在“多复杂”，而在“把重复劳动收起来”

这份分享并没有刻意追求“最前沿”的架构，而是把大量制作中真实发生的卡点——导出限制、跨软件尺度、渲染农场卡死、任务残留、维护成本——一件件用模板和脚本收敛。

如果你也在做 USD/Solaris 的流程建设，我觉得它最值得参考的点有两个：

1. 模板先行：让团队成员进入同一条“正确轨道”，减少隐性差异。
2. 把维护自动化：农场稳定性不是靠“手工盯着”，而是靠脚本把常见故障处理成“默认行为”。