Home News Epic王祢:详解虚幻引擎5核心技术Nanite

Epic王祢:详解虚幻引擎5核心技术Nanite

GameLook专稿,未经授权不得转载!

GameLook报道/9月24日-9月26日,北京国际游戏创新大会(BIGC 2021)正式举行。在25日下午Unreal Circle北京站活动上,来自Epic Games China的首席工程师王祢带来关于Nanite的特性剖析和原理讲解。

随着不久前UE5 EA版本的发布,越来越多游戏团队开始进行UE5特性的探索和使用,其中一大核心功能Nanite更是引起了同行的探究兴趣。而在演讲中,王祢分享了Nanite的设计核心思想、Cluster生成、裁剪和LOD选择、光栅化、材质、串流、压缩以及未来可能进行的各种改造,干货极多。

王祢表示:“Nanite现在的特性已经支持PC、下一代的主机PS5、Xbox Series X/S,同时我们也在尝试优化到PS4、Xbox这一代的主机上。”



以下是演讲实录:

王祢:大家好,虽然Nanite细讲可以聊几个小时,但因为时间关系,今天我想尝试一下简介,同时稍微讲一些技术原理。

用过UE5、或者看过我们视频的都知道,Nanite是UE5中主打的两个渲染功能之一,是一个全新Mesh的表现形式,我们叫它虚拟微多边形几何体。

Nanite解放了之前美术的同学、或者艺术家们制作模型时的很多限制,现在大家可以用影视级资产直接导入引擎。其实我们自己也有做过一些尝试,百万、上亿,甚至几十亿面的模型导入引擎,场景中放入几十万、几百万Mesh的实例,引擎还是可以在比较不错的显卡上有非常流畅的表现。

这些资产除了ZBrush自己雕的高模,也可以使用我们提供的Megascan扫描库,我们未来也会有更简单的工具流,帮助大家以比较低廉的成本,自己做高质量的现实物件扫描、导入引擎。

Nanite现在有图上这些特性,大家可以看到现在支持PC、下一代的主机PS5、Xbox Series X/S,同时我们也在尝试优化到PS4、Xbox这一代的主机上。目前在一些设置调整上是可以工作的,我们还在优化效率。



今年的EA版本我们放出的Ancient Game,相比去年的那个Demo,我们对整个Nanite的品质和效率都做了非常多的提升。比如说磁盘的压缩、内存和显存编码的访问效率都做了改善。同时也支持Nanite Mesh存储它对应Lightmap的一些信息、可以支持烘焙的数据。

现在Nanite也支持我们的Geometry Collection,同时我们也支持以自动流程去生成一些减面的proxy mesh。比如开了Ray Tracing以后、开了物理模拟以后,因为Nanite的面数实在太高没有办法跑,而我们的流程是会自动帮你做这些事情。

另外,我们之前的那个版本里面其实是有一些像素误差的,硬件自动帮你计算的解析微分单元的误差项,你自己是算不出来的,而我们现在对此也做了一些改进。再然后也支持多光源、多View的投影,在Lumen和virtual shadow map等技术里都有很大的体现。

我们先看看今天讲的主要内容,Nanite其实是个完整的GPU Driven管线。在主机上,很多3A自研引擎GPU Driven的这套管线已经发展了几年,也已经比较成熟。

为了高效地完成剔除,其实UE4也已经在4.22版本以后,开始慢慢往GPU Driven管线上靠。我们从4.22开始,底层就加入了GPUScene,把整个渲染器每帧完全场景重新构建在CPU上做一部分剔除,然后发给GPU要绘制的绘制指令和所有绘制要用到的数据,改成了只更新那帧里变化的数据,而整个不管可见不可见的场景数据其实都在GPU上面。

那Nanite在这个基础上又做了很多新的工作,其中跟别的GPU管线相比,最重要的就是无级的LOD切换。

一般的LOD切换是基于单个Draw的Mesh对象,GPU-driven管线也可以在GPU上做到判断出来用哪一集,然后GPU去选择它的LOD,但这个时候LOD变化还是很明显、会有跳变的。而我们希望做到的是,你在镜头拉近拉远观看的时候、非常高面的模型在切LOD的时候,你是完全不可见的。这里有一个比较关键的地方,我们在把Mesh切成处理的一个个Cluster的时候,我们有一些算法用来保证LOD的切换是完全没有crack这种边。

