本系列为Epic官方视频[中文直播]第29期|解析虚幻引擎开发路线图(上集) | Epic 王祢 马骥 孙丹璐笔记。

Scalable performance and quality

Epic致力于,全平台使用统一渲染管线、资源(渲染、粒子特效、音效、物理模拟等)。开发者开发一套,引擎针对不同平台、机型进行处理。这种分级处理的能力,被称为Scalable performance and quality

比如Nanite,移动端不直接支持,但是有工具直接将针对Nanite制作的资源进行转换(可以设置参数,满足不同级别的平台和机型)。比如,可以将其转成proxymesh(类似自动生成lod,但由于需要控制绘制对象的数量、DC的数量,所以会使用聚合的方法按照一些规则,生成HLOD的对象)

Nanite的细节是:使用GPU的compute shader来算perpixel的像素密度来渲染三角形,所以在nanite上不需要关心面数和物件数量。但是移动端因为硬件的计算能力和特性的支持度,所以没有支持nanite。所以移动端会模拟这个原理(使用CPU做粗粒度的Nanite,通过LOD控制面数、HLOD控制DC。)。由于CPU没那么细致,所以对工具要求比较高。而且因为增加了LOD资源,所以会增加包体,之后会根据不同硬件,使用不同的参数,来进行平衡。(Patrick:甚至实时计算?)

渲染的自适应还比较简单(texture、mesh、dynamic resolution、material、particle)。gameplay的自适应可以通过significance manager(根据gameplay的关注程度,以不同的频率tick对象逻辑,比如动画(降帧率、lod))

UE4中各个模块都有consolevariable可以调整参数(渲染、植被、后处理、内存、贴图 streaming的池子、GC的频率、LOD层级)

下一代主机的目的是让开发人员不再关注贴图分辨率、面数、同屏对象数量,只关心画面足够的好,效率和内存靠引擎

Loading and Streaming

最新一代主机的IO非常厉害,所以导致loading会bound在序列化上。所以Epic重点优化了这个部分,比如能memcpy的直接copy,之前在序列化的时候还会进行数据类型检查,shipping版本可能也会删掉。

UE在打开场景或者跳转会糊,因为有texture streaming,CPU在衡量使用哪一级mipmap,然而由于texture streaming pool是有大小的,如果有足够空间,则可以很快streaming进来,但是如果空间不够,需要调度策略,有些请求的优先级会比较低,导致一直没加载进来。

音频、贴图这种大块内存是分开存,加载地图的时候是不加载的,而是根据需要,通过VT之类的异步加载,基本不需要CPU参与。而比较麻烦的是物理等加载。想要完全瞬时做异步,只能分摊到更多帧。比如,Chaos物理,每个static物件都有一个对应的物理对象Physicssetup,有physicsshape,加载进入场景,instance的时候,需要把数据实例化注册给physics系统,这个过程很缓慢,如果同时加载很多streaming level,同时注册给物理、渲染、网络、ai(未来)肯定会有卡顿,Epic正在将这个过程分帧,引擎的聚合可以控制一个物件在所有系统注册好之后再激活。 这个过程在CPU端做了很多优化。

通过这两步,使得Streaming变的容易,这样就可以使得常驻内存的必要性降低。

具体多远距离Streaming,用什么策略Streaming,开发团队都可以控制。

texture mipmap streaming、mesh streaming(共享内存)

动画序列、音频(异步加载,不是整段加载、可以预判一帧需要的数据,只要一直满足下一帧的数据需要,就不会卡)

Material比较复杂,因为关联有material - shadermap - material resources - shader source 而且都是间接引用

引擎打开会比较卡主要是因为引擎太复杂,未来部分引擎功能会变成插件。

Landscape

Landscape支持多layer,自定义brush(参数可以是坡度,甚至是光的方向),Epic提供了一个例子:lightmass插件

支持runtime virtual texture(4.26支持手机版,async cs实时压缩成etc2)

4.26版本支持通过一个DC绘制地形,可以更好的控制顶点面数,可以认为整个heightmap就是一个vt。

支持physics based sky and atmosphere,且大气散射可以实时影响skylighting。在iphone6s也只需要1ms,原理是使用低分辨率的lut

Niagara

未来不再支持Cascade,但是有工具可以直接将资源转换。

Niagara分为三部分,输入数据、模拟、渲染

输入数据支持:houdini(csv)、mesh(skinmesh)、texture、sound(均匀分度采样)

模拟(CPU、GPU)可以自己用脚本(CS、hlsl)写,引擎有demo(头发,分了好几个module,比如重力、碰撞等)

Niagara的模拟具备两个主要功能:1.对相邻数据pixel的查询;2.对前一个compute 的结果进行 dependence (类似barrier),通过simulation stage。

渲染呈现(可以多个render,还可以使用模拟中用到的速度等属性进行显示)

Niagara现在在移动端还是只能CPU simulation,因为比如coliision需要depth信息,GPU simulation的话,Niagara是在每一帧的开始,但是移动端depth 默认会被discard掉(避免store),所以是拿不到上一帧深度的。(Patrick:如果不做collision,就可以了?)

Chaos

未来默认会将phyx换成Chaos,但是对开发者是透明的。

Chaos的设计的目的是,更可交互性的场景。使得物理、渲染可交换数据。也可以实现网络同步(UE4是状态同步,帧同步的缺点是:运算量大且有dependence。)。

没有定点数,全都是浮点数,由于平台、机型浮点范围精度不同,会略微有误差。

Chaos会有更好的ragdoll、物理动画的节点、物理载具、水、头发、肌肉

Insight

可扩展,有API,并非只是简单的profiler,而是一个framework

loading、netword、animation

UE5

低门槛、高上限

Nanite

