SEED 如何用 Unity URP 渲染玩家无限构建的世界

Nov 6, 2026

Adam Axler - Unity

Senior Content Marketing Manager

Platforms and publishingTarget platforms

种子 | Klang Games

为方便起见，此网页已进行机器翻译。我们无法保证翻译内容的准确性或可靠性。如果您对翻译内容的准确性有疑问，请参阅此网页的官方英文版本。

你无法预测玩家会生成什么。在种子中，那就是全部的重点——也是核心的渲染挑战。

种子是 Klang Games 使用 Unity 构建的持久型 MMO 沙盒游戏。它设置ON一个遥远的星球上，玩家管理着名为“幼苗”的自主角色，生成家园和企业，在一个由Player驱动的Economy中进行贸易，并用自己的角色和法律来组织社会。玩家日志后世界仍关闭running，并且它在不断增长。每栋新建房子、商店、树和幼苗都ON Unity 渲染性能带来更大的压力，这涵盖了从结束 PC 到手机的各种硬件。

该模拟本身在 Klang Games 的服务器上运行。Unity 客户端的任务是渲染 Server 传来的任何状态，因此其工作负载取决于玩家建造了什么，而不是 Team 计划了什么。

“由于SEED是一个完全由Server权威的游戏，客户端主要读取和渲染状态并转发玩家交互，例如点击或摄像机移动，”Klang Games的图形工程师Artem Dyadichkin说。

我们与高级游戏工程师 Dyadichkin 和 Nikita Fetisov 谈了关于使用通用渲染管线 (URP) 来渲染玩家构建的社会、保持数千个小物体成本低廉，以及在 PC 和移动设备上使用真实玩家数据查找瓶颈的问题。

一个由微小碎片构建的世界

SEED 的艺术风格在任何代码运行之前就完成了大部分的缩放工作。这款游戏是风格化的低多边形，它不依赖于 Textures，而是将大部分表面数据存储在几何体中。

“我们的大部分颜色数据实际上是存储在顶点数据中的，”Dyadichkin 说。“顶点数据知道它是哪种颜色，它具有哪种材质定义——它是金属还是平滑的？”All那些东西都已烘焙在网格本身中了。

这节省ON着色和内存带宽，这ON移动设备来说最重要。

建筑将事物推向极端。SEED 不是将每个结构视为一个大型网格，而是从许多小的、砖块状的模块构建建筑物：在一米网格上设置墙壁、地板、屋顶边缘和角落。玩家放置粗糙的构建方块（体素），游戏将每个方块扩展成大约 15 个模块，其中大约一半构成构建的外观，一半构成其内部，内部仅在Player看向内部When生成。在SEED最繁忙的岛屿之一上最大的社会拥有172座建筑，这些建筑由大约12,500个体素或190,000个模块组成。

Dyadichkin 说：“我们利用 BatchRendererGroup 来渲染和将它们批处理在一起，我们通过作业来处理这些批次。”“尽管我们需要渲染非常多的模块，但从纯粹的渲染性性能看，建筑本身从未成为瓶颈。”

这些任务在C# Job System上运行，团队使用Burst compiler进行编译。Dyadichkin 说在 SEED’ 的客户端代码中，它们几乎总是相辅相成的。

种子 | Klang Games

在URP中保持默认路径

SEED 使用 URP 在 PC 和移动设备上进行缩放，而 Klang Games 刻意贴近 Unity 的默认设置。

“我们尽量坚持使用 Unity 默认决方案，这样我们就可以确保无论Next更新是什么，它都能被覆盖，”Dyadichkin 说。

这很重要，因为Team大约每年升级Unity一到两次——SEED目前运行在Unity 6.3上，随着Project的发展，会采纳新的渲染Features。当游戏需要自定义功能时，Team会扩展 URP 而不是替换它，使用自定义定义渲染器Features来实现游戏指定的的特效和交互。

他们对Shader Graph的使用遵循相同的原则。自然环境 Assets 使用默认的 Lit shader，而角色和物体使用带有自定义 Lighting 通道的 Unlit 着色器。无论哪种情况，Team都不必担心破坏 URP 的性性能Features。