我一开始讲的就是这个核心思想,即我们是怎么去思考的。

一般来说LOD的切换,比如我把一个Mesh切成了一组Cluster以后,一旦要去减面,即针对每个Cluster、比如两个合并一个这样分级去做合并以后,我要保证降了一级的LOD和上一级LOD没有边界的crack。

那这种情况下会有一个问题,比如LOD 0和LOD 1的边界锁了,保证了LOD0模型的外边界其实和LOD1是一样的,那么LOD1还可以跟2接、2可以跟3接,最后最高那级LOD的面数其实坍缩全都在别人界上,你还是搜不到、很小,而且减面质量其实非常差的。

我简单演示一下,比如说这是我最细的那级LOD,它的每一个Cluster。事实上我们在切分它上一级,切LOD变得更粗的时候,大家可以看到它的边界其实是跳开的,跟之前不重叠。

然后切到上一级,完整切换后我再往上一级,也是会再切成更粗的Cluster。大家可以看到,Cluster的边界上看起来并不锁,等一会我会详细讲。

最后切到比较高LOD的时候便是这样,这其实就是我们Mesh的Cluster。也就是说,我们的Cluster跨不同LOD通通存在这个模型上。

本质上,一个模型的表述就是所有不同层级LOD Cluster的组合,而且这些Cluster并不是两个合一个的。

在LOD选择之前,我们先来看Cluster的数据结构,我们是怎么组织Cluster的。

面对一个模型,比如说有上百万个面,我们会根据128或者64个面为一组去生成Cluster,而这个Cluster是利用Mesh LOD 0的原始模型面生成。我们反复用到切分的规则,其实是一个图的切分(graph partition)。

graph partition其实有很多条件,比如我们会要求切分出来128个面的Cluster,保持的面积尽可能接近。因为在LOD切换时,要保证它在屏幕上的投影尽可能均匀。另外一个是为了保证减面质量尽可能好,在锁住边界的时候,减面的自由度还比较大。这时关键的条件是要保证Cluster切分出来的边尽可能少,这是graph partition的条件。

graph partition用了一个第三方库,但因为我们的边界划分条件有些特殊,所以我们对这个库的源码也做了一小部分的修正。这个库叫matrix,应该是现存的最高效、最高质量的graph partition的库。

那整个减面的过程怎么做呢?我们把LOD 0的Mesh拿过来,生成了一组LOD 0的Cluster,那这组Cluster我们会再用graph partition的条件,把一组Cluster,比如64个、32个或者更少的Cluster合并成一个Cluster Group。背后的条件也是一样的,面积尽可能均匀、边界尽可能少。

在减面的时候,其实是在这个Group里进行。我先简单举例,如右图所示(实际划分不止是4个),比如现在有一些Cluster、假设它只有4个面,我把这4个Cluster并成了一个Group,这是LOD 0的。那我要降一级LOD的时候怎么做呢?我先把这些Cluster的边界全解开,把一个Group看成一个大的Cluster,这时我锁住这个Cluster的边界,去对半地减面。之后再以128个面分成一个Cluster时,它Cluster的数量刚好也是减半,就变成了两个Cluster,所以生成了新的Cluster Group里减完面的就是两个Cluster。大家可以看到,这两个Cluster除了Group的外边界跟上面保持一致,内部的边界其实是没有关系的。

生成这个Group的时候,同时还会存下一些额外的信息。比如减面算法可以保证每次减面能获得投到屏幕上的最大误差。即上次减完面后,会记下对原模型误差影响的数值。每个Cluster会记两样东西,一个是记Cluster减到当前这一级时自己的误差,同时还会记下合并完的上一级,即面数更少的那一级。

比如下面这个模型,它的整个Cluster Group会存一个误差。这个误差项来自于上面那四个误差里的最大值,以及下面这两个重新生成面的误差最大值。这样能保证所有的Cluster Group,从上级到下级合并的串一定是降序排列的。也就是说,LOD 0的误差一定小于它所在Group往上一级、所有Cluster所在的那个误差。

这样做的好处在哪里?等会儿再做LOD选择的时候我会讲到,你可以不需要一个总体的结构,够能在GPU上非常方便地、并行地去做选择。也就说,只要知道当前这个Cluster以及预处理时存的误差,并不需要知道额外信息,就可以决定这个Cluster在当前屏幕上是否应该被选择。

