摘要
在采用 USD 后不久，Walt Disney Animation Studios（WDAS）便开始探索，并随后将其基于 Maya 的遗留灯光工作流迁移到 Houdini Solaris。本文介绍了这一历程与演进，从原型到首次在长片制作《Moana 2》中投入使用期间的工作流与工具开发。我们将讨论从最初的 MVP 工作流到如今所使用工作流之间的经验教训与调整。
灯光工作流以及向最终画面的演进
1 引言
自 2009 年以来，Disney Animation 一直使用一款名为 DLight 的专有工具。该工具对 DCC 不设限制，但具有功能强大的 Maya 插件。DLight 提供了一整套自定义工具，用于制作材质、灯光以及仅适用于我们专有渲染器 Hyperion 的灯光附件。我们用于灯光制作的主要 DCC 是 Maya，并与 DLight 结合运行。
DLight 一次只处理一个镜头，这要求艺术家若想同时为多个镜头打光，就必须分别管理多个独立的 Maya/DLight 会话。由于这种单镜头范式，艺术家依赖传播工具在镜头之间复制数据。当关键灯光镜头完成后，艺术家会将数据传播到每个子镜头。传播是一种单向的、破坏性的编辑方式，艺术家无法轻松共享额外修改，除非手动导出并导入有选择的变更。
灯光模板
鉴于现有基于 Maya 的灯光流水线的局限性，以及工作室自 2020 年起向 USD 的转型（Miller et al.）和 Vo et al. 中提到的其他更新，我们得以获得新的机会，去利用那些内建 USD 支持的商用 DCC。
2 背景
在评估 Lighting 和 Look 的解决方案时，我们仔细考虑了 Katana 等业界标准选项，同时也考虑了工作室对 Houdini 日益增长的采用程度。多年以来，我们曾多次评估 Katana，但鉴于我们已建立起基于 DLight 的工作流，Lighters 始终认为它吸引力不足。为了支持 Katana 而重构内部系统所需的成本和复杂度，并没有带来足够有说服力的收益。此外，我们也有意维持一个精简的多 DCC 流水线，倾向于避免在非必要情况下再引入一个重要的 DCC。在评估当时，Katana 也缺乏完整的原生 USD 制作能力——这一点直到较近的 Katana 7.0（2023）才有所改善。
由于 Walt Disney Animation Studios 在动画制作中采用了 Pixar 的 Presto，我们也与 Pixar 就其在 Presto 内进行灯光制作的项目 Luna 进行了交流。我们与开发团队会面讨论了 Luna 的时间线，但很明显，它无法在我们所需的时间窗口内准备就绪。此外，采用 Luna 可能意味着对我们的 Material 系统和 Render 流水线进行重大改造，因此在当时并不适合我们的需求。
相比之下，Houdini Solaris 已经集成到我们的流水线中，并且由于现有 USD 基础设施的存在，开发投入更低。它从一开始就提供原生 USD 工作流，也与我们的内部能力高度契合。我们强大的内部 Houdini 专业能力以及与 SideFX 的紧密合作进一步强化了这一决定。Houdini 也非常适合随着艺术家经验水平的提高而扩展——灯光艺术家可以使用或扩展 Solaris 的灯光工具，而技术艺术家则可以轻松构建部门工具。该应用的多功能性支持多个部门在同一环境中协作，鼓励知识共享，并在部门之间培养共同语言。
作为一个基于节点的制作系统，Houdini 还使艺术家能够以类似合成工作流的方式工作，并在更高层面理解镜头中的数据流。此外，随着 2022 年大量来自 Katana 和 Houdini 背景的新艺术家加入，Solaris 被认为具有更平缓的学习曲线。随着健壮的多镜头工具和工作流的发展，它已被证明是适合我们工作室、可扩展且面向未来的解决方案。
3 实现
最早的实验始于 2020 年，当时测试是在生产流水线之外进行的，使用的是展平后的 USD 数据、原生 Houdini 和 Karma。灯光艺术家对一个试点工作流进行了可用性测试，这促成了继续推进迁移的决定。在 Houdini 中构建新的 Lighting 工作流与工具集，最初计划分为两个阶段，但最终发展成三个阶段。Walt Disney Animation Studios 的《Moana 2》将成为首个采用这一新工作流的制作项目。
3.1 版本 1：原型
由于许多艺术家都熟悉旧版流水线，我们最初的尝试重点放在将 DLight 中的工具和小部件迁移过来，并模拟基于 Maya 的工作流。我们使用节点模板，为旧的 DLight 工作流提供熟悉的工作区域（图 2）。灯光工作通常按 packet 进行，即一组位于相似位置、具有相近摄影机角度的镜头。为了帮助进行 packet 工作流，我们构建了一个工具，帮助用户生成包含多个镜头的模板。
我们利用一个“mirror stage”，使现有来自 DLight 的 QT 小部件能够在 Solaris 中运行，而无需为 Houdini 重新实现。我们会在内存中保存一个“mirror stage”，它是当前节点 stage 的一个可编辑副本。工具小部件会在这个 stage 上捕获编辑，然后我们会在 Houdini 网络中注入一个内联 layer edit 节点。
为了更好地与 Solaris 的内建特性集成，我们将自定义灯光 schema（它们不使用 UsdShade）迁移为派生自 UsdLux。这样一来，我们便可以直接利用更多 Solaris 的现成功能。
3.1.1 挑战
这一套工具在早期采用时，很快暴露出三个重大挑战：
- 性能
- cooking 不稳定
- 无法利用 Solaris 更多的内建能力
从艺术家测试中可以明显看出，性能和稳定性不足以支撑在最高生产效率下完成一个制作项目。运行在 Solaris 中的原始 DLight 工具表现出与程序化网络不一致的行为，这给艺术家带来了困惑。距离《Moana 2》交付只剩一年多一点的时间，我们必须退一步，并且必须迅速行动。
3.2 版本 2：重构
LightBox
为了加强与 Solaris 以及 Houdini 生态的集成，我们调整了方向，弃用了来自 DLight 的既有 QT 小部件，转而将材质和灯光制作工具重新实现为带有 Houdini 原生参数界面的 HDA。这样一来，我们总体上可以避免使用 mirror stage，从而提升性能和稳定性。此外，这也使我们能够利用艺术家所期待的 Houdini 小部件行为，例如参数引用和表达式。尽管 UI 不如我们先前的工具那样精致或熟悉，但它们为艺术家交互和整体工作流带来了更自然的 Houdini 外观与使用感受。
限制我们利用现有 Solaris 特性的因素之一，是我们的灯光 schema。由于 Disney Animation 使用自己的 BRDF，且不使用 shading networks，我们的材质和灯光使用的是自定义 schema。这样做实质上使 Solaris 的部分能力对我们的 Lighters 不可用。为了开放这些功能，我们决定让灯光 schema 继承自 UsdLux。虽然那些专门面向 UsdShade 的功能依然不适用，但许多基础灯光操作已经可以使用。派生自 UsdLux 还将使我们能够在未来的 Houdini Solaris 和 USD 功能及版本发布基础上继续构建。
3.2.1 挑战
尽管针对单个灯光的制作和编辑在性能与用户交互上得到了改善，但艺术家在快速批量编辑灯光方面依然遇到困难，而这正是他们在此前 DLight 工作流中习以为常的操作方式。为了提升艺术家的迭代速度和使用体验，还需要做更多工作。我们意识到，有必要扩展工具集，加入艺术家在 DLight 工作流中所具备而当前缺失的能力，例如同时创建和修改多个灯光、使用一个工具将场景中的所有灯光汇总查看，以及访问一些有价值的旧版功能。
3.3 版本 3：可投入生产
我们的最后一个主要阶段，带来了《Moana 2》大部分制作过程中所使用的工作流。为了让艺术家能够以 DLight 工作流的方式批量创建和操作灯光，我们曾尝试扩展 Solaris LightMixer 以支持我们的工作流。我们的目标是尽可能依靠 Houdini，而不是完全构建新的解决方案。但我们对 LightMixer 的扩展尝试遇到了若干难以突破的限制。
相反，我们创建了一个更完整的 Houdini 节点和 UI，称为 LightBox（图 3）。它在理念上类似于 LightMixer，但融入了我们在 DLight 十余年发展过程中积累的大量丰富能力。
LightBox 是一个强大的工具，旨在提供多个灯光的高层概览，同时也支持对它们进行同步更新。在幕后，LightBox 是一个定制构建的 UI，它管理着一个 subnet；该 subnet 组织了一组标准 Light 节点实例，可对其进行创建或修改，并据此调整参数。LightBox 不仅能够管理场景中的整套灯光系统（并提供多种过滤选项），还支持创建和管理我们称为 Light Accessories 的内容。这些是自定义 schema，可实现更广泛的材质修改、控制表面之间的 light transport，以及对表面进行分组，以便简化 shader 的使用。
LightBox 具有高度可定制性，使艺术家能够根据其特定工作流、偏好或流水线需求，灵活调整界面和功能。无论是在单个镜头上工作，还是处理整个序列，LightBox 都可作为大多数灯光创建与编辑任务的可选集中枢纽。不过，它仍然兼容传统工作流，允许用户在需要时手动创建或调整单独的 Light 节点。
此外，对模板和渲染设置工具的进一步完善，也使艺术家能够更深入地采用多镜头以及序列级或 packet 级灯光工作方式。
为了支持更快速的迭代，我们集成了两个自定义 Hydra render delegate：一个支持基于 Hyperion 材质的实时预览 viewport，以及一个交互式 CPU/GPU ray-tracer。我们还扩展了整体工具集，其中包括与 Nuke 的工作流集成、一个用于 dust and particulates 的工具、Scene Graph Tree 中的右键辅助功能等更多内容。在图 4 中，我们可以看到 Houdini 中的桌面布局和用户体验是什么样的。
Houdini 工作流
4 生产挑战与结果
通过大量深入投入的工作以及稳固的合作关系，我们成功使用新的 Houdini 灯光流水线交付了《Moana 2》，尽管这一过程并非没有生产挑战和成长阵痛。
4.0.1 培训
从 Maya 的单镜头工作流转向 Houdini 的多镜头方法，给艺术家带来了挑战，尤其是由于肌肉记忆和既有习惯的影响。
由于大多数艺术家都是 Houdini 新手，基于视频的培训，以及与 Lighting 同行和 Technical Directors 一起进行的 office hours，缓解了这一过程的困难。在一个活跃进行中的制作项目上同步开展培训与开发，也带来了额外挑战——团队为了跟上工具集的演进，不得不多次接受再培训。
标准化模板帮助引导艺术家，而 Houdini 的灵活性则允许多样化的工作风格。除了培训项目之外，在实际制作过程中来自 TD 和开发人员的持续支持也至关重要。
4.0.2 多镜头
一些艺术家权衡了多镜头工作流的利弊。他们怀念旧工作流中的一个方面，是能够在不同 DCC 会话中同时处理多个镜头。多镜头工作流在 viewport 和节点网络方面面临性能挑战，尤其是在切换镜头时，这是由于《Moana 2》环境的复杂性所致。此外，输入的生产数据存在局限，也造成了障碍——如果摄影机调度和 layout 在前期没有据此进行设置，那么相似镜头未必能够直接适用同一套灯光设置和位置。
与之前的单镜头工作流相比，多镜头工作流也带来了一些好处。在旧工作流中，跨镜头保持连续性往往是个挑战；一旦艺术指导发生变化，用户就需要手动更新序列中相似的镜头。相比之下，Houdini 中的多镜头方法允许用户在单次工作会话中保持相关镜头之间无缝的连续性，减少连续性差异并尽量降低重复劳动。
4.0.3 增强
尽管存在需要克服的障碍，这次转型仍带来了明确优势。与 Maya 相比，Houdini 的基于节点工作流使共享变得容易得多，艺术家可以在不同艺术家和不同场景之间复制粘贴设置。现在，随着灯光工作转移到 Houdini，他们能够利用现有的 FX 工具集，两个部门之间也有了更好的交叉交流与协作。艺术家如今在创作过程中拥有了更高的参与度，能够在 Houdini 中构建自己的 rig、工具和 HDA。工具创建对 TD 和艺术家来说也变得更快、更易接近，不再像我们基于 Maya 的流水线那样需要大量编码知识。虽然适应变化需要时间，但这些改进以切实的方式赋能了艺术家，并简化了生产流程。
5 未来工作
尽管我们的新流水线已成功用于《Moana 2》，我们仍将其视为真正的 1.0 版本，尚未成熟。目前正在推进工作，以便为未来的长片制作继续演进这套流水线。这些工作包括：通过内部 delegates 增强 Hydra 交互性能、重新设计 render pass 工作流、改进 render submitter UI，以及更新我们的 region gradient（light transport modifier）工具。此外，我们还在实现模块化模板工作流，使灯光模块能够在多个 HIP 文件和工作区域之间进行实时传播。随着这些工作流逐渐成熟，提升自定义 HDA 和工具的性能仍将是重点关注方向。
DLight 经过了 15 年的打磨，我们对 Houdini/Solaris 工作流的成熟充满期待与信心，并相信它最终会超越其前身。
Acknowledgments
如果没有 Walt Disney Animation Studios 中那些出色的艺术家、TD、产品设计师、工程师和技术领导者的支持，这项工作根本不可能实现，其中包括 Emily Sison、Neelima Karanam、Kendall Litaker、Bettina Martin 和 Tami Valdes。
同时也特别感谢 SideFX，尤其是 Mark Tucker、Cameron White 及其团队，感谢他们提供了极具价值的开发见解。