原文页面 https://animallogic.com/technology/publications/usd-at-scale/
PDF https://animallogic.com/wp-content/uploads/2023/04/USD-at-Scale.pdf
USD at Scale
Jon-Patrick Collins（Animal Logic，澳大利亚悉尼）
Romain Maurer（Animal Logic，澳大利亚悉尼）
Fabrice Macagno（Animal Logic，澳大利亚悉尼）
Christian Lopez Barron（Animal Logic，澳大利亚悉尼）
图 1：USD 资产图（USD Asset Graph）组件：左侧展示一个典型制作镜头在磁盘上的 USD 物理结构；右侧为同一镜头的实时 3D 视窗渲染。图从左到右流动：镜头实体（shot entity）在最左，通过连接关系延伸到下游的域（domains）、子域（subdomains）、片段（fragments）以及技术变体（technical variants）。文中示例基于 USD ALab 开源场景，公开地址：https://animallogic.com/usd-alab/ 。
摘要
本文描述了动画与视效工作室（Animal Logic）将 Pixar 的 Universal Scene Description™（USD）集成到一个既有、规模庞大的传统管线中的关键步骤。我们讨论了多项架构选择，以及为支撑这些模式而开发的软件系统。此次 USD 迁移取得成功，使工作室的工具链生产力显著提升，从而能够同时开发多部长片项目。
1 引言
历史上，Animal Logic 采用一种“生成式（generative）”的场景构建方式：由工具根据不同工作流需求，将原子级资产（atomic assets）装配成场景，而不需要明确的场景描述（scene description）。该系统在很大程度上由数据库驱动，并依赖大量工具支持。这种方式劳动密集，需要庞大的软件代码与手工配置。尽管我们的工具链在不同工作流之间是共享的，但底层资产是异构的，涉及多种文件格式。我们曾短暂尝试开发内部的通用场景描述（Common Scene Description, CSD）格式，但最终认识到，开发此类系统是一项极其重大的工程，超出我们的开发范围。
在 Pixar 于 2016 年将 USD 开源之后，我们开始分阶段推广 USD。动画团队在《比得兔》（Peter Rabbit，2018）上用 Forge™ 镜头构建应用进行了成功试点 [Baillet et al. 2018]。在此基础上，我们在《比得兔 2》（Peter Rabbit 2，2021）期间推动全管线向 USD 的大规模迁移。当前，我们的 USD 工具链仍在持续成熟，应用于包括《DC 超级宠物联盟》（DC League of Super-Pets，2022）与《魔法师的大象》（The Magician’s Elephant，2023）等项目，重点是在大规模条件下构建 USD 内容。如今，在一部典型制作的生命周期内，我们会生成数以百万计的 USD 文件。向 USD 的迁移也使我们能够整合多条工作流与技术栈，效率提升让我们可以并行开发多部长片。
2 架构选择
在设计基于 USD 的管线时，我们需要同时考虑多方面约束：如何将管线内容与工作流建模为原子级 USD 文件；如何确保这些 USD 文件以尽可能高效的方式进行组合（compose）；如何自动化 USD 文件生成（包括大规模的批量重建）；如何支持 USD 文件的打包（packaging）与版本管理；如何在“集中式场景描述”的需求与跨项目、跨地域、跨部门团队的“分布式开发现实”之间取得平衡；以及如何支持跨部门的并行工作流。这些约束共同导向了以下设计选择。
2.1 基于片段（Fragment）的组合
在电子游戏架构中，一个常见的软件模式是 Entity-Component-System（ECS）：实体（entity）并不由“类型（type）”定义，而是由其包含的组件（components）装配而成。例如，如果一个实体包含几何组件，它就可渲染；如果包含物理组件，它就可参与模拟。我们受到该模式启发，创建了一个可复用的“全局片段（global fragments）”库，并辅以“镜头特定片段（shot-specific fragments）”库。每个片段由一个 USD 文件定义，它通常会通过 references、sublayers 或 payloads 等方式引用其他 USD（以及非 USD）文件。片段代表可复用功能单元（units of reusable functionality），例如几何（geometry）、绑定（rigging）或 UV 绑定（UV bindings）。
随后，我们将顶层“拆解/分解（breakdown）”概念（如角色、道具、镜头）建模为实体（entities）。每个实体由一个 USD 文件定义，其中包含对若干片段的引用列表。实体（功能聚合体）与片段（功能单元）之间这种清晰分离，是一个关键的设计选择，后续许多架构都由此展开。该模式的一个结果是：它抑制了项目特定的、带强类型（typed）的实体膨胀，并减少了需要被各类软件系统建模的核心概念数量。这不同于我们过去的管线——那时每出现一个新概念，都需要新增一套软件与配置栈，而过时的、项目特定的类型也会长期滞留在代码库中。
此模式追求通过片段的组合与交互来获得复杂性，而不是为制作过程中不断出现的新顶层概念手工硬编码。它同样追求以“库”的形式建立可复用功能，其中片段是复用的基本单位，且同一个片段可能被多个实体引用。
图 2：组合弧（composition arcs）示意图，用于描述实体（entities）与片段（fragments）之间的关系。
2.2 基于实体的组合（Entity-Based Composition）
在标准组合模式中，实体引用片段，但片段不引用实体。然而，为了支持“环境（environment）”这类实体装配体（entity assemblies）——它们由大量布景模块（set pieces）聚合而成——我们引入了某些会反向引用实体的片段。具体而言，我们使用 Assembly 与 Breakdown 两类片段，这两者都包含对其他实体 USD 文件的引用列表。
我们使用 Assembly 片段来定义实体装配体（例如环境）；使用 Breakdown 片段来向镜头中填充角色、道具、环境、摄影机与灯光。二者的主要区别在于：装配体更适用于对较简单实体的直接复合；而被加入镜头 breakdown 的实体，预期会被许多额外“微调层（tweaking）”、运动（motion）以及其他 USD 意见（opinions）进行大量修改。
2.3 实体域（Entity Domains）
我们在实体与片段之间引入了一层额外组织结构：实体域（entity domain）。实体域代表单一逻辑工作流（例如建模、绑定或材质/表面）对某个实体的贡献。实体最终由一组域 sublayer 堆栈（domain sublayer stack）构建而成；每个域层可能会引用多个片段。实体域为部门与工作流提供了自然映射，并且域的相对强弱（每个项目可配置）会体现在它们被追加到 sublayer 堆栈中的相对顺序上。该模式的关键结果之一是：它清晰划分了各部门的责任边界，并保证每个部门工作流的最终交付物是一个实体域 USD 文件，使得所有 USD 内容都可以被引用该实体的上游层通过 sublayer 直接组合进来。
图 3：全局片段浏览器：片段按片段类型与兼容域（compatible domains）进行分类。
2.4 技术变体（Technical Variants）
我们将片段的“重载荷（heavy payload）”数据拆分到独立的技术变体资产文件（technical variant asset files）中。许多技术变体以原生 USD 文件存储（重内容通常为 .usdc，较轻内容通常为 .usda），但也有不少技术变体是外部文件格式（例如 Foundry Nuke™ 的 .nk、SideFX Houdini™ 的 .hou），或是标准数据格式（XML、YAML、TOML 等）。
片段通常会定义一个 USD 变体集（variant set），其中每个具名变体都会引用一个技术变体资产。例如，建模（Modeling）实体域会引用一个几何（Geometry）片段；该片段通过变体集引用多个几何技术变体，每个技术变体对应一种分辨率或使用场景，如 BaseMesh、PoseMesh 或 HighResolutionDeformationMesh。
2.5 打包（Packaging）
在使用 USD 之前，Animal Logic 有一个随着多年演进而变得复杂的资产打包系统，其工具链不透明且难以维护。迁移到 USD 给了我们一个机会来精简与现代化这一套工具。
为了打包 USD 内容，我们采用了一个直接方法：对 USD 文件进行快照（snapshot），并将未版本化（unversioned）的标识符替换为带版本的标识符。必要时，我们也会对这些 USD 快照进行可选后处理，例如裁剪某些内容、注入元数据（如包围盒范围/bounding box extents）。这样便形成了一个简单而强大的资产层级快照机制：我们可以沿着 USD 图的拓扑结构递归重复该过程。
我们只为轻量的 USD “脚手架（scaffolding）”内容创建 package 文件（即实体、域、片段），而不会为技术变体创建快照。我们以扩展后的标识符存储打包资产，将 package state 纳入标识符的一部分，典型值包括 Live、Output、Delivered；这些会作为磁盘上的新资产发布。
此外，在 stage load 时，我们还可以指定 package state 与版本的动态覆盖（dynamic overrides），以控制在特定工作流中使用哪些资产。不同工作流可能需要混合使用不同打包规则的资产：例如某个工作流可能加载 Live 实体（所有内容解析为最新版本），但建模几何则使用 Delivered（解析为最新的已交付版本，即使存在更新但未交付的版本）。
图 4：“打开所选版本（Open Selected Version）”对话框：用于让艺术家选择要打开的实体版本。窗口会展示针对该实体发现的不同 package state 及其关联版本。
3 实现
我们生成 USD 内容的第一种做法是围绕既有制作数据库：用户显式向数据库添加新内容，从而触发脚本重建 USD 内容。但该系统相当僵硬，很快演变成庞杂且复杂的脚本集合。其关键缺陷在于：生成 USD 的前提是必须先更新制作数据库。
我们的下一次迭代旨在移除对制作数据库的依赖，使工具能够在不向数据库写入大量“虚假/实验性”内容的前提下，直接创建可用于制作的（production-ready）USD 资产。
3.1 LEAF 工具包
为了支持独立的实体-片段内容创建，我们开发了 LEAF（Layered Entities and Fragments）工具包：一组 Python 库，为 USD 文件创建与编辑提供完整功能。LEAF 的一些关键特性包括：
- 一组通用 façade 类，例如
FnEntity、FnDomain、FnFragment、FnTechVariant，用于建模我们的实体-片段概念。我们使用这一 API 层来保证创建、编辑与遍历 USD 内容时采取一致方法，并确保其符合我们的 USD 设计模式。 - 一个规模庞大的“工厂构建器（factory builder）”类注册表，用于构建与修改特定域/片段类型。目前我们为 60+ 种不同的域与片段类型注册了 builder，每个 builder 由对应工种组（craft groups）的技术导演（TD）维护。builder 形成了一个受管理、可扩展的 USD 内容创建生态，使组织内的贡献者可以扩展整体 USD 场景描述，但必须在受约束的框架内进行。
- 一个规模庞大的配置文件库，用于定义创建新实体时的默认实体-片段拓扑。配置文件让代码与数据得以分离；这些文件使用 TOML 格式，由每个活跃项目的 TD 维护。
3.2 AssetWorkshop 工具包
下一阶段工作是开发 AssetWorkshop 工具包：一套工具生态，使艺术家与 TD 能够以直观的“超图（hypergraph）”风格 UI 查看和编辑 USD 图，并提供丰富的交互能力，包括选择、高级右键命令、拖拽等。该工作引入了：
- AssetWorkshop API：更高层的 Python 库，以简洁的面向对象 API 对 LEAF 进行封装；包含与制作数据库更紧密的集成；提供大量用于修改 USD 图的命令（例如插入域与片段）；并通过生产媒体、提示信息等 UI 元素增强界面体验。
- USD Asset Graph：一个可复用的 UI 组件（Qt 实现），可供内部应用集成。它由 AssetWorkshop 驱动，提供插入/删除图内容的右键命令、拖放添加内容，以及表示各 USD 文件状态的可视化反馈。
3.3 VirtualBreakdown 工具包
我们近期的一阶段工作是开发 VirtualBreakdown 工具包：一套围绕“虚拟拆解（virtual breakdown）”的高层工具。“虚拟拆解”是一种“配方（recipe）”，从逻辑视角描述一个或多个实体。VirtualBreakdown 的动机主要有二：
- 在某些工作流里，用户更关注内容的高层逻辑视图，而不是低层的基于资产（asset-based）的视图。例如，他们可能希望围绕镜头清单（shot manifest）工作：它描述镜头包含的角色、道具、灯光、环境与摄影机。
- 用户可能会同时处理大量实体，不需要为每个实体都打开一个独立的内存内 USD stage。在一些场景下，他们可能会更新几十甚至上百个镜头，需要一种高效方式来处理这些更新，同时避免每个镜头都付出非平凡的（通常超过 30 秒）stage load 时间。
该工作在 LEAF 的基础上进一步构建，包含：
- VirtualBreakdown API：更高层的 Python 库，用于描述分层的资产配方。该配方既可在本地处理以生成 USD 内容；也可发布（publish），其过程涉及离线处理以生成并检入 USD 内容，同时更新制作数据库。
- Virtual Breakdown Editor：Qt 实现的可复用 UI 组件，由 VirtualBreakdown API 驱动；采用类似大纲（outliner）的方式展示实体与其逻辑内容。
4 里程碑
从经典“生成式”管线向现代 USD 管线的过渡持续了较长时间，并由多个制作项目对应的里程碑节点所推动。我们在整个过渡过程中一直沿用同一套资产管理系统，使得我们可以在转型期间并行支持多套管线。尤其是，在开发一套并行的 USD 管线期间，我们仍能在《乐高大电影》（The Lego Movie，2014）、《乐高蝙蝠侠大电影》（The Lego Batman Movie，2017）、《乐高忍者大电影》（The Lego Ninjago Movie，2017）与《乐高大电影 2：二次元危机》（The Lego Movie 2: The Second Part，2019）上维持经典管线。
4.1 USD 管线原型
我们希望将 USD 集成到管线的一个有限子集，以控制风险，并保留现有工具作为后备方案。在《比得兔》（2018）上，我们选择动画管线作为合适的原型测试场景。其中一个动机是：该管线正经历从 SOFTIMAGE|XSI™ 到 Autodesk Maya™ 的平台迁移。原型开发包括：
- 一套 USD 生成器：处理制作数据库以生成对应的 USD layer（注意资产格式本身保持不变，例如烘焙几何仍使用 Alembic）。
- 一个面向艺术家的应用（Animal Logic Forge™）：使动画师能在 Maya 上下文中加载与操作 USD 内容，包括切换各 USD layer 的可见性（visibility）、激活状态（active status）以及激活变体（active variant）。
- 一个 Maya 自定义插件（AL_USDMaya）：将 USD 组合后的 stage 内容实时翻译为原生 Maya 数据。
4.2 技术迁移
我们回顾了将 USD 推广到所有管线所需的一般化设计需求。这一阶段最终形成了“实体-片段”设计模式，并开发了 LEAF 工具包以管理 USD 内容生成。原型中一些效果不佳的特性被放弃，例如：将 Python 代码存储为 USD attribute（试图在 USD 资产内部描述工作流），以及用 USD layer 存储 UI 配置（这超出了 USD 的自然职责范围）。
在《比得兔 2》（2021）上启动 USD 的广泛推广时，我们为所有管线并行生成 USD 内容，并引入基于 USD 的打包。我们对既有的艺术家工具进行了内部重构，使其以 USD 资产作为输入，但在其他方面尽量保持不变。该阶段技术风险较高，因为项目成败依赖这一新的设计模式。同时，由于工作流断裂、性能不佳或功能被认为退化，艺术家的不满情绪也较为明显。我们开发了：
- 通过交互式可视化控件，允许资产 TD 与协调人员以完全符合实体-片段模式的方式探索制作内容，并以图形方式创建与编辑资产。
- 升级工作室工具（例如 Animal Logic Filament™，我们的自研灯光工具）以使用实体-片段模式。
- 在可行时放弃技术变体的非 USD 格式支持，例如停止生成 Alembic 烘焙几何，转而使用 USD 二进制（
.usdc）格式。
4.3 初始工作流迁移
要充分实现 USD 管线的价值，我们需要升级完整的艺术家工具套件，使其原生支持 USD 概念，而不仅仅把 USD 当作后端。这一过程面临多项挑战：包括艺术家对重设计现有工具的抵触，以及更充分地向用户沟通实体-片段设计模式的必要性。相关工作在《DC 超级宠物联盟》（2022）制作期间展开，包括：
- 一个面向艺术家的应用（Animal Logic Environment Studio™）：使布景/置景（set dressing）艺术家能在 Maya 上下文中以 USD 方式加载与操作内容。这是我们首个基于新实体-片段范式的工作室工具。
- Performance（Layout 与 Animation）管线升级：采用一个与新 LEAF 管线兼容、略作修改的 Forge™ 版本。
4.4 进一步的工作流迁移
我们在《魔法师的大象》（2023）、《Treehorn 的缩小》（The Shrinking of Treehorn，2023）以及另外两个尚未公开的项目上持续增强基于 USD 的工作流。我们仍在努力补齐与经典管线的功能对等（feature parity）。目前大多数工作流都已迁移到以 USD 实体作为入口点。近期开发包括：
- VirtualBreakdown 工具包，并在 FilmStudio™ 中部署，将其作为装配（assembly）艺术家填充镜头内容的下一代工作流。
- 新的工作流工具，包括 Animal Logic Modeling Studio™，用于建模艺术家以 USD 方式在 Maya 中工作。
- AssetWorkshop 工具包，并在新的艺术家应用（Animal Logic FilmStudio™）中部署，使资产 TD 与协调人员能够以图形方式探索、创建与编辑符合实体-片段模式的制作内容。
同时，我们也观察到 USD 迁移带来的组织与技术收益：
- 以单一 USD API 替换多条工作流与多种文件格式，使技术栈更统一、更连贯；大多数概念以 USD 表达，对制作数据库的依赖降低。
- 形成了更强大的工作流工具套件来管理 breakdown 变更，并提升了对所用资产的可见性。
- 由于域 USD 资产成为映射到部门的一等概念（first-class concepts），再加上改进的 USD 打包机制，部门贡献变得更显式。
- USD 作为行业标准逐渐确立，使技术人员入职与技能提升更容易，内部教程、术语表、文档与扩展库等资源也更易共享与复用。
5 讨论
我们描述的流程会生成可被任何 USD-aware 系统消费的 USD 内容。我们的 USD 场景描述中唯一的专有概念是常见的 USD 扩展，例如 kinds。管线围绕“以片段形式的可复用 USD 内容”构建：每种片段类型都关联已注册的 builder 逻辑。从几何到材质再到运动，片段库中的任意部分都有可能被任意实体引用。需要强调的是：实体与片段最终是一种组织方式，用于在 USD 资产之上提供分类体系（taxonomy）。
我们选择以实体作为所有工作流的共同起点。所有相关资产引用都可通过 USD 场景描述获得与发现，无论该资产本身是否为 USD 文件。对于非 USD 资产，我们通过在场景描述中写入 attribute 来表示它们，以便外部工具处理。
我们当前 USD 管线的一个有用特征是：实体成为显式的“片段集合”，并会被审阅以确保组合的正确性。过去的管线没有这种显式的有效组合声明，也无法知道某个表面（surfacing）变体、绑定（rigging）变体、FX 变体或灯光（lighting）变体之间哪些组合在一起是合理/可用的。
另一个重要方面是：内容创建如今独立于制作数据库发生。过去，breakdown 内容必须先在制作数据库中注册，然后自动流程才会被触发来生成 USD 内容以与数据库同步。我们的 USD 管线反转了这一关系：LEAF API 可以在不通知数据库的情况下创建可用于制作的 USD 内容；VirtualBreakdown API 仅在最后一步出于一致性目的才通知制作数据库，而不是在第一步就依赖数据库。艺术家现在可以基于完全可用于制作的 USD 内容探索变体与想法，这些内容可以被导入到诸如 Autodesk Maya™ 等数字内容创建（DCC）系统中，同时不会因为无休止的变更（churn）而让数据库被“堵塞”。
6 未来工作
我们正在积极研究与开发的一个方向是“资产解析（asset resolution）”的优化。对于更大的 USD 图，可能需要解析成千上万个资产标识符（asset identifiers）；解析耗时的叠加会限制我们重建 USD 内容与加载 USD stage 的速度。我们也在探索减少生成文件数量的方法，这对未来的云迁移尤为重要。举例而言，我们一些更大的镜头包含 15,000+ 个资产引用（asset references），每个都需要对 Web 服务进行一次独立调用。
在实践中，这意味着资产解析通常由定制的 resolver（解析器）触发并与后端服务交互；当引用数量上升到数万量级时，resolver 的单次解析成本与批量解析吞吐会成为整体性能的关键瓶颈。
另一个持续工作方向是提供工具，使技术开发人员能够在“极端规模（extreme scale）”下工作，从而对一个制作中潜在的成千上万个资产执行更新。我们正在推进一系列工具，使 TD 能在可视化编程环境（visual programming environment）中快速部署自定义脚本，从而更高效、更强力地工作。
我们也意识到：将内容与关系从制作数据库稳健迁移到 USD state 后，在某些场景下反而使某些查询变慢。例如，我们不在 USD 之外存储实体-片段关系，使得快速判断“哪些实体使用了某个片段”变得困难。为此我们在探索缓存关键 USD 内容与关系的方法，以支持快速搜索与查询。
最后，我们也在探索改进质量保证（quality assurance）的方式：提升我们分析域贡献（domain contributions）以进行验证与兼容性检查的能力，从而限制破坏性（breaking）交付。
参考文献
- Aloys Baillet, Eoin Murphy, Oliver Dunn, and Miguel Gao. 2018. Forging a New Animation Pipeline with USD. In ACM SIGGRAPH 2018 Talks (Vancouver, British Columbia, Canada) (SIGGRAPH ’18). Association for Computing Machinery, New York, NY, USA, Article 54, 2 pages. https://doi.org/10.1145/3214745.3214779