这里还列了一些额外的细节,为了之后除LOD选择哪一级Cluster时,更快地做一些分层级的剔除,这里先略过不说。

我们先简单讲一下实际渲染的总流程,因为今天时间的关系,可能集中讲我们比较有创新的LOD部分。我们整个选择和剔除的过程,在GPU上是依赖了这个HZB。这里其实是个先有鸡还是先有蛋的问题,比如我还没有绘制之前做不了HZB,那就没有办法用HZB去做剔除。如果场景里面的Cluster数量非常多,那这个绘制是非常慢的。

提出的解决方案其实蛮多的,我们现在用的方案是用前一帧的HZB,但前一帧的HZB会有很多误判,所以其实是做了两次HZB的Culling。大家可以看到,我们先用前一帧的HZB,对每个Mesh做一个HZB的Culling。做完以后才会去做刚说的,每个Mesh切分成了很多小的Cluster,再做它的Culling。因为刚说了,每一个Mesh其实把LOD0到LOD N的Cluster全都放在里面。也就是说,我对这个Mesh做Culling的时候,假设LOD 0有128个Cluster,那LOD1就是64个,然后32个就加起来,最终这个Mesh就有非常多的Cluster。这些Cluster全加起来以后,在GPU上是对这些Cluster并行做剔除。

剔除的时候有些特殊的地方,等会也会讲到,怎么样去把这些Mesh经过管线画到屏幕上,我们有一些特殊的算法来保证效率。这里我们会做一些算法上的选择,是利用硬件光栅化,还是用软件做光栅化。之后我们就能拥有一个当前帧的、新的可绘制对象,把这个对象深度重新构建一遍HZB。与此同时,再把刚刚不可见、被剔除掉的对象,再针对这个HZD重新做一遍,这样拿到一个比较保守、在屏幕内当前帧可见的绘制对象列表。有了这些以后,我们得到了一个Nanite管线比较精简的Visibility Buffer。最终用这个Buffer通过材质pass在延迟管线里去生成实际用于光照的延时管线的G-Buffer pass。

我们希望未来Nanite可以支持所有的几何表,但目前还做不到。所以在当前阶段,我们需要保留现的普通管线。

所以整个渲染流畅其实是普通管线流程(base pass)先画完,然后处理Nanite对象,用Nanite对象光栅化完生成的Visibility Buffer通过材质pass再生成和并入G-Buffer,接下来的光照流程还是一样的。

这里是比较核心的部分是我们怎么样做LOD的选择。我们一开始其实就是暴力地做了LOD的选择,但这个过程其实是非常慢的,因为我的Cluster 非常多,尤其是比较极端的情况。我们会先做Instance Culling、再做Cluster Culling,那假设场景是一个几亿面的模型,怎么办呢?Instance只有一个,你就只能依赖Cluster Culling,这时候就变成所有Cluster Culling都是并行去做Culling,这肯定是不合适的。

其实前面跳过了一部分,我们对这些Cluster还做了一个类似BVH的加速结构,即把每一个LOD层级算出来的Cluster做一个BVH,来做一个快速的剔除。比如我们拿HZB去做深度的遮挡剔除,这时会根据每一级LOD Cluster的BVH去做树的剔除,获得最终的叶子节点。因为叶子节点里存的才是Cluster Group,我拿到后才会去做Cluster Culling。

而Cluster Culling也有一些比较细的地方,比如说200多个Cluster做选择,怎么能保证它们是一致的,为什么它们的边界刚好能接起来?这就是我们刚刚说到的存下来的额外数据。大家仔细考虑一下,Culling条件和LOD选择条件本质上是一样的,比如说当误差足够小,Cluster是不是应该显示到屏幕上?并不一定。因为上一个Cluster的误差可能也足够小,所以Culling条件是我的误差足够小,上一级的误差不够小,也就是意味着我这级LOD被选中了。

反过来,比如我现在是LOD1、误差足够小,LOD 2的不够小,那他LOD2所在的Cluster Group所有的误差一定都是同时满足不够小,所以LOD2所在的整个Cluster Group都不会被选中。那被选中的时候意味着什么呢?即LOD1所在的整个Cluster Group都被选中。而它的边界和上一级LOD2的边界是保持一致的,所以他上一级边上如果选中的是LOD2,跟他接起来是不会有接缝。

