Rendering Engine 分类法初探 (A Taxonomy for Rendering Engines)

只有结合语境才能解决复杂问题。

是时候成长了。 我们（Steve, Stephanie, Natalya, Michael 和我）每年组织的 REAC 大会的主要目标之一，就是分享实时渲染领域那些“来之不易”的经验教训。这些经验目前只能通过在行业内工作数十年（并且可能需要在许多不同的项目和公司工作）才能获得。游戏开发者和计算机图形学从业者是一个伟大的社群，我们在制作方法上分享了很多，我们为推动技术进步而自豪，我们希望其他人也能了解它！不可否认的是，如果没有这种开放性，我们将无法创造出今天如此令人难以置信的技术。但是，在很多方面，我们仍然是一个年轻的行业，我们喜欢谈论闪光点，但不太关注幕后那些“不那么迷人”却往往能带来巨大差异的决策。而且因为我们不习惯这样做，所以我们在这方面做得不好！几天前，我和一个人（稍后我会问他们是否愿意署名）聊天，他们说他们“讨厌”架构讲座，因为大多数时候只是展示某个东西是如何工作的，而没有提供有用的语境来评估该解决方案是否值得考虑。我完全同意！我认为作为一个行业，我们需要一段时间才能理解如何最好地呈现这些经验。这就像一篇关于“成功 CEO 的 10 个习惯”的懒惰文章与试图发展管理理论的学术文本之间的区别。理论需要假设、语境，它们需要可复制、可证伪。 一个好的开始是开发一个实时渲染引擎的分类法。一种描述语境的语言。这在所有成熟的技术中都是...正常的。例如，我们来考虑一下数据库。没有人会说“这是你如何制作一个数据库”，这是一个非常模糊的说法。什么类型的数据库？关系型、键值型、时序型、向量型、图型、空间型、列式？有什么特点？并发读、写或两者？分布式？一致性？持久性？事务性？ 从高级用例和技术需求中，我们可以讨论算法和数据结构、架构 - 发展理论和实践。 也许我们也被图形相关目标的相对简单性所宠坏了。渲染方程在追求照片级真实感的过程中，提供了一个简单的、客观的进步指标，我们可以用来进行比较。对于其余的部分，更多的对象，更多的多边形，更多的纹理，在单位内存和时间内 - 是我们想要实现的目标的一个好的通用代理。与围绕它们的引擎的其余 90% 相比，驱动我们 GPU 的紧密循环相对更容易谈论。

一个（示例）分类法：3x3 维度。 以下是我们可能需要考虑的几个维度：

  1. 产品特性。

    • 引擎用户。从窄到宽：单个团队专有，多个团队，单一类型中间件，多类型中间件，用户生成内容平台。
    • 平台支持。单平台（例如 web 或 PlayStation），多平台，多模式（计算机、手机、游戏机、Web、汽车、VR...）
    • 可扩展性需求。目标是主要针对一组具有大致相当能力的设备，还是引擎旨在扩展？缩小内容（细节级别），放大内容（程序细节生成），还是两者兼而有之？

  2. 生产：人员与流程。

    • 内容抽象。引擎是用于 ad-hoc 渲染代码的 API（即没有内容管道，引擎是绘制抽象），还是数据驱动的？如果是后者，数据是“通用的”（带有 shaders / shadergraphs 的任意网格属性），还是必须遵守狭窄的模式（每个模式类型的专门/“硬编码”渲染循环）？
    • 迭代。引擎是否优先考虑数据的实时编辑（无需烘焙 - UGC 也很常见），还是用于“烘焙”？从更改到审核需要多长时间？
    • 用户。引擎是为谁设计的？艺术家驱动还是工程驱动的生产？引擎的目标是专家还是易于使用？

  3. 技术要求。

    • 延迟。数据是否可以进行双缓冲和三缓冲以帮助并行化，或者我们需要尽可能快地执行？
    • 动态性。我们约束哪些数据保持静态，以及允许更改哪些数据？
    • 流式传输。无（内核渲染），本地（磁盘到内存），分布式（云/服务器到客户端）。

第十个维度。

...是成功（或规模）。这可以说是最重要的一个，但我认为这适用于一般的软件工程 - 而不是 3d 渲染特有的东西。 没有用户的技术（在很大程度上）是微不足道的。 工程问题的规模随着产品的用户数量（包括当前和历史开发过程中的总数）呈指数增长。 同样，也与开发该产品所需的团队规模成比例。 可能会有人认为代码与规模无关 - 一个好主意就是一个好主意，但事实并非如此。 团队规模和组织会改变代码的结构方式，但即使在算法上，某些解决方案也可能难以大规模维护，过于复杂而无法开发等等。

结论？

通过这些属性，我们可以描述大多数架构选择。 最佳线程模型是什么？ 取决于延迟要求。 最佳 API 或绘制调用抽象是什么？ 取决于平台支持和内容类型。 从游戏/模拟获取更新的最佳方式是什么？ 取决于我们的引擎需要有多大的动态性，每帧可以更改多少实体。 描述场景的最佳数据结构是什么？ 取决于内容类型和用户期望 - 等等。 然而，我并没有呼吁采用这些类别作为引擎讨论的标准，这会不必要地冗长，而且我认为僵化的结构没有任何价值。 我的邀请是让人们更多地思考，并展示他们认为与给定选择相关的最佳语境描述符 - 而不是盲目地遵循这个例子。 狭隘地应用的引擎可能需要更多的规范才能提供语境。 为了推动交互式照片级真实感的最新技术而构建的用于建筑可视化的引擎，可能需要与赛车游戏引擎或自上而下的策略图块引擎不同的选择 - 而且如今，越来越多的行业使用实时 3d。 但我怀疑与这些更具结构性的属性相比，“文体”选择对架构选择产生重大影响的情况相对罕见。 我们正在成为一个成熟的行业，我们不太可能发明新的游戏创意，让我们获得数量级更大的特许经营权，AAA 更有可能希望更高效地覆盖更多人。“商品化”。 我们将需要更好的语言和新的重点。 （感谢 M.Vance 审阅了预发稿） 2025-04-27, 星期日, 4 月 [Home]