BACK TO ARCHIVE
usd interoperability pipeline framework ubisoft bpmn microservices uri asset library game pipeline

在 Ubisoft 的分布式架构上构建可扩展且可演进的 USD 流水线

08.07.2022 ADUCG RESEARCH

image

图 1:我们使用 BPMN,从引擎提取构建一个 Asset library 流水线,以便在我们的 DCC 中离线使用。

摘要

本文介绍了我们如何在 Ubisoft 的分布式架构上构建可扩展且可演进的 USD 流水线。我们使用 BPMN 作为节点式表示方法,使主管能够构建新的工作流或修改现有工作流。我们的流程采用行业标准和 USD 文件格式进行设计,以实现可互换性,并且易于扩展,能够部署到我们多站点的工作室与团队中。借助运行在我们内部云计算基础设施上的 Microservices 及其语言中立性,我们可以利用由全球各地团队在多个平台上开发的现有内部技术和新技术。

1 引言

视频游戏行业中的 Asset Creation 流水线与 VFX 类似,但也有围绕游戏引擎的一系列独特挑战。资产可以在 Digital Content Creation tools (DCC) 中形成,但它们的最终归宿是游戏引擎数据。多站点要求和多个工作室意味着资产数据必须能够在不同工具、流水线以及各类团队之间进行交换。此外,更长的视频游戏制作生命周期以及可下载内容(DLC)意味着,即使在发布后的许多个月,这些资产仍需要作为已“创建的内容”被识别并可访问。

本文旨在详细说明,我们如何使用 VFX 与视频游戏行业标准来创建我们新的游戏内与 VFX Asset Creation 流水线。

2 我们流水线的四大支柱

在本节中,我们将解释如何调整四项主要行业标准,以在 Ubisoft 为我们的游戏内与 VFX Asset Creation 流水线开发一个可扩展且可演进的流水线。在第 2.1 节中,我们讨论如何使用 BPMN 的节点式方法来帮助主管创建和修改他们的工作流。第 2.2 节说明 USD 如何帮助我们的流水线拥有统一的数据格式。在第 2.3 节中,我们将讨论如何改造 URI 格式,以便在游戏制作语境中标识资源。最后,在第 2.4 节中,我们将解释为了在基于 Microservices 的分布式架构上实现可扩展流水线,我们所做出的决定、选择和开发工作。

2.1 使用 BPMN 创建工作流

在我们旧有的 Asset Creation 流水线中,由主管创建新工作流或修改现有工作流,意味着需要对代码库进行大量修改,并且直接依赖开发团队。

解决这一低效问题的关键在于模块化流水线。主管可以从一组现有的、预定义的、彼此独立的流程中进行选择(这些流程由开发团队创建),并根据我们的生产需求来构建他们的工作流。为此,我们选择使用 Business Process Model and Notation (BPMN) [Rosing et al. 2014]。这是一种标准化的可视化方法,已在从零售到汽车制造等不同行业中得到验证。BPMN 以彼此分离但又独特的流程形式,提供了对工作流的直观表示,并有助于团队之间进行沟通,从而精确定义流水线。流程可以被定义为 BPMN 模板,并根据流水线需求进行版本管理与扩展。诸如用户任务、生产跟踪、文件提交、媒体编码和通知系统等不同流程,都可以由开发团队实现为独立的 BPMN 流程,并通过 BPMN 建模界面向主管开放,以便他们设计并创建所需的工作流。

图 2 展示了一个由我们的主管创建的 BPMN 示例,用于将一系列图像编码为视频,并将结果上传到我们的生产跟踪工具( )。

image

图 2:主管为媒体编码与跟踪创建的 BPMN 流程示例。

2.2 使用 USD 实现可互换性

近年来,Pixar 的 Universal Scene Description (USD) [Disney/Pixar 2016] 在 VFX 行业中的成功推动了它在视频游戏行业中的采用。然而,在视频游戏行业中使用 USD 也伴随着一些挑战。例如,原生不支持非 3D 数据(如游戏内玩家库存),或者无法支持实时流而非关键帧,这些都是该格式的不足之处。尽管存在这些缺点,USD 仍然是统一我们文件格式、并满足我们在 DCC 中进行资产生产时对可互换数据需求的显而易见的选择。我们使用 USD 标准格式以及我们自定义的 USD 节点(用于存储 rig 和约束数据),将视频游戏资产从其引擎原生数据格式转换出来。此外,USD 还帮助我们简化了视频游戏资产的打包与交付,以满足我们的 CG 和营销需求,并交付给外部合作伙伴。

2.3 使用 URI 进行资源标识