通过这样算法的预先生成和并行计算,我们能保证整个选择逻辑非常高效地在GPU上做并行。这里还有一点,GPU并行的线程数量我们没有办法确定,因为并不知道每个Mesh的LOD有多少级,所以我们开足够多的Persistent线程去做Culling。也就是说,在这个线程里面做了所有刚刚说的这些事情。

光栅化有一些比较特殊的地方,我们Nanite的基本原则是每个像素一个三角形,因为当三角形的精度高于一个像素以后,肉眼基本上已经不可分辨,它的意义就没有那么大了。

我们做了这样的前提假设,但也带来一个问题,现在的图形硬件其实并不是基于这样的设计。硬件的光效管线是基于像素去做处理的,比如以2X2个像素的去做光栅化。因而对于单像素一个三角形的光栅化,效率是非常低的。

所以当Cluster投到屏幕上的面积非常小时,光栅化效率就非常低,就需要用别的方法来做,而我们纯粹用软件的方法做了光栅化。我自己做光栅化的话,没有Depth,所以需要依赖一些wave instruction去做Depth的写入。整个光栅化的过程,最终输出的是一个Visibility Buffer。那Visibility Buffer高30位是深度,低位分别是实位的ID和三角面片的ID,通过一个Draw就可以画完所有opaque对象。

这里我们有很多技巧保证我们的软件光栅化足够高效,可能比硬件更高效。比如在处理亚像素采样的时候,我们假设了什么时候会做软件光栅化。假设我们的面积小于256的时候,保证了三角面片的边界是小于16的,那你就能保证它的浮点,因为亚四像素会乘以边界的长度。比如说乘以16的话,那就是我小数位有四位是在整数位能保留下来,我就可以只用浮点值来模拟一些类似定点数的计算。

所以我在做光栅化计算的时能有非常高效率,不用定点数据算,用硬件的浮点数运算就可以达到这样一些目的。比如边长16的三角面片,就能保证我刚说的四位的小数位数的精度。这时候我后面最大的误差项也就是乘法,乘法的话需要变成八位的小数精度。但八位的小数进度刚好可以在浮点里面保证,所以随便怎么样计算,这个浮点都有我要求的定点最基础的那个精度。

做完光栅化以后,硬件光栅化为了跟软件光栅化合起来,我们还做了一些额外的处理。事实上,我是可以真的做硬件光栅化,但硬件光栅化的内容跟软件光栅化是没有办法合起来、没办法并行,所以变成先选择一部分像素做三角面片、去做硬件光栅化,然后再回来跟软件化东西并行起来。我们发现,这样可能效率更差,完全可以并行做。所以我们的硬件光栅化有一步也很特殊,我没有让他真的去写深度,而是让他跑了我们的软件光栅化代码,把深度写到Visibility Buffer里。

那有了Visibility Buffer以后,接下来就好处理了。我们其实有很多方法,可以从Visibility Buffer到最重要的G-Buffer的数据,选择这个东西的原因有很多。首先可以解耦开材质的复杂度,其次Visibility Buffer精简的程度,也使得前面Mesh Cluster生成到Visibility Buffer的pass能够足够高效,超过硬件的光栅化。我们试过在满足条件的 Cluster上面做软件光栅化,效率可能是硬件的三、四倍。

有了Cluster在以后,我们要生成实际的G-Buffer就要经过材质pass。每个Cluster其实我们还用了一些额外的,比如32位的数据来存储这个材质的信息。这里的32位其实有两种编码,一种比较快速的方式是大部分Mesh都能满足每个三角面片都会有自己对应的材质ID,但事实上你并不太可能一个Cluster的,比如128面里,每个面片都用不一样的材质,这种可能性是很低的。一般来说,一个Mesh我们最多支持64个材质已经足够多了。那64个材质肯定需要六位,如果我直接编码的话,那一个Cluster其实是默认用了三种材质,可能还剩下十四位,这时我每七位存第一种和第二种材质索引到的面片数。

如果超过了怎么办?因为我高七位本来是存第一种材质的三角面片部分,现在我把这部分作为padding,剩下的十九位存buffer的index,这样我有六位来存buffer的长度,大概最多能到127,这个叫slow pass。我们就会间接地去访问一个全局的GPU的一个buffer。这个buffer里面是一张材质的范围表,也就说每个三角面片都能找到自己在材质表的位置。这时结构存的那两个八位的那个三角面的index,即使到最后,大概6位、一共有64种材质的index都可以存下来、找出来。

