图 1：Manuka Hydra Delegate 在 Pixar 的 usdview 中，使用 physlights 设置实时渲染一个简单测试镜头
Pixar 的 Universal Scene Description（USD）与 Hydra 结合在一起，定义了一套场景描述与渲染 API，展示了未来交换与高效渲染的一种图景。业界已经拥抱了这一体系，并且所有 DCC 都已提供相应集成。
尽管如此，Hydra 在很大程度上仍被限制为视口渲染 API，而没有被部署为最终帧渲染 API。我们相信，拥抱其组合与分层系统的能力，并结合实时组件与交互式渲染，能够彻底改变艺术家交付最终帧的方式。在这一共同基础之上构建工具，不仅能够改善迭代时间，也会改变他们在不同部门、工具，乃至不同公司之间的协作方式。通过考察为实现并展示一个可工作的端到端系统而构建的组件与约定，我们希望鼓励围绕这一生态系统展开讨论，并推动进一步的贡献与改进。
1 引言
视觉特效（VFX）工作室能够制作出令人惊叹的视觉成果，为全球观众带来娱乐体验。为了做到这一点，VFX 流水线由多个部门构成，它们分别贡献各自发布的产物，共同组成一个镜头或一个序列。每个产物通常代表某个元素的不同部分之一。例如，Models 部门会发布 AssetChair 的 hero 几何体。随后，Look Development（LookDev）部门会发布 AssetChair 的材质与着色器。Virtual Art Department（VAD）会发布适用于实时、可用于片场、分辨率较低的 AssetChair 几何体与材质版本。Layout 部门会在镜头布局中将 AssetChair 作为元素 chair01 发布出来。如果 chair01 需要被直接动画化，Motion 部门就会在该镜头中发布它的动画版本，而 Creature Department 则会在需要时发布带有可能的 shot-sculpts 的 hero 动画版本。Effects（FX）部门会发布与该 hero 动画相关的 FX 组件，例如椅子撞击地面后产生的灰尘或碎片等。随后，Lighting 部门的艺术家会通过导入所有这些产物来组合镜头，并摆放灯光以建立他们想要的构图。当 Lighting 艺术家对 CG 构图满意后，他们会提交渲染，并将结果拆分为独立组件，供 Compositing 部门的艺术家使用；后者可能需要对窗户上椅子的反射做小幅修改，或者将实拍帧与 CG 生成的数据结合起来。
在 Wētā Digital（现为 Wētā FX），我们一直专注于构建一条基于通用数据格式的流水线，使每个部门都能够消费同一份数据。我们的内部场景描述 Atlas 正是已发布数据的核心。
为了统一所有部门对数据的查看方式与可访问性，我们为主要的 DCC/宿主应用构建了 Atlas，例如 Maya、MotionBuilder、Katana、Houdini；同时我们还构建了 Zeus（Atlas 的 outliner），以便在 Maya 和 MotionBuilder 这类更强调交互性的环境中与其配合使用。我们让 Atlas 深度理解自研实时渲染器 Gazebo，并通过 GardenPartyInterface（Gazebo API）与之连接。作为一个视口渲染器，Gazebo 能够在每个 DCC/宿主中为艺术家提供一致的渲染结果。Atlas、Zeus 与 Gazebo 的组合使艺术家能够在 Maya 中为 MotionBuilder 中的片场动作捕捉会话准备布局，从而确保他们在 Maya 中看到的内容，就是他们在 MotionBuilder 中得到的内容。或者，他们也可以在 Maya 中搭建灯光 rig，然后再载入 Katana 进行离线渲染。Atlas 及其“朋友们”（我们自定义 procedural 的 atlas-plugin 版本）几乎是整个流水线中每个部门的艺术家都要直接交互的对象。Koru GPU puppets、LightNinja 灯光与 physcam 设置、Bake 与 Lumberjack procedural、Wig/Braidular 毛发资产、Apteryx 羽毛，以及复杂的 WaterWaves 或 Loki 模拟；我们可以在一个 atlas 文件中描述这一切，通过 Atlas 和 Zeus 在任何 DCC/宿主中打开它，在 Gazebo 的视口中查看其内容，通过 AtlasTweaks 调整元素或 procedural，并在 Katana 中通过 Manuka 进行离线渲染。上述这一切的优点在于，我们完全按照自身需求构建了系统；缺点则是，我们必须持续支持它，并随着 DCC/宿主的每一次更新而对其进行修改，因为为了给艺术家提供无缝体验，Atlas 深入到了这些宿主的内部。
过去几年里，我们这个行业以及 Wētā FX 的工作方式都发生了变化。我们的客户希望在镜头的所有部分上持续进行迭代，直到最后。显而易见的是，我们需要转向一种行业标准的数据格式。
Pixar 的 Universal Scene Description（USD）和 Hydra Rendering API 为数据交换与渲染提供了统一定义。将两者结合起来，而不是仅仅在开源环境中采用一种数据格式或一种渲染 API，就能提供一个框架，使所有 Digital Content Creation（DCC）工具之间实现一致结果成为可能。这种一致性能够增强信心，同时也让 DCC 厂商与工作室能够创造出更具动态性、更加无缝的体验。
Pixar 以及各个 DCC 厂商正朝着我们一直希望达到的那个行业标准前进。USD 与 Hydra 现在已自然成为我们重建流水线过程中的下一步，它们与 Atlas 和 GardenPartyInterface 有许多共通之处，但我们的工作重心将转向支持开放标准，而不是封闭的定制工具集。
在接下来的章节中，我们将描述我们采用 USD 的道路与历程。我们希望，这条端到端流水线的描述不仅能表明：人们可以通过 Hydra 来提供最终帧渲染；也希望分享我们学到的经验，以促进更开放的协作持续发展，并改进我们所有的工具。为简洁起见，我们假定读者已经了解 USD 及其提供的组件和 API。
2 通往 USD 之路
制作从不停歇，“show(s) must go on”。
考虑到这一点，不可能一次性改变整条流水线。因此，我们将 Lighting 和 LookDev 部门选定为第一批集成切入点。
在 Wētā FX，Lighting 的职责比这个词字面所暗示的范围更广。
我们常常并行构建镜头，例如 Lighting 和 Comp 会很早就开始，甚至在动画尚未完成之前就已启动。于是，一个显而易见的需求出现了：我们需要在一个内容能够被“创建”而不仅仅是“组装”的软件包中工作。随着越来越多的部门共同参与镜头同一部分组件的制作，我们需要一套系统，能够处理各个 layer 的变化，并在必要时以非破坏性的方式禁用它们。
USD 的一个关键特性是组合：所有“arcs”（layers、inherits、variant sets、references、payloads、specializes）都会按照称为 LIVRPS 的特定顺序进行求值，从而快速且无歧义地得到最终的 USD stage 表达。
为了利用这种组合能力，我们必须确保每个部门发布的数据都采用 USD 形式。此前，我们已通过专有场景描述 Atlas 统一了流水线中的各个 DCC；而现在，我们面临的是用 USD 来替代它。
采用一个事实标准的关键，在于避免在内部把它重新做成另一个定制版本。如果我们开始在简单修复或适配之外大幅修改 USD 代码库，那就违背了采用标准的初衷。基于这一点，我们评估了 USD 是否具备我们所需的全部功能，并尽量只通过 USD 插件来弥补缺口。为此，我们实现了自定义 schemas、kinds 和 primadapters。我们尽可能把这些实现向层级结构更深处推进，把它们隐藏在组件背后，让大多数 layout 层级和顶层组合仍然保持 USD 所期望的形式。
2.1 基于转换的流水线
将我们已发布的 Atlas 产品转换为 USD 产品，是第一步。Atlas 与 USD 非常相似，但也存在差异。这种转换并不是简单映射，而是基于目标特性对数据进行重新诠释，以最大化发挥 USD 的优势。对于更复杂的资产，我们则使用针对几何格式和 procedural 的自定义插件。
2.2 资产转换
建模流水线主要基于 Maya，我们在那里发布自定义几何格式 Bake。我们一开始是把 Bake 文件转换成 USD，随后我们意识到，较复杂的 procedural 带来了问题。
于是我们决定构建 chasers，并将其插件化接入 Maya 的 USD 导出器，以避免这些问题。这样既能覆盖资产发布流程，而且更好的是，我们把 USD 的使用进一步前移到了流水线更上游的位置。
2.3 Procedurals
我们丰富的 procedural 系统具备足够的灵活性，可以在流水线的所有阶段始终保持 procedural 形态，从创建一直到渲染器输入阶段。这使得艺术家可以在流水线的任意节点编辑 procedural 的复杂度，而不必先将结果 bake 出来。
在 USD 中，我们也采用了类似的开发方式，混合使用 FileFormat 插件和 PrimAdapters。考虑到 PrimAdapters 在设计上只能为 Hydra delegates 展开其内容，我们还定义了一个通用 API schema，以复用 PrimAdapters 的工作，使其也能够在 USD 上下文中展开。这使艺术家能够在 outliner 中验证内容；在 PrimAdapters 无法用于模拟或其他用途时对内容进行 bake；或者将其导出，用于与客户或其他工作室交换。
2.4 材质
在与 USD 相关的会议和 focus groups 中，Materials 和 Shaders 一直是热门话题。
我们的 LookDev 工作流通过专门投入资源得到了直接处理：我们用 SideFX Houdini 来替代自定义 authoring 工具，使用 Houdini 的 node-graph 编辑器来制作 Materials 和 Shaders，而不再使用我们自己的 node-graph 编辑器。
我们希望采用 USD 和 Hydra，而随着 Solaris 的引入，最自然的做法就是直接在 USD 中创作 materials 和 shaders。在这一实现中，我们需要理解我们的自定义 shaders，并知道如何将它们编译给自定义渲染器 Manuka 和 Gazebo 使用。一套复杂的自定义 C++ Solaris Nodes 构成了我们 squid 工具集的核心：我们现在能够生成 UsdMaterials，并在 UsdShaders 中包含按需即时编译、面向 Manuka 与 Gazebo 的 shaders。
2.5 烘焙“secret sauces”
虽然我们希望这一节讲的是烹饪，但实际上它讨论的是：我们如何确保场景能够在所有尚未实现 PhysLight 或使用专有逻辑的 render delegates 中被加载和渲染。我们当时的资源只够在 USD 中为自定义渲染器重建 material 和 shader，而无法确保每一个 render delegate 都能使用我们的 materials 和 shaders 进行渲染。我们决定，不必在 layout 层编码任何“秘密配方”来制作一个可共享的通用表达，只保留原始 USD。我们也决定将资产烘焙为可共享的多边形形式，并把颜色按 CV 烘焙进去。缓存带来的收益对 Manuka 同样成立，因为我们既可以将其烘焙为 Manuka 专用格式，也可以烘焙为通用 USD 格式，使用每顶点的 displayColor，存储扁平化的 albedo RGB 值。这些资产在 Manuka 中（由于预缓存了与光照无关的着色和细分）以及在其他所有渲染器中（包括 GL）都能非常快速地加载，因为 shader 和 texture 都已被 displayColor primvar 替代。我们决定将它们用作默认表示：渲染用途使用 render purpose（即 Manuka assetCaches），代理显示用途使用 proxy purpose（即 viewportproxy assetCaches）。
图 2：在 Manuka 中，AssetCaches 使用中等质量 LOD 的完整 hero 材质渲染；在 GL 中，则使用较低 LOD 的每顶点 displayColor 渲染
2.6 场景描述
在模型与材质完成转换之后，就必须处理 layout 及其元素。这个任务的一个重要目标，是定义什么是 element、它应如何在 layout 中被描述，以及它由哪些组件构成，材质、几何体、其他可能的表示或 variant 又应该放在什么位置。
我们经历了多个“版本”的尝试，最终从艺术家的视角来处理这个问题：艺术家希望什么样的定义被视为一个 Element？他们更希望如何处理一个 creature、一棵树，或整个 layout？他们真的希望看到成百上千个 element、后代节点和实例吗？
艺术家帮助我们把数据“翻译”为对他们以及对 USD 本身都有意义的形式。我们在转换过程中加入了特定功能，以利用 Classes、Variants、Inherits、References 和 Payloads。随着时间推移，我们逐渐意识到这些 arcs 中每一个的重要性，而且至今仍在学习。
理解你的场景表达方式，是为流水线构建可渲染且可管理场景最关键的部分。我们将 layout 结构划分为两个主要部分：其一是 Workspace，其中包含所有 elements。这一部分是可渲染内容，并按典型的 assetElements 层级结构组织。
另一部分是 Class 定义，其中存放所有资产的 payloads。这些是由 Workspace 中的 prim 继承的可共享内容。
图 3：Workspace 的层级结构，以及可共享的 Classes。
这种结构允许我们通过 classes 对某个特定资产的所有 elements 进行全局修改，也可以通过 workspace 中的 prim 对单个 assetElement 进行编辑。
艺术家可以控制按 purpose 区分的 variants，从而根据自己当前在 proxy 或 render 中想做的事情，在不同表示之间进行选择。例如，在 GL 中使用低分辨率 assetCache，而在 path-tracing 中使用完整 hero variant。
图 4：GL 与 Manuka Hydra delegate 中 AssetCache 的多 LOD 表示
需要注意的是，在选择表示 variant 时，用户必须做出一定判断，因为过多高细节表示很容易耗尽可用渲染资源。尽管如此，我们也认识到，在某些时候，为了让特定元素达到理想效果，这种程度的控制是有必要的。
PointInstancer 的 prototype prim 以与单独 assetElement prim 完全相同的方式继承自 assetElement class prim，因此也享有拥有共同 assetElement class prim 的同样好处。
2.7 构建目标、依赖项、VFX Platforms 与 DCCs
如果没有为多个 VFX Platforms、DCC 和 USD 版本管理构建环境，这一切工作都不可能实现。通常，人们必须为每个 DCC 单独编译。但由于 USD 是开源的，它也鼓励 DCC 去产出类似的开源组件。因此，我们得以为每个 DCC 编译自定义插件，并让它们加载同一版本的 USD。这使工程师只需要针对一个 USD 版本进行编译，唯一的变体只有 VFX Platform 年份，而他们的插件就可以在 Maya、Katana 与 Houdini / Solaris 中透明运行。这让他们能够专注于更重要的问题，例如性能与艺术家体验。
3 通往渲染之路
我们的 VFX 流水线包括通过生产级 path-tracer Manuka 交付最终渲染。
如今数据已经以 USD 的形式流动，下一步自然目标就是能够通过 Hydra 在 Manuka 中渲染它。我们最初试图让 Manuka 直接读取 USD，但最终放弃，转而采用更为集成、符合 Hydra 规范的解决方案。有了 Hydra render delegate，同一个场景就可以在 usdview 以及任何其他支持 Hydra 的宿主中查看。
3.1 将离线渲染带入视口
Manuka 早已支持一种名为 Manuka Live 的重新渲染模式，它能够接收各种类型的编辑。
这意味着我们需要专注于制作一个 Hydra delegate，把 USD/Hydra 编辑连接到 Manuka 的内部编辑系统。在开发 Hydra delegate 的同时，我们也提升了 Manuka Live 的交互性。速度对于向艺术家提供交互式反馈至关重要。然而，我们仍然需要生成最终质量的渲染结果。
3.2 用于最终帧渲染的 HydraOffline
仅在视口中渲染，并不足以让 USD 和 Hydra 流水线支持离线渲染。我们扩展了该 delegate，使其能够在非编辑模式下运行，以避免为单次渲染保留并不需要常驻的数据。
我们必须确保能够交付 Compositing Department 和去噪流水线所需的所有产品——AOVs。我们流水线当时正在使用的最新 USD 版本是 USD-21.08，而 Pixar 在这一版本中并没有为 Hydra 中的离线渲染制定任何完善方案。
USD 为多种 Render-prim 提供了 schema，例如 RenderSettings、RenderProducts 和 RenderVars，这些都是完整离线流水线所必需的。而 Hydra 对这些内容完全没有支持，这就成了一个问题。我们还需要一种能够被远程派发到 CPU render wall 上的解决方案。
我们构建了一个名为 HydraOffline 的工具，这是一套通过 Hydra 渲染流水线执行渲染的 C++ 与 Python API。
它的命令行行为类似 usdrender，但允许我们定制 Hydra 渲染流水线，以便适配我们的渲染器。现在我们能够加载 USD stage，读取 Render-prims 并将其放入 RenderSettingsMap，创建 RenderTasks，调用 render delegates，并支持我们的 VFX 流水线所需的全部 AOVs，同时能够运行在 CPU render wall 上。
3.3 渲染大型场景
通常，场景在结构上并不是以最优的渲染方式组织的。它们是由人构建给人读的，而不是专门为渲染优化。
其中存在显式实例化的元素：单个元素会被描述为一系列变换列表，这些变换是场景中同一元素的多个实例，在 USD 术语中称为 PointInstancers。除此之外，所有可能从同一资产 class 继承而来的单独元素，都必须由底层系统以隐式方式处理。
USD 原生支持隐式实例化，这意味着即便场景中是以单独元素形式组织的，它们仍然可以被隐式实例化，从而更高效地加载 USD stage 并渲染这些元素。
我们意识到，尽管 USD 能够处理这一点，但向 Hydra 的转换并没有完整反映出来，或者至少说，Hydra delegate 很难理解多个 PointInstancers 与多个单独元素正在使用同一个 prototype，从而难以减少渲染内存和时间。能够在单独元素和多个 PointInstancers 之间共享同一个 prototype 的能力当时还不存在；而我们迁移自的系统正是高度依赖这一点来渲染大型场景。
在与 SideFX 讨论这个问题后，他们得出结论：Pixar 的 Hydra 中需要一个新的 API，以便在 Hydra 中也能取回由 USD 创建的隐式 prototype，这样 render delegates 才能在渲染时减少 prototype（也称 exemplars）的数量。
我们知道 Pixar 正在开发下一代 Hydra v2，以提供更多特性来支持这一点，但我们使用的是 USD-21.08，因此来自 SideFX 的补丁对我们至关重要。
我们把这个补丁加入了内部的 USD 构建中，以便能在所有 USD 环境中使用它，从而渲染大型场景。再次说明，能够在所有 DCC 中灵活控制我们的 USD 版本，使我们得以在很短时间内部署并使用这一特性。
4 通往新照明工作流之路
在新的标准已经就位，并且我们已经能够通过 Hydra 在视口和离线环境中渲染内容之后，我们还需要让 Lighting 工作流真正采纳它。
在我们的流水线中，我们不会为某项工作强制规定特定工具。艺术家可以选择手头可用的工具，而我们会尽最大努力确保任何工具都能平滑地融入流水线。我们为特定 DCC 构建了发布与渲染流水线，但除此之外的其他操作都可以在任意工具中完成，只要提供导入/导出能力即可。
采用 USD 与 Hydra 将有助于把多种工作流融合在一起。
4.1 融入现有体系
我们在 Katana 中已经拥有一条经过充分验证的渲染流水线，而 The Foundry 也完成了一些将 USD 集成到渲染流程中的工作。
在这条流水线基础上，我们又启用了流水线中的一个 authoring 工具。它同时具备相当强大的 procedural 系统，并支持 USD 与 Hydra：这就是 Solaris。
通过引入 USD，最直接的收益之一，就是让 Lighters 能够在 Solaris 中探索 lighting 方案。Lighting 艺术家可以在 Solaris 中探索 lighting 方案、修改 layout、重新布置实例、尝试替代模型，直接使用 USD，并在需要时导出到 SOPs，再返回 LOPs，以便通过 procedural 方式修改多边形。随后，再把例如灯光之类的内容导回 Katana 中现有场景，也就变得非常直接了。
4.2 非破坏性方法
随着我们的生产流水线变得更加复杂，流水线中的角色也理所当然地变得更加专业化。随着专业化程度提高，参与人员数量也会增加，因此把内容在流水线中向前推进所需的额外开销也会增加。我们在 lighting 环节切实感受到了这种额外开销所带来的负面影响，而我们认为 USD 与 Solaris 是重新平衡整个系统的有价值工具。
我们希望赋予 lighters 像通才一样工作的能力——创作内容、管理布局、微调着色，并最终缩短反馈闭环，让他们能够更快地迭代。
作为 Houdini 的众多上下文之一，Solaris 为这类工作流提供了理想平台。我们意识到，如果能够利用 Houdini 的各种上下文，并把它们导入 LOPs，在现有场景之上构建非破坏性的 lighting 编辑，那么 Solaris 就可能成为向 lighters 开放通才式工作流的理想工具。
4.3 构建新的工作流
Lighting 中发生的一切，始终都位于大多数其他部门的下游。要想让 Lighting 对一个镜头或序列做出显著变更，这些变更就必须是非破坏性的。
USD 让这件事变得容易。我们很快发现，允许 lighters 以 USD 的形式创作内容，是支持其工作最快且最灵活的方式。在 Solaris 之上，我们构建了 layer 摄取和发布工具，用于隔离 lighters 做出的改动，并把它们以“烘焙”后的 USD 形式重新并回 Solaris。
Lighting 产生的任何 layers 都可以像任何其他上游内容一样被摄取。通过这种方式，我们能够简化为一次渲染而装配各个 layers 的过程，降低 Solaris 场景的复杂度，并改善场景性能。让 lighters 成为内容作者后，我们也能复用他们完成的工作，并把这些成果纳入其他镜头或序列中。我们构建了自定义节点，用于导入镜头内容、定义 passes、管理 render-caches、指定所需 AOVs、在 render wall 上发起 batch renders，也就是从 Solaris 发起渲染所需的整套工具。至于内容编辑，大多数工具都已经存在于 Solaris 丰富的节点集合之中。除了能够创作自己的内容之外，许多 lighters 过去还曾提出一个顾虑：要有意义地检查自己场景中的内容非常困难。我们的镜头已经变得极其复杂，以至于我们过去更侧重于数据吞吐量（渲染性能），而不是可内省性。为了解决 Solaris 中的这一问题，我们把重点放在视口体验以及构建可视化场景内容的工具上。我们构建了一个 Outliner，用来可视化镜头中的关键组件，并支持诸如切换表示、为视口渲染加载/卸载 assetElements、管理 USD-layers、检查元素是否有新版本等核心操作。其中最关键的特性之一，是能够跨多个镜头查看数据。创意决策往往需要放在多个镜头的上下文中一起评估，以检查连续性。
4.4 所见即所得
对于这套新的 USD 工作流而言，Solaris 中快速的交互性至关重要。尽管艺术家已经能够在视口中加载完整场景，但要获得流畅体验仍是个问题，因此我们需要一种方法，把渲染部分迁移到 CPU render wall 上。为此，我们构建了 Mamao。Mamao 在毛利语中的意思是“遥远”或“远方”。
它是一小套工具，用于对 Solaris 场景进行交互式远程渲染。其目标是利用 render wall 上更大、更强的资源来完成交互式渲染任务，从而把处理负担从艺术家的机器和当前活跃的 Solaris 会话中移除。
其主要组件包括：一个自定义 Houdini Operator，用于获取 USD stage 数据，并在发生变化时通过网络派发出去；以及一个运行在远程硬件上的客户端应用，它能够接收这些变化，并将其应用到一个实时 Hydra Delegate 渲染会话中。
与解决该问题的某些方法不同，我们的 Houdini Operator（MamaoSender）不会生成 stage deltas——也就是一次更新与下一次更新之间的差异。相反，它会获取 stage 中存在的完整 layer 栈，包括匿名的内存 layer，将这些内容编译为一个 journal，然后通过 ZMQ socket 发布出去，供远程客户端消费。
客户端应用随后通过网络获取这个更新 journal，并将其重新拆分为离散的内存内 Sdf layers。接着，它会识别哪些 layers 的内容与上一次更新周期中提供给 stage delegate 的内容不同。那些发生变化的 layers 会被更新，而新引入的 Sdf layers 会被追加到 stage 中，从而触发最小量的同步操作，使远程 stage 保持最新状态。由于忽略 deltas，获取 usd 状态的过程被简化了，因为在 Solaris 中不再需要做 flattening；而 Mamao 客户端应用更新的过程也被简化了，因为它可以忽略所有中间更新，只应用队列中最新的 journal。
由于我们的 USD stage 绝大多数由 references 构成，而诸如 lighting 或 material 调整之类的内容通常位于各自独立的 layers 上，因此即便在大型复杂场景中，对 lighting 或 camera 的修改也几乎能够被立即生成并应用。
Mamao 包含一个 Snapshot Manager 和一个 Resource Manager。Snapshot Manager 允许艺术家为迭代过程创建快照、从先前迭代恢复，或者根据创意反馈混合搭配不同迭代。Resource Manager 则使艺术家能够在 Houdini 内部轻松启动、管理或监控进行中的 Mamao 渲染。
Mamao 让我们能够同时对多个镜头进行实时渲染。我们可以把最多 10 个 Mamao 渲染流式传输到 Weka（我们的查看应用）中的一张 contact sheet 上。contact sheet 的实时渲染为多镜头 lighting 工作流打开了令人兴奋的新可能。
5 艺术家反馈
以下是 Lighting 部门中少数几位已在不同方式下使用我们目前所构建系统的艺术家的初步反馈：他们一方面在 Katana 中扩展了自己惯常的渲染流水线，引入在 Solaris 中创建的内容；另一方面也在 Solaris 中直接测试了一套完整的、基于 USD/Hydra 的非破坏性工作流。
这两种工作流都很不错，只是出于不同原因。
Rob Byrne，CG Supervisor
我们在 Solaris 中借助 Mamao，快速探索了若干问题镜头的 lighting 方案。在获得创意批准后，我们导出了 USD lights，并且毫无问题地将它们集成进艺术家的 Katana 场景中。
在一些镜头中，我们把 Katana 与 Solaris 结合起来使用，因为我们需要通过碰撞和灯光来驱动资产的着色。能够在同一个应用里完成构建、着色和渲染，给了我们极大的灵活性。我们可以回应那些通常需要 2 到 3 个部门协同才能完成的反馈。Squid 让我们能够利用 Houdini 的 SOPs 上下文中定义的 primvars，以 procedural 方式为资产着色，并在 Solaris 的 LOPs 上下文中进行测试渲染。我们现在也开始使用 PDG 来进一步简化这个流程。
Steve Bevins，Lighting TD
我一直在做的这个镜头，其特点在于 layout、lighting、lookdev 和 fx 彼此紧密交织，因此为了快速迭代，我们需要一种方法，能够把其他部门的工作集中在一个地方完成。Solaris 让我能够从头到尾交付这些镜头，同时仍然可以在我们的 hero character 流水线内部完成全部渲染；鉴于这些镜头涉及交互式 lighting，这一点的威力非常大。
在某个镜头中，我们的周期非常短（从 turnover 到交付只有 8 周），而我能够在正式资产真正发布之前数周，就先在 Solaris 中开始一些创意迭代。多出来的这几周缓冲时间对于交付镜头非常重要。能够自行搭建 layout 和 shading，使我能够更早开始 lighting，并且随着 hero builds 准备就绪，再用它们替换掉我自己做的内容。总体而言，这让我在整个创意流程上都抢得了很大的先机。
6 未来工作与结论
我们在这里只是简要描述了一大批工作，但它确实改善了艺术创作体验。能够亲眼看到这一点，令人非常欣慰；而且我们对这套系统有足够信心，愿意使用 Hydra 层来生成最终帧渲染。我们还进一步实现了 procedural 的延迟展开，而我们仍然相信这点非常重要。我们交付给艺术家的用户级工具，使更好的交互式工作流成为可能，也开启了新一代 look development 与更优交互式 lighting 工作流。与此同时，我们做到这一切的同时，仍然忠实于 USD 的本质。此外，只需对 USD 核心代码库做非常小的改动，我们就能够利用 Hydra API 高效渲染大型场景并产出画面。
我们认识到，还有许多其他团队也深度参与在各自的 USD 采用与落地过程中。对此，我们希望我们的努力能够鼓励这些团队继续前进，并进一步促进这个社区中的对话与贡献。
归根结底……它是可行的！
致谢
如果没有以下这些按字母顺序排列的艺术家和工程师，这一切都不可能实现：
The Amazing AssistantTDs Team、Alex Samsonov、Andra Doran、Barton Gawboy、Chris George、Chris Russell、Derek Norn、Eric Vezinet、Farhan Wali、Fraser Robertson、Jiri Schlemmer、Johannes Franz、Kenan Bolukbasi、Kipp Horel、Luca Fascione、Martin Grözinger、Matt Dudgeon、Matthias Baas、Nicholas Grobler、Nick McKenzie、Nick Shore、Oleskiy Puzikov、Oliver Castle、Olivier Gourmel、Peter McGrattan、Remi Fontan、Richard Addison-Wood、Richard Lei、Robert Byrne、Sander van der Steen、Seb Schmidt、Steve Bevins、Tereza Drskova、Tim Murphy、Tom Buys、Tomas Davidovic、Tymon Pitts、Yogesh Balguri，以及最后但同样重要的 Joe Letteri，感谢他在整个工作流设计过程中对我们的指导。