本系列为Epic官方视频[中文直播]第29期｜解析虚幻引擎开发路线图(上集) | Epic 王祢 马骥 孙丹璐笔记。
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层级）
下一代主机的目的是让开发人员不再关注贴图分辨率、面数、同屏对象数量，只关心画面足够的好，效率和内存靠引擎
最新一代主机的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支持多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
未来不再支持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，就可以了？)
未来默认会将phyx换成Chaos，但是对开发者是透明的。
Chaos的设计的目的是，更可交互性的场景。使得物理、渲染可交换数据。也可以实现网络同步（UE4是状态同步，帧同步的缺点是：运算量大且有dependence。）。
没有定点数，全都是浮点数，由于平台、机型浮点范围精度不同，会略微有误差。
Chaos会有更好的ragdoll、物理动画的节点、物理载具、水、头发、肌肉
可扩展，有API，并非只是简单的profiler，而是一个framework
loading、netword、animation
低门槛、高上限
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使用
目前的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））
缺点：间接的镜面反射、半透明。对小的对象也没精度。
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)