Dyadichkin 说：“你可以放心，如果你创建着色Shader Graph，它不会破坏 SRP [可可编程渲染管线的批处理，也不会破坏 GPU Resident 绘制器。”“确信All URP 核心Features仍然受支持，同时您仍然有Space在着色器中自定义任何您想要的内容，这非常强大。”

在一个玩家而非设计师决定客户需要绘制多少的世界上，那个安全网很重要。

最大化跨平台的性能

与数千个对象交互

玩家构建得越密集，渲染一个社会就越困难——也越难让他们点击其中的任何部分。

当玩家放大时，SEED 使用像素级拾取。一个自定义渲染器功能将对象绘制到单独的渲染目标中，这是一个 GPU 渲染到而不是屏幕的离屏纹理。每个对象都用一个唯一的 id 进行编码，CPU 和 GPU 都可以读取它。客户端读取光标下的像素，以查找 Player 悬停在哪个对象上。

ON移动设备上，指尖的精度远不如光标，因此客户端还会检查每次点击周围的像素。如果检测到附近有多个对象，它会向 Player 显示一个列表供选择，使在建筑密集的区域更容易选择较小的对象。

When玩家变焦时，客户端会切换Physics线投射，因为在宽的视图野中进行 GPU 拾取更难Scale。

那些射线投射背后坐着数量的碰撞体。SEED 使用 Unity Physics 不是用于模拟，而是为了快速启动它们和查询它们。

“每棵树都有一个碰撞体体，每个对象，甚至每个构建砖块都有一个，角色和幼苗也是如此，”Dyadichkin 说。我们可以非常快速地引导（或“构建”）这amount的碰撞体，然后针对它们进行查询以进行广告位检查和Other交互。

一旦Player打开一个构建，其内部就会显示出来，客户端在玩家在楼层之间Move和检查各个房间时需要轨道更多信息。一个持续running的任务确定每个对象是否在构建物内部或外部，以及它占据的房间和Floor。

“这使我们能够做各种事情——禁用或启用游戏对象，或者设置正确的渲染图层来控制照明情况，”Dyadichkin 解释道。

种子 | Klang Games

分析世界玩家实际构建的内容

优化Player构建世界最难的部分是获取真实数据。Klang Games 从实时游戏中获取。

Team会为灾难恢复保留服务Server快照，一旦玩家建立了足够大的社会，这些快照就成为了测试用例。

费蒂索夫说：“我们可以恢复玩家实际构建的内容，并将使用于性能测试和大ScaleFeatures测试。”“我们可以利用这些已建立的社会，而不是从零开始或尝试自己模拟数据。”

在本地加载一个大城市的快照时，在PC上暴露了一个意外的CPU渲染瓶颈。

“我们的游戏大多数时间不是受GPU限制，而是受CPU限制，”Dyadichkin说。这是一款风格化程度很高、低边形、几乎没有Textures的游戏。

使用Unity Profiler，Dyadichkin发现渲染线程花费的时间比预期的要多，因为它在提交绘制调用。该Team使用GPU Resident Drawer，所以Dyadichkin期望它能实例化这些对象。帧调试器显示了不同的情况。

种子 | Klang Games

“我们仍然默认使用SRP批批处理而不是混合批批处理，”Dyadichkin说。结果发现 GPU Resident 绘制器没有捕获All这些对象，因为我们的大All预制件制件都有 LOD 组组。

在SEED的Scale上，差异很重要。SRP Batcher 降低了设置每个绘制调用的 CPU 开销，但仍然为每个对象提交一个。GPU Resident 绘制器功能更进一步，将共享网格和材质的对象分组到实例化绘制中，帧调试器器将其标签为混合Batches。有数千个小物体，这就是许多轻量级绘制Calls和少数大型绘制调用之间的区别。

导致物体丢失的罪魁祸首是动画 LOD 交叉淡入淡出。特效看起来更好，但它仍然将对象排除关闭 GPU 驻留绘制器路径之外。

我们Disabled了动画部分。他说，我们仍然有交叉淡入淡出，但现在是手动设置的 Transitions。现在绘制调用再次实例化了，这减轻了我们 CPU 渲染线程的负载。

种子 | Klang Games

在移动内存中渲染一个成熟的社会

在移动设备上，SEED 的渲染遇到了不同的限制。“ON移动端，我们不是受CPU限制的——我们是受内存限制的，”费蒂索夫说。“那是我们Project的主要弊端。”

一个成熟的社会可以包含大量的建筑物、室外物体、角色和网格。客户端渲染的每个网格和材质都必须先装入内存。Klang Games 严重依赖内存性能分析器和内存快照比较来追踪内存的去向。Team 发现由于一个中断的引用、重复了相同材质的 Addressables 依赖项以及比需要大得多的 C# Collections 而存储了三次纹理。

“很多问题出现ON桌面端是没问题的，人们没有注意到，但ON移动端是个大问题，”费蒂索夫说。我们非常依赖 Unity 内存性能分析器，尤其是内存快照差异。

即使没有Textures，几何体体也会累积起来。

“有些网格相当粗糙，尤其是树木，”费蒂索夫说。“如果你加载所有 LOD，一棵树可能会占用数兆字节的内存，而且我们有许多树的变体。”

因为Team builds Addressables per platform，所以它可以将简化的树形结构发送到移动设备而无需更改任何游戏代码。“加载桌面ON的椅子和移动设备ON的椅子使用相同的代码，”费蒂索夫解释道。“但 Addressables 本身可以被优化用于移动的 Assets。”

更大的转变是完全用移动设备ON的 LOD 组而代之。经典的 LOD 意味着在内存中为每个对象类型存储多个网格——这与 Fetisov 描述的树木的成本是相同的。网格 LOD 在 Unity 6.2 中引入，它将每个细节级别存储在单个网格中，并且 SEED 的移动变体现在独家使用它。它还减轻了 Klang Games 小型艺术Team的工作量。

“从 LOD 切换到网格 LOD 是使游戏世界能够ON移动Devices上渲染的关键一步骤，”Fetisov 说。

种子 | Klang Games

为玩家的下一次生成而设计

SEED 的核心渲染挑战不会消失：玩家决定客户端需要绘制什么，而且他们永不停止构建。“这在我们在这些Player创建的世界中设想的视觉保真度与结束DevicesON的稳定帧率之间是一个常量的平衡，”Dyadichkin说。

Klang Games 无法预测玩家Next来会生成什么——但它可以测试他们已经建造过的东西。

“从第一天起就为你的TargetScale设计、生成和测试，”费蒂索夫说。“尽早针对实际负载进行配置文件，并保持这样做。”

尝试 Unity 6.7 Beta 中的新建Features