即便是slow pass,在极端测试时的速度也还是蛮快的。大家可以看到,最终它是怎么做的呢?在Mesh Pass的时候,我们会根据整个Nanite一共用到多少个材质,我就发几个材质的Draw。这些Draw我们做了一些加速,比如说我把整个屏幕切成一些屏幕空间的Tile,对它做InstancedDraw。如果Tile里某一类材质一个都没有,他在Vertex阶段就会被 Culling,这是硬件自己做的事情。等于是一次draw只画对应材质的ID,我会把这个材质pass一遍,生成它对应G-Buffer的数据,也就是说,整个屏幕里面有多少个材质,我就画了多少个Draw。

其实Nanite的渲染部分已经都讲完了,稍微有一点区别的是串流会对我Cluster的选择有一些小的影响。但是渲染部分本质上的计算逻辑,就是刚刚这些东西,等会我们会简单看一下它的效率和数据。

这里也额外讲一点,跟渲染没有关系但也很重要。因为Nanite的数据非常大,我们不可能都放大显存里面,所以它其实类似virtual texture,是用到哪一级才去串流的。所以串流、包括内存和磁盘压缩我也会简单介绍。

因为资源很大,我们只希望整个渲染是一个比较固定的开销,只跟你的屏幕分辨率相关。同时想要内存或者显存的占用也是固定开销,所以它的概念就跟virtual texture样,GPU只请求需要用到这个精度层级的Cluster数据,然后CPU去填充。当然,我们还有一些硬件、或者Graphic API现在支持direct storage,可以GPU直接去请求IO,这个先撇开不说。Geometry的需求笼统的感觉就跟virtual texture本质上是一样的。但是geometry的处理肯定是比virtual texture要特殊和困难不少的。

还记得我们之前说LOD选择的时候,最终结果刚好是在一个有像图上面的很干净的cutter,能保证我的边界是没有接缝的。如果这时我的数据没有进来怎么办?没有进来的时候肯定就不对了。我们其实是保证了内存里面的数据,不可以在Cluster Culling时加入数据信息的判断。所以我们需要runtime paging,即LOD选择的时候什么都不管,还是去选满足刚说的那个条件,比如我自己的error足够小,而parent error不够小,或者我已经是LOD 0、最精细的那一级。那error再大也没办法,没有更细的东西。

题外话,我们以后可能还会在这个基础上做软件的amplification,类似做textlation,永远可以保证一个像素、一个三角面片,即使原始数据没那么高精度也可以做。但现在没有到这一步的情况下,我只能说LOD的选择最差,即使你都不满足条件,到LOD 0也只能选择。

这个时候我为了不影响我刚刚GPU上的选择逻辑,我需要你的叶子节点本身能patch。比如,其实现在加载进来的最低的那一级是LOD 2的,那我在选择的时候就认为你是LOD 0,就是一个叶子节点,这种情况其实就是我们streaming系统runtime去做的这个patch。

我刚说了,因为我们在选择的时候,它一定是一个group同时被选中。所以在streaming的时候,每个单位的力度也是这个Cluster Group。在生成Cluster的时候,我刚刚跳过了很多细节,我的Cluster的存储是按照我streaming的page去存,这个page里是以Cluster Group去存的。

但这个时候会很浪费,因为我一个page,比如4096,肯定不刚好是Cluster Group的整数倍,后面会浪费掉很多。所以在存储的时候,我们又引入了partial,即一部分的Cluster Group的概念。也就是说,有些Cluster Group一半在前一个page上,一半在后一个page上。当我请求这个Cluster 的时候,我会同时把这两个page都要求进来。

那有了这些数据以后,runtime就是streaming系统去做的事情,streaming系统会去patch加载进来的page。装载了这page以后,我会告诉你你Cluster Group哪几级是有的,runtime patch能访问到GPU上叶子节点到哪一级的数据。GPU的选择,就刚刚那个Cluster 和LOD的选择算法完全不变。