视频游戏行业中数字资产的生产,与 VFX 行业相比,遵循着不同且有时更长的生命周期。Game as a Service (GaaS) 以及更长的制作周期意味着这些资产会被保存更久,而它们的存储位置也可能不断演化和变化。为了将资产数据与通常在工作室级别定义的物理架构解耦,其他公司已经决定使用 Uniform Resource Identifier (URI) [Staeubli et al. 2019]。

URI 比磁盘路径更具语义,搜索引擎也可以很容易利用其可分解能力。对这种架构进行抽象,使我们能够在工作室和项目之间共享资产,并支持随着项目推进而在工作室内部发生的演进。诸如 workgroup、status、version 等 URI 片段,都是由主管设计和选择的,以便在遵循 VFX 与视频游戏行业通用标准化流水线词汇 [Polson 2015] 的同时,完整表达 Ubisoft 的 Asset Creation 工作流。

此外,通过将 URI 与 object id 关联起来,URI 也是一种很有前景的方式,可帮助我们预先为迁移到云端做好准备,并使我们彻底摆脱工作室范围内静态树状结构的束缚。在图 3 中,我们展示了如何使用单个 URI,通过部门、状态和文件格式来表示一个生产中的资产。

ubi://Helix.ACK.chr/Eivor?workgroup:Modeling:status:wip:version:05:format:usd:lod:high
scheme authority path query

图 3:一个表示由建模部门正在制作的 3D 资产的 URI。

2.4 使用 Microservices 实现可扩展性

我们旧有的 Asset Creation 流水线经历了多年的生产演变,逐渐变得不够灵活、难以扩展,也无法跟上新技术的步伐。要在不同工作室、团队和平台(Windows、Linux)之间支持这样一个单体代码库,使得更新或修改某项特定功能需求变得更加困难。为了解决这一问题,我们选择将流水线拆分为若干独立组件,并将每个组件创建为独立、自包含的单元 [Golembeski et al. 2017]。这种拆分使我们能够围绕流水线的特定需求开展更聚焦的实现工作。Microservices 的语言中立性(即不同的 Microservices 可以用不同的编程语言编写,例如 Go、Python 和 C++)使我们能够利用其他团队和工作室开发的现有内部技术,例如云存储、数据库和媒体编码。它还使我们能够为外部资产生产跟踪软件( 和 )创建一个统一且安全的入口点。

image

图 4:我们核心 Microservices 的简单说明。

3 示例用例:离线游戏资产库

Asset library(见图 1)是我们基于第 2 节所提支柱创建的第一条流水线。其目标是从引擎提取中填充一个 Asset library,以便在我们的 DCC 中离线使用。

四个核心 Microservices(见图 4)以及两个流程(分别在本地和内部云计算基础设施上运行)通过 BPMN 向主管开放,以定义他们的 Asset library 提取工作流。图 5 展示了由主管组装并看到的 BPMN 逻辑。

image

图 5:我们的主管为离线游戏 Asset library 设计的 BPMN 流程。

开发团队负责为所需流程编写底层功能。图 6 说明了当用户运行该流水线时被执行的工作流。

来自引擎的所有资产都会被提取、转换为 USD,然后存储到我们的云存储解决方案中:若该资源是新的,则以唯一的 URI 标识符作为新资源存储;若其已存在于存储中,则通过现有 URI 进行引用。

4 讨论与即将到来的挑战

在应对当前视频游戏活跃制作周期中日常生产需求的同时,将我们复杂的 Asset Creation 流水线拆分为独立组件并不是一项容易的任务。

我们观察到,将创建工作流的责任从开发者转移给主管,不仅把流水线流程的所有权转移给了他们,也改变了开发者的思维方式。开发团队必须从底层技术层面进行思考与实现,以适应主管新工作流中潜在的使用场景、设计想法和性能需求。虽然我们能够在云端实现大多数流程,但其中一些流程,例如 USD 转换和资产比较,在用户机器和本地农场上似乎更快、更高效。这个限制迫使我们设计更复杂的 BPMN 方案,以处理带有等待再继续流转的异步流程。为了处理这类复杂流程,我们在优化设计和性能方面仍有更多工作要做。

image

图 6:客户端、BPMN 流程与我们各类 Microservices 之间的交互。

5 结论

Microservices、行业标准以及统一的文件和资源约定,正在为创建标准化流水线打开新的大门和机会,这些流水线具备跨平台、可扩展和可演进的特性。前方的道路仍然很长,但我们相信自己正走在正确的道路上。

本文采用 Creative Commons BY-NC-ND 4.0 协议进行授权。

BY-NC-ND: 署名-非商业性使用-禁止演绎

End of Article