Nanite本质上就是GPU Driven pipeline 。预处理之后就在GPU 做culling、visibility的生成(用compute shader做了光栅化(原本硬件要做的事情,因为硬件在微三角形光栅化的效率是比较低的,因为它们假设一个三角形不会有那么高的密度,比如一个像素一个三角形,之前的假设都是一个三角形占据2*2个像素)。如果三角形面数太多,会带来quad overdraw,导致硬件光栅化器的效率比较差。所以这种情况下就用软件光栅化了。当然也会做平衡,看谁快,用谁做。),生成出的GPU visibility的buffer会转成GBuffer(由于是生成到GBuffer,所以对半透的支持还不太好),和传统管线联合在一起绘制。

Nanite是在导入模型的时候做的预处理,所以对于需要顶点变形的mesh,比如SkeletalMesh,目前Nanite还不支持。

材质和传统管线差不多。

程序化生成的mesh肯定不能做预处理。

Nanite不擅长处理比较薄的,面数比较少的,比如草、叶子。半透处理也有问题。

UE5的demo中,将16B的面数,经过策略处理,可能最终只有30-40M面,和像素数正相关,比如每个像素1个三角形面数。1920*1080才207M面。因为一个像素如果超过一个面数是没有意义的。

这16B的面数并非全部会进内存,而是会有自动streaming,根据需要加载。

对象数量也不敏感。硬件对DC敏感,而Nanite其实也是有上百万个mesh,所以Nanite做了一定的机制,使得实际上并不会调用那么多dc。

面数超过一定数量,会自动生成Nanite的mesh,用Nanite绘制,会用1%的面作为proxy mesh,生成物理对象。少的话就不用,可以自己选择。

对于面数比较低的情况,可以amplification,也就是用computer shader在软件中增加面数

资源送到渲染的时候,在渲染引擎有个proxy的对象,会生成sceneproxy。勾上Nanite后,生成的sceneproxy就是一个Nanite的Sceneproxy。比如Chaos的对象,geometry collection也会生成对应的Nanite的Sceneproxy,生成Nanite的数据,做预先处理。Nanite驱动的mesh,本身还是Nanite的数据,不会影响后面的使用,比如可以提供给Niagara使用

Lumen

目前的GI方案有:lightmap是静态(迭代比较麻烦)的。lightprobe(限制:光源的方向不能变、贡献间接光的主要几何体是不能发生变化的)和PRT(项目组用的多)算是半静态的,因为可以对动态物件产生影响。

Lumen相当于实时间接光。实时间接光肯定是要raytracing,只是Lumen并不强制使用硬件的raytracing加速结构,而是用自己的加速结构进行raytracing。

目标是为了超大规模场景,完全动态,迭代快速,并有比较好的间接光的效果。

Lumen支持color bleeding、indirect shadow间接光阴影(影中影)

infinite diffuse bounces。同时可以cache radiance通过几帧迭代,可以做到无限次漫反射反弹

shadowed sky light天光阴影

indirect specular reflection(并非纯镜面的,因为需要一些简化的几何代理做加速tracing)

使用这些特性,就可以支持动态灯光、天气动态、local light动态(比如手电筒)的间接光照,支持场景变化,比如场景破坏、建造物件遮蔽灯光。

总的来说,预计算的灯迭代也慢,也不支持各种动态。Lumen可以做到实时,并争取效果也比较好

性能:目前Lumen在下一代主机上也只能30fps(Nanite需要4ms,culling2ms,转成GBuffer 2.5ms,Lumen需要8ms(目标2-4ms))

缺点:间接的镜面反射、半透明。对小的对象也没精度。

Other

slate只依赖四个模块: slate stalecore rhi core,为了方便,最多再加上application。可以用slate做工具,比如launch、insight。

照片建模高精度模型:Quixel Megascans素材库 Marketplace和Quixel Bridge可以下载

数字角色:头发、皮肤、面部表情(比如基于ML的deformation)、动画系统(rigid body and cloth——chaos,IK)

大世界:水、路、云彩、streaming、HLOD

资源虚拟化:资源放在云端,只是下载资源描述,使用的时候从云端获取

UE4-UE5:以后不支持32位windows和ios

源码阅读:Gameplaye(actor、component、level、pawn、character、controller、game mode)

AI:使用ECS系统。目前包含:寻路、感知、场景状态查询、行为树系统。新的会将场景、对象更多的和AI统一起来。使得场景更丰富。比如分层级的寻路,场景细节交互。也会分LOD。

倾斜摄影:(无人机拍的,照片建模、扫描的点云)生成高精度纹理和高度图

UObject还会继续支持,但正在探索更细力度的。

UProperty改成FProperty,因为C++反射,导致property的反射描述的属性,也是UObject(1/3是UProperty)。FProperty是struct,省内存,减少GC

Animation也会分LOD。中间级别用 Animation sharing减少动画更新,使用简单状态,和blend状态,没有蒙太奇,分层骨骼混合,物理模拟。最外级使用减面的GPUSkin instance

毛发lod

准备加入motionmatch

UE的正交相机的阴影一直有问题

UE的后期现在全部换成RenderGraph

epic online subsystem(services):用于出海(具有好友、邀请之类等功能)

引擎建模

VRS:手机看硬件厂商。PC上正在做评估(包括软件VRS和硬件VRS)

UE的桌面管线和HDRP大框架类似

OIT目前还没有规划

1080 checkboard、upsample、dlss才能跑8K

UE4和UE5的shading model会有不同,会增加更好的材质效果,更好的PBR

volume cloud(含地面反弹到云层的光),性能只能靠LOD了。

reply回放

虽然并非全部原创,但还是希望转载请注明出处:电子设备中的画家|王烁 于 2020 年 10 月 16 日发表,原文链接(http://geekfaner.com/ue4/blog4_liveshow29.html)