我们这样保留了特定的culling层级信息,所以streaming实际geometry信息有很多好处。比如说新的对象刚被看到的那一刻,其实不用一级一级的请求,内存里面会永远会保留Cluster root的信息。所以新的东西被看到时,最初那级始终是在内存里面,然后我马上就能知道实际要请求的是第几级,因为整个BVH表都在。我实际知道拿到的最低的叶子可能是LOD 9的,但我知道要的是LOD 0的,所以会发出LOD 0的请求。串流的系统和它的那个存储基本上就是这个样子。

然后要说到压缩。其实我们做了一些特殊的压缩测试,最终总体的思路是利用硬件、尤其是主机硬件上面的硬件解码压缩。这种通用的压缩算法,一般就是重复的内存段的比较,然后去做这个index和LaaS编码,再把这个字符串做压缩替换。比如哈夫曼编码这种就是最常用的,我用最短的商编码的方式,来做到通用的压缩。

假设我们想利用这个东西,那最好的办法是什么?其实就是Cluster 以后的数据。大家可以想象一下,比如说我的面数就是128,所以我index数量是大量重复的,而且我的position在local space里面的偏移也很小。我可以用非常少的位数去存它,以及我的index buffer是可以非常紧凑的。一旦有跳开的部分,我存一个标记位就可以了,前面都是按顺序往后连的。我一个Cluster的index pattern和别的Cluster index pattern是大量重复的,我只要把这些东西排到一起,通用的压缩算法自动就能有极高的压缩率。

我们还要满足内存随机访问的需求,vertex buffer和index buffer的大小是需要固定。如果不固定,那runtime的性能就会比较差。所以我存储cluster local的值,可以做很大量化的压缩。然后normal可以用比如八面体的这种编码,通过那个球映射到那个八面体,展开到UV上面去编码,也能省掉很多。

硬盘存储就是我刚刚说的LZ压缩,streaming进来以后在GPU上能比较高效的、用我刚说的解码方式来高效地做GPU的decoding。index一百二十八位,其实真的只要一个bit来告诉我这个index是不是冗余的、重复的。每个Cluster的index非常省,我还能把index的全排到一起,vertex全排到一起,最终Mesh在磁盘上的压缩远比大家想象的要乐观。大家看到我们Nanite那些Demo那么大,其实主要贡献全都来自于4K和8K的贴图。

最后是一些性能数据,其实还是比较早的数据。我们去年的Demo在PS5的硬件上做了一些测试,最终输出是4K。但大部分情况下,是靠TSR(Temporal Super Resolution)uptempo到4K的。即使是这样,我们平均也一直是跑在1400P以上的分辨率。在这个分辨率以上,大家可以看到主要就是两个pass,一个是光栅化到visibility这个pass,包括了所有的Culling、LOD的选择,然后到生成光栅化VisBuffer。这里整个东西只有一个Draw,它其实完全没有CPU开销。

接下来就是从Visibility Buffer到G-Buffer,这里CPU是有小部分开销的,正比于当前画面里用到的材质数量。再比如说我们的材质、Instance和bindless的概念引入后,也会进一步的缩减。事实上一个pass画完也行,但pixel shader会比较浪费,因为相邻的那些像素,如果材质类型不一样,GPU的动态分支的利用率还是并不高。我们用了这样的方式,是觉得在渲染线程上面CPU已经很空余了,尤其是当以后所有东西都跑在Nanite上面以后,CPU基本上渲染线程没多少事要干,就runtime graph、pipeline的优化要准备、其他就没有了。

整个Nanite管线,大家可以认为CPU上几乎没有什么开销。GPU上的开销看起来是变高的,但是因为以Cluster为基础能做大量更细力度的Culling,使得实际的pixel的Overdraw远低于我CPU这种Culling的管线,导致能省下更多精确的时间。总体两部分的开销都是2毫秒左右,我们也在做进一步的优化,现在效率可能会更好一点,图右边是这些pass的比较详细的数据。

伴随Nanite管线,开启了一些以前做不到的新功能,比如virtual shadow map。因为时间关系,就简单介绍一下它怎么利用Nanite管线。

首先我们针对每一个灯光,其实都有一张16K X 16K的这样的 shadow map。那通过Nanite也可以,因为画到 shadow map上的光栅化过程,跟屏幕上做Nanite光照过程其实很像,可以自动地去选择一个texel对应一个pixel。就屏幕上需要到一个pixel的精度,我知道这个texel应该在16K的clipmap第几级的精度上,只要在那块上面去画这个shadow就可以,可以去掉非常多不必要的、不同精度层级的绘制开销。

