前言

在高质量写实渲染方面，UE引擎无疑是比Unity有着大幅领先的——这种领先主要在于渲染管线、全局光照、GPU集群渲染等方面，而我认为更重要的是在工具化实现高清渲染方面（即它是对于艺术家更友好的一款引擎）。最终这种开发和渲染特性传达给玩家的感觉，就有例如“建模”更精细，整体光感更好更“真”，特效更亮更炫等。

但是反过来，大家可能也有一种感觉，就是现有的玩家硬件其实还不够迎接这种技术升级。因为概括来说这种技术提供的是“不人工优化模型网格”的一种特权，它带来的优势更多是高清大型项目中的，对GPU有一定的算力要求，这从出发点上就一定程度上放弃了下沉到中低端设备的可能性。而且从文章中我们可以看出，其实不人工优化网格不等于不生成LOD，只是他们的LOD自动化构建有一套搭配他们新渲染方案的定制化的方案。

由于我不是从事UE方面开发的工作，因此虽然之前大概了解过UE5中实现巨量多边形的大概思路，不过如果不过写文章我可能不会进行逐页翻译粗读。这次还是以读分享文稿为主，由于篇幅原因就不摘录讲述者的原文了；打星号的部分还是我个人的一些补充说明。

另外，由于篇幅原因会分成两次来读，这篇文章是上篇。

1 目标

梦想——目标

像实现虚拟纹理一样实现虚拟化几何体（指像虚拟纹理突破尺寸和显存限制）
不再有性能预算——多边形数量、渲染调用次数、内存
直接使用电影质量的美术资源（不需要手动优化）
不损失质量

*看过当年UE5首次演示的应该有印象，这些就是它们的核心突破方向和宣传点。

实际情况

——比虚拟纹理难得多

不仅是内存管理（地址映射）问题
几何体的细节会直接产生渲染开销
几何体不具备一般可过滤的特性（不像纹理格式，可以应用各种信号学意义上的滤波方法）

2 备选方案分析与拆解

*这部分可以说探索了现代引擎渲染技术的方方面面，虽然长但是很有价值。

体素？

体素和隐式表面（通过函数定义的）通常是这类问题的有潜在优势的讨论方向。
图中的原网格被重采样成了右侧的基于有向距离函数的体素（13M narrow band SDF voxels）。
体素方案的核心问题是采样精度不好把握以及数据量相对较大（在相对无损的情况下）

——（网格体素化）并不是要完全改变全部CG工作流

支持把任何地方制作的网格体进行导入
仍有UV和细节纹理
只替代了网格，而不是纹理、材质和相关工具

——但尽管如此也带来了更多难解的问题

体素如何与UV进行映射？
小于体素采样精度的尺度下，无法表现细节和动画

*基于这些现状，体素目前无法称为既有网格结构的替代方案。

细分表面？

细分表面既可以作为平滑增加细节的方案，也可以作为合并减面的方案。
采用自动化的网格细分并不会减少网格方面的限制，并且往往会为艺术家引入一些额外的限制，否则往往表现不如传统的手工低面数网格模型。

替代（移位）纹理？

在某些情况下可以用低网格模型结合雕刻出的替代纹理数据，以类似法线贴图的方式来提高精度
但对于右侧的铁链，是无法通过替代纹理来取一个低网格模型然后提高精度的，因为位移操作不能改变物体的“属”（Genus 拓扑结构的概念，可以简单理解成洞的数量）——就好比无法通过位移操作把圆球变成圆环
因此它不能作为一个常规普适的网格简化方案

基于点的渲染？

单个点本身渲染会很快，但整体结果会有overdraw问题，或者需要补洞
点之间的几何关系也没有保存下来

最终选择了三角形作为基础渲染单元

尽管其它的一些方案也能围绕其艺术风格上的特点构建一套完整的渲染系统，但Unreal需要普适的渲染方案。因此基于之前的一些对照方案，Nanite（UE引擎的一个模块）选择了三角形作为基础渲染单元。

3 管线概述

GPU驱动的管线

——渲染器的现行模式

跨帧进行GPU场景数据保持
在场景物体变化时进行稀疏的更新
所有顶点和索引数据保存在一个大资源文件中

——每个渲染视图中

GPU实例剔除
三角形光栅化