再者,我在Cluster和virtual shadow map的每一小块上的绘制能做大量的cache。比如camera拉近、拉远,其实还是有很多削弱的像素,它的精度要求变化不大,一直落在同一集里面,这些东西是永远不需要重新绘制的。只有发生变化时,我才要在他上一级或者下一级的mip里面去做绘制。

多光源、多级的map里面的绘制的过程,我们可以利用Nanite高效的光栅化。并且因为为了Lumen也做了multiview这样的一个管线集成,所以Nanite是可以同时支持非常多个view同时光栅化。因为我那个persistent的Culling pass是可以非常高效地把GPU全跑满,这时候等于把多个view的Cluster Culling并行地放到里面去做,VSM应该是我们未来打算把整个引擎shadow方案全统一的一个目标。

Nanite目前的情况大家也看到了,接下来的目标并不一定是5.0。未来几年里,我们希望把整个引擎所有几何类型都可以用Nanite来表示,所以会支持更多的材质类型。比如现在MASK材质、透明材质不支持。

我们也希望能支持所有的geometry类型;能更进一步改善磁盘和内存的压缩;也进一步改善runtime的性能。除此之外,VSM也会支持,比如目前我们同时支持所有的光源类型和Nanite和非Nanite Mesh。我们希望未来所有的Mesh类型都能走Nanite管线,在这之前可能先走纯GPU的管线,让VSM可以统一起来。

再然后就是分屏或者VR的渲染,这其实只是一个上层到下层的打通,因为Lumen和VSM已经用到了Nanite多view并行的Culling和光栅化的过程。多view或者VR的渲染本身也是multiview的渲染,Nanite很自然就会有优势。之后,Ray tracing现在我们是用了代理几何体,我们也希望未来能改善,能去tracing实际的Nanite三角面片。-

包括我们放出来第一个版本,其实Nanite上面已经可以存perinstance的data。材质、实力上动态参数的变化这些对象,现在其实它的shader是不一样的,所以你是会分成不同的Draw,未来可以合并成同一个Draw,你可以靠它用同一个材质来做。

最后带World partition proxy、蒙皮网格的,比如你的角色、包括你的植被等重要度比较高的。我们也希望能做一些支持。我的一些不成熟的想法是觉得,本质上Nanite管线是比现有的正常流程GPU skinning要高效的多的,它特别擅长做这个事情。

为什么?现在假设一个角色、夸张点有个500万面,你肯定绘制不动的,因为还要做GPU skinning。你每个顶点都要做大量的计算,那Nanite有什么好处?如果我对skeleton mesh也做了cluster的话,假设这种情况下,我肯定是要用现在的那个skinning cache的机制。也就是说对Nanite而言,你的输入依然是vertex或index buffer。这些cluster怎么来的呢?它其实是通过skinning cache生成出来的。这个生成出来的个loop,也是前一帧Nanite反馈回来的数据。我已经知道了skeleton mesh身上每个部分实际要的LOD层级,那我skinning的计算其实是能省非常多的。

本质上,你要做的东西其实只是我在做BVH Culling的时候,我要有一些error matrix的误差项,我的screen会有分层级的。因为我们骨骼的transform其实是local space转到mesh space去变换我的位置。如果能有一个比较快的估计,能知道每个Cluster的跳点变化大概是什么样。一个保守的方法去做Culling,依然可以比较快速的选择出我保守的LOD是多少,本质上是可以做的。唯一麻烦的部分是,我们为了高效地去做Visibility Buffer的生成,其实不跑vertex shader。

但我现在把vertex shader放到了compute shader,是在你整个Nanite管线之前跑的,所以本质上是可以支持的,唯一带来的问题是内存可能会较高一些。因为比如我有一百个一样的角色,那他的vertex buffer和index buffer本质上是一样的,我是在vertex shader skinning的时候到光栅化,生成出来的东西不一样,才去对顶点做transform。

如果要跑这个管线,我需要在实际Draw你的对象的时候,我在GPU上先用compute shader算一遍,那这一百个对象生成出来肯定是不一样的,我就可能有一百分。这是别的问题,但本质上对现在我们所有常用的几何类型都有很大的改善。

大概就是这个样子,那今天内容主要就讲到这样。

This Article is curated from Source and we only provide the English version of the Story.

No comments

Leave a Reply

Exit mobile version