——如果只绘制深度，整个场景可以在一个DrawIndirect（集成好的间接绘制指令）中完成

*强调是GPU驱动的意义在于减少与CPU的交互并尽量通过显存内部处理、传递和运算数据，这也是现代渲染管线的趋势。Cluster这个处理逻辑也是建立在GPU的并行计算优势之上的。

三角集群剔除

将三角面分组为集群——为每个集群构建包围盒数据
基于包围盒剔除集群——视锥体剔除、遮挡剔除

遮挡剔除

遮挡剔除主要针对多层深度缓冲来进行（后续缩写为HZB）
剔除计算时，依据包围盒对应的屏幕空间尺寸来判断合适的HZB层级
当屏幕尺寸小于等于4X4时，直接和最低层级的mip比较

*我之前一篇介绍遮挡剔除的文章里详细介绍过Hiz剔除是怎么计算的。

遮挡剔除

HZB怎么来的？在还没有渲染任何东西时是没有HZB的（尤其是第一帧时）
把前一帧的Z-Buffer投射到当前帧呢？往往需要额外的补洞方案，且剔除的结果总是粗略和不够保守的

双pass遮挡剔除

上一帧可见的物体很大程度上会是在这一帧可见的，至少是一个视为遮挡物的好的选择
双pass的方案：绘制前一帧可见的物体；构建HZB；绘制上一帧不可见但这一帧可见的物体
这几乎是一个完美的遮挡剔除方案：它是保守的（不会额外剔除），只在一些极端的可见性变化的情况会失效

从材质上解耦可见性属性

By that I mean determining visibility per pixel (which is what depth buffered rasterization does) is disconnected from the material evaluation.

（这种解耦）意味这逐像素确定可见性——就像深度缓冲光栅化中做的一样，将其和材质公式的关联性去掉。

消除：

光栅化过程中的shader切换（which is 有性能开销的）
材质评估过程中的重叠绘制
为避免重叠绘制而进行的前置深度pass

处理密集网格体时的像素多边形低效

备选项：

REYES（Render Everything Your Eye Sees，渲染所见的一切）
纹理空间
延迟渲染可用的材质

*这部分思路以及后面围绕这个逐像素的策略进行的改装就是UE5管线的精华了。

可见性缓冲

把几何体信息写入屏幕——深度、实例ID、三角形ID

逐像素的材质shader：

加载VisBuffer（可见性）
加载实例的空间变换数据
加载3个顶点的索引
加载3个顶点的坐标
把坐标变换到屏幕空间
得到目标像素的重心坐标
加载和插值参数

可见性缓冲

听起来不太现实？但实际不像它看起来那么慢

有很多可用的缓存数据
没有重叠绘制或像素多边形低效问题

材质pass写入了GBuffer——可以与我们其它的延迟着色渲染模块集成

现在我们可以在1次绘制中渲染所有不透明几何体

完全GPU驱动
不仅是深度的prepass（也是几何体的绘制pass）
每个视图仅光栅化三角形一次

*这部分可以说就是这个方案的核心，一些方面消耗虽然变高了，但另一些方面节省了。

次线性缩放

Linear scaling in triangles is not ok. We can’t achieve our goals of “just works no matter how much you throw at it” if we scale linearly

三角形的线性缩放是不OK的，如果不管引入多少三角形我们都仅线性缩放，我们就无法达成目标。（这里scale直接理解成规模变化也没问题）

Virtualized geometry is partly about memory. But ray tracing isn’t fast enough for our target even if it fit in memory

虚拟几何体是部分关于（节省）内存的，但（对现有数据结构的）光线追踪即使在内存达标的状态下还是不够快。

次线性缩放

In terms of clusters, we want to draw the same number of clusters every frame regardless of how many objects or how dense they are.

在集群方面，我们希望绘制相同的集群数量（和像素数量相关），无论每一帧有多少物体或密度如何。

It’s impractical to be perfect there but in general the cost of rendering geometry should scale with screen resolution, not scene complexity. That means constant time in terms of scene complexity and constant time means level of detail.

虽然没有完美实践过，不过通常来说渲染几何体的开销是与屏幕分辨率正相关的，而不是场景复杂度。这意味着在（不同）场景复杂度方面的恒定时间，而恒定时间意味着采用LOD。

*这里再次突出了这个方案的重点，就是“逐像素”或者规模与像素正相关。