实时渲染基础
[官方培训]01-实时渲染基础上 | 陈拓 Epic_哔哩哔哩_bilibili
[官方培训]02-实时渲染基础下 | 陈拓 Epic_哔哩哔哩_bilibili
实时渲染介绍
实时渲染本质就是在管理性能的损耗和画面的质量,在不渲染任何物体的时候能达到其最高性能,RTR流程的本质是管理性能损耗和画面质量的平衡。
实时渲染中画面质量、特性、帧率是不可能都很高的,只能达到一个平衡。
在渲染过程中
- 所有环节都必须要尽可能地高效
- 需要严格的流程标准和限制
- 将一部分工作分配到预先计算环节(虚幻相较于其他游戏引擎最大的特点就是预计算贼多)
- 需要多种方案混合工作
CPU VS GPU
- CPU和GPU负责处理渲染的不同部分多数时候是同步的
- 有可能成为对方的瓶颈
- 需要知道工作负荷如何在两者间分配,才能采取对应措施
渲染前的准备
渲染一共三个线程
首先是游戏CPU线程,之后是渲染的CPU Draw线程,最后是GPU线程。下面是一个30FPS的渲染线程概述
第0帧-0ms-游戏线程(CPU)
在开始渲染前,我们需要知道参与渲染的物体在什么位置
游戏线程执行所有逻辑计算和物体的变换,包括下面五个
- 动画
- 模型或物体的位置
- 物理
- AI
- 生成或销毁,隐藏或显示
以及其他任何与物体位置变化相关的逻辑
现在我们已经知道了所有物体的正确的位置
第1帧-33ms-渲染线程(大部分在CPU)
至此,我们已经知道了各个物体处于什么位置
我们还需要知道哪些物体应该被渲染在画面中 →只渲染可见的内容
这部分的工作大部分也是在CPU上计算的,但也有一部分是在GPU上计算
遮挡过程——建立一个可见物体的列表(逐物体,而不是逐三角形)
分为以下4个步骤处理
-
距离剔除——根据物体与相机的距离决定是否剔除(默认未开启)
开启方式一:直接点击希望距离剔除的物体,详情搜索
distance
,设置最小绘制距离和最大绘制距离(ps:虚幻默认的1是1cm,所以如果设置最小绘制距离1000、最大绘制距离5000,那就是摄像机距离这个物体10m~50m之间时物体才会绘制)开启方式二:对场景每一个物体都去设置距离剔除很麻烦,如果我们希望批量设置,那就使用
Cull Distance Volume(距离剔除体积)
。可以设置这个体积的大小,在包围的物体都会受他的影响- 该体积中大小最接近 500 单位的对象会在它们距摄像机 500 单位或更远时被从视野中剔除。
- 该体积中大小最接近 600 单位的对象会在它们距摄像机 600 单位或更远时被从视野中剔除。
- 该体积中大小最接近 10000 单位的对象将永不会被剔除。这可以确保尺寸极大的对象被视为无穷大,这意味着它们距摄像机的距离永不可能远到应将它们剔除的程度。
这个方式对不希望受这个影响的物体可以设置No Culling
-
视锥剔除——根据物体是否在视锥内决定是否剔除
这个是自动开启的,可以用freezeRendering命令冻结渲染画面去看画面是否正常剔除
-
预计算可见性——将可见性结果提前计算好并储存下来
可以使用
Precomputed Visibility Volume(预计算可见性体积)
将场景中的所有物体框起来。之后在
世界场景设置
中开启预计算可见性
。之后打开
显示->可视化->预计算可视性单元
,就可以看到这个可视化的预计算单元了,通过预计算在每个蓝色方块中保存了可视物的信息。但是这里需要注意的是,开启了这个会导致运行时内存的加大,因为需要很多内存去存储每个预计算可视性单元和对应预计算单元内部保存的可视化信息。
-
遮挡剔除——性能消耗最大,在最后才执行
遮挡过程性能提示
- 设置距离剔除
- 大于1万个物体会对性能有较大影响
- 大部分情况下CPU是瓶颈,有时候也可能是GPU
- 遮挡在大型开放世界通常作用比较小
- 所有的物体都会被遮挡
- 大的物体很难被遮挡,因此在GPU渲染上可能需要消耗更多时间
经过上述两个线程,我们已经得到了每个模型的位置和可见性,之后我们需要把这些信息给GPU
第2帧-66ms-GPU
Prepass/Early Z Pass
GPU现在已经知道了需要渲染的物体的列表及其位置信息,但是如果直接渲染,会有一次像素重复绘制,造成了非常大的资源浪费,因此我们需要找出哪些模型应该先被渲染
Early Z
如果我们能在片元阶段之前进行深度测试提前丢弃掉那些不需要绘制到屏幕上的片元,那么就可以减少大量片元计算提升效率。 Early Z就是为了控制GPU在执行像素着色器前会检查该点深度,提前跳过不符合条件的像素。
early-z的解决方式非常简单,就是直接修改传统渲染管线,在光栅化和片元阶段中间,加入一个early-z阶段。在画场景之前先执行一遍着色,将所有可见物体的深度写入深度buffer中,在绘制每一个像素时,我们就会去对比深度buffer的值,只绘制深度buffer值最小的。
Draw Call
Drawcall是指渲染时在特定pass中采用的单一处理过程
通常可以理解为绘制拥有相同属性的一组多边形
不考虑auto instance,左边 Drawcall为5x2=10(背景,地板,三个柱子,并且由于上面的Early Z需要获取深度buffer也需要Draw Call一次所以要 x2 ),右边 Drawcall为 6x2=12(背景,地板,三个柱子,最后一个柱子有两个材质构成)
切换材质会影响性能开销
在GPU渲染时,引擎会根据材质对物体进行排序,相同材质的会在一个批次里绘制,这也是材质实例存在的意义。
DrawCall对性能会有较大的影响
- DrawCall对性能有非常大的影响
- 每次GPU绘制完成后,需要从渲染线程拿新的指令,这里会有比较大性能开销
- DrawCall数量对性能的影响比三角形数量要大许多
通过CMD的stat RHI命令查看运行统计数据
- 2000-3000:合理
- 大于5000:略高
- 大于10000:也许会有性能问题
- 移动端:在几百左右比较合适
这篇帖子详细记录了UE4如何评估画面性能
Draw Call相关性能提示
- Drawcal 数量相比多边形数量对性能的影响更大
- 引擎有一些 Drawcall 的基础开销
- 为了降低 Drawcall,我们可以将模型进行合并,但也有副作用
- 遮挡检测性能更差
- 计算碰撞性能更差
- 占用更多内存
- 一个较为常用的技术称为 Modular Meshes
- 也可以使用 Instancing 降低 Drawcall
- Level Of Detail (LOD) 和HLOD
可以选中多个模型右键合并Actor
去合并模型,对于合并后的模型哪怕只是看到模型的一个小角落,整个模型也都会被放到GPU去渲染。
Renderdoc Plugin
这是一个查看性能消耗的工具。
实时渲染
Shder
Shader是一小段在GPU上执行计算的代码
有许多不同类型的Shader:VertexShader、PixelShader、ComputeShader、Other
Shader是流水线执行运行非常高效
Vertex Shader
Vertex Shader是渲染过程的第一步,主要处理做三件事情
- 将坐标从局部空间->世界空间->投影空间进行转换
- 处理顶点着色
- 应用世界坐标偏移(World Position Offset,WPO)
顶点着色器性能提示
- 动画越复杂性能越慢
- 顶点越多性能越慢
- 高精度的模型最好使用简单的Vertex shaders
- 对远距离的物体禁用顶点动画
光栅化和G-Buffer
提供了变换数据、投影顶点以及必要的着色数据后,下一步是找到所有在这些三角形内部需要渲染的像素点,这个过程我们成为光栅化
光栅化按照Drawcall的顺序逐次调用
(ps:在远处观察一个有 10 万面的模型,即使最终只占了画面中的一个像素,GPU仍然会处理这10万面的数据)
由于硬件设计的原因,在计算一个像素的时候,同时还需要计算其周边2x2的像素(Overshadding)
光栅化 和 Overshading 性能提示
- 多边形越密集,渲染的开销越大
- 从更远处观察物体,多边形的密度会增加
- 因此可以使用LOD的方法或远距离剔除减少这部分的开销
- PixelShader越复杂,0vershading的开销也越大
- 非常细长的三角形也会造成比较严重的0vershading
G-Buffer
我们将物体表面信息储存到一系列的图像中,这些图片称为G-Buffer
G-Buffer可以用于合成各种信息,最终生成渲染输出
GBufferA.rgb = 世界法线,由 PerObjectGBufferData 填充 Alpha 通道。
GBufferB.rgba = 金属色、镜面色、粗糙度、ShadingModellD。
GBufferC.rgb 是基色,由 GBufferAo 填充 alpha 通道。
GBufferD 专用于自定义数据(PF B8G8R8A8)
GBufferE 用于预计算阴影因子。(PF_B8G8R8A8)
GBufferF 在rgb 中输出 WorldTangent,在 alpha 通道中输出各向异性。
可以在主界面点开光照,缓冲显示,选择总览看到G-Buffer的各种信息
可以使用 Custom Depth 作为 Mask 输出
也可以使用 MovieRenderQueue 可以输出其他 G-Buffer,或 Object ID 用于合成
需要现在项目设置中搜索Custom Depth
打开这个选项
纹理
- 纹理在导入时会被压缩,可以大大减少GPU显存占用
- 不同的平台有不同的压缩方式,Windows上通常使用BC算法
- 法向贴图使用了特殊的压缩方式,只保留了RG通道
- Shader中对采样纹理的数量有限制
- 纹理的分辨率主要影响的是内存和带宽,而不是着色
Mipmap
为了减少锯齿以及加快渲染速度,我们需要使用Mipmap
开启后内存占用为原来的1+1/4+1/16+1/32+…=4/3≈1.33倍
为了启动Mipmap我们需要进行如下设置
- 纹理的尺寸需要为2的幂次方
- 长方形贴图长和宽都是是2的幂次方也是可以的
- 边长不是2的幂次方的贴图无法生成Mipmap和进行纹理流送
- UI贴图可以不需要Mipmap
像素着色器和材质
- 像素着色器(Pixel shader)与顶点着色器(Vertex shader)类似
- 也在GPU上执行的程序,可以同时执行大量的简单计算,用于修改像素的颜色
- 对于渲染管线极为重要
- 像素着色器是材质系统的底层实现
- 同时也实现了光照、雾、后期等任何与效果相关的处理
像素着色器是以Shader Language书写的,在Windows平台上使用的HLSL,不同平台使用不同的Shader Language,引擎会自动进行转换。
首先UE一段Shder模板,内部有一段代码是空的
用户在材质编辑器中进行连线,设置材质和贴图之类的
引擎将材质转换成Shder代码内嵌到之前的Shder模板中
之后编译成可以在GPU上运行的代码
对编辑好的材质可以在ShaddingCode中查看代码,可以看HLSL的,也可以看GLSL的
PBR材质
- 材质管线很大一部分都基于PBR也就是基于物理的渲染(PhysicalBased Rendering)
- PBR使用Specular/Metallic/Roughness来描述一种材质的属性
- PBR是一种统一着色模型,可以通过修改参数表现很多不同的材质
- UE中几乎所有的模型都是使用PBR模型进行渲染的
- 可以达到最快的效率
- 可预测性
- 基于G-Buffer的合成工作流限制
材质性能提示
- 每个材质的纹理采样器有最大数量限制(16个),DX11可以使用共亨采样器(最多可以使用128张纹理)
- 纹理尺寸过大会导致短暂的卡顿,但不会降低帧率
- 像素着色器会对性能有非常大的影响,可以优化材质编辑器中的指令数(100~200)
- 屏幕输出的分辨率越大,复杂材质对性能的影响也越大,使用着色器复杂度可以查看着色复杂情况。通过这个显示情况可以快速找出那些物体复杂度比较高
反射
实时渲染中反射是一个非常有挑战的特性
UE中有多种不同的方案
反射捕获
在场景中添加Reflection Capture
,可以是盒体反射捕获,也可以是球体反射捕获。
项目设置中可以修改反射捕获分辨率
来使反射效果更好。、
由于这个是事先计算好的反射贴图,所以在移动过程中反射并不会发生很大的改变,
- 在指定位置捕获一张Cubemap
- 需要预计算
- 在运行时生成反射非常快速
- 反射效果不精确
- 只能捕获一定距离范围内的物体(太远的物体就不会反射了)
平面反射
-
并不常见,也不常常使用,仅限在指定平面上
-
在某些设置下可能会有很大的性能损耗(每帧捕获)
-
适合需要精确反射的表面(例如镜子)
-
需要项目设置中开启global clip
-
在生成反射的过程中,相当于是每一帧在平面出又渲染一次,性能开销很大。
屏幕空间反射
可以开启关闭屏幕空间反射
r.SSR.Quality 0//关闭
r.SSR.Quality 4//开启
- 默认开启的反射系统
- 对任何物体都有影响
- 反射准确
- 输出有噪声,性能损耗较大
- 而且只反射视野范围内可见的物体
Lumen
RT Reflection
反射性能提示
- 如果未经过Cook,反射捕获会在打开关卡时进行,导致加载变慢
- 反射捕获区域如果有很多重看,会导致多次着色从而性能变差
- 反射捕获的分辨率可以在系统设置中调节
- 天空光为整个关卡提供了低成本的反射捕获
- 必要时才使用平面反射的实时捕获和SSR
光照
虚幻光源分类
-
静态光源(Static Light)
是指在运行时不能以任何方式改变或移动的光源。它们仅在光照贴图中进行计算,一旦处理完成后,不会再有进一步的性能影响。可移动对象不能和静态光源进行交互,所以静态光源的用处是非常有限的。
-
可移动光源(Movable Lights)
产生完全动态的光照和阴影,可以改变光源位置、旋转度、颜色、亮度、衰减、半径等属性,几乎光源的任何属性都可以修改。它们产生的光照不会烘焙到光照贴图中,也不会产生间接光照效果。
-
固定光源(Stationary Lights)
保持固定位置不变的光源,但可以在其他方面进行变更,例如亮度和颜色。这是它们与静态光源的主要不同之处,静态光源无法在游戏时以任何方式进行变更。然而,应该注意的是,在运行时对亮度进行修改仅会影响直接光照。间接(反射)光照由于是通过Lightmass 进行预计算的,所以不会改变。
静态光照和阴影
- 与反射一样,光照和阴影在实时计算也很困难
- 部分光照、阴影的计算会在预计算阶段完成,在runtime与实时光照结合
- 虚幻引擎中有数十种不同的光照和阴影方案
静态光照是通过Lightmap做的,Lightmap是一张在构建光照时预计算出来、烘焙了光照和阴影的贴图,在计算光照时与BaseColor相乘。
UE4中,我们使用 Lightmass 工具生成 Lightmap,多张 Lightmap 会合并到 atlas 中,可以逐个 mesh 调整 Lightmap 密度。
Volumetric Lightmap
Lightmass会生成表面光照贴图,用于表现静态对象上的间接光照。但是,动态的对象(例如角色)也需要一种接受间接光照的方法。这种方法就是在构建时将所有点的预计算光照存储在名为 体积光照贴图 的空间中,然后在运行时用于动态对象的间接光照的插值。(输入命令ShowFlag.VisualizeVolumetricLightmap查看 体积光照贴图 )
静态光照质量
- 可以处理辐射和全局光照
- 真实的阴影效果包括软阴影
- 质量取决于Lightmap的分辨率和UV分布
- 由于UV布局的关系,光照还可能显示出接缝
- Lightmap分辨率有上限,巨大的模型可能效果不佳
- 一旦烘焙完成,在运行时静态的光源和物体无法移动
静态光照性能
- 在编辑器下预先计算,并将信息储存在Lightmap中
- 计算非常高效,但占用更多内存
- 需要一定的时间去预计算
- 需要重新构建光照每次修改光照和静态物体,
- 模型需要Lightmap UV,因此需要额外的步骤去处理
GPU Lightmass
GPU LM大大减少了计算、构建和生成复杂场景光照数据所需的时间,其速度可与基于CPU的Lightmass使用Swarm进行分布式构建时的速度相媲美。此外,GPULM提供具有交互性的新工作流,可以实时编辑场景、重新计算和重新构建光照。基于CPU的Lightmass系统无法使用此工作流。
静态光照的性能提示
- 静态光照总是以完全相同的速度渲染
- 无论有多少静态光源,烘焙之后的渲染速度是一样的
- Lightmap分辨率会影响内存,但不影响帧率
- 烘焙速度会受以下几点影响
- Lightmap分辨率
- 模型、光源数量
- 烘焙选项
- 光照影响范围
动态阴影
动态阴影有以下四种生成方式。
- 常规动态阴影
- 级联阴影
- 逐对象阴影
- 距离场阴影
常规动态阴影——非常锋利
以光的位置为视角进行渲染,看得到的就渲染,看不到的就是阴影。
当阴影贴图的分辨率不够就会产生阴影失帧(自遮挡),这个时候需要设置阴影偏移
或者设置封装光源和阴影贴图纹理大小
级联阴影——方向光、不同距离
近的地方使用精细的阴影贴图,远的地方使用粗糙的阴影贴图,优化了阴影效果的同时也保证了渲染效率
逐对象阴影——固定光源(位置固定,颜色、光强可变)
逐对象阴影是针对固定光源的,由于光源对象位置固定,我们可以针对单独的每一个物体渲染阴影贴图,这样既保证了分辨率,也保证了贴图的使用率
距离场阴影
- 距离场阴影——可以生成软阴影,不需要针对模型运行阴影pass
- 从空间中待着色的点出发,沿着光线方向前进
- 由于需要直接光照,光源需是固定或可移动光源
- 只对静态网格体有效,需离线生成Mesh Distance Field
- CSM>DFS>Traditional Shadow
- 运行实时生成Global Distance Field
- Ray Marching
距离场就是一个空间的函数,定义了任意一点到场景中最近一点的距离。
距离场阴影在UE4工程中不会默认开启,需要手动设置,设置-》项目设置-》正在渲染-》生成网格距离场,或者直接搜索 distance,选择生成网格距离场。
Contact Shadow——对于小的物体有较好的细节
Capsule Shadow——用简化的模型来渲染阴影
阴影的性能问题
- 渲染阴影的性能损耗大,通常需要降低渲染质量来补偿
- 动态光照不会对大部分的内容产生辐射或全局光照
- 动态光照不会生成“真正的”软阴影,是通过模拟软阴影的方式实现,比如说上面的距离场阴影,多少范围内就是半影区。
- 动态光照在场景中看起来更“真实”(闪烁等,光线非常锐利)
动态光照的渲染
- 使用像素着色器计算
- 点光源用一个球形模型来渲染,在球投影内像素会进行光照渲染
- 如果是方向光那就是全屏渲染
如果这个光离相机很近,光源的投影就会占到整个画面,但是实际上这个光没有照亮很多物体,所以就需要做光源剔除
常见的剔除方式就是Tile Culling
和Cluster Culling
知道光能照射到的区域(球的投影区域),也知道场景的深度,也知道光的范围和距离,这样就可以算出某个物体会不会被光源照射到。
用法线信息和上面生成的图像混合
之后叠加阴影贴图,阴影是最慢的部分,不过直接对上面的图像乘以对应的阴影系数就行了。
最后将材质和光照进行结合,就得到了最终效果
动态光照性能提示
- 动态光照在延迟渲染中性能损耗相对少,但在前向渲染中损耗可能非常大(光源本身并不是性能损耗的关键,阴影才是)
- 损耗源于像素的着色运算,像素越多性能越慢
- 光源离相机越近,受影响的像素越多,光源渲染的速度也就越慢
- 光源半径需要尽可能小,避免重叠,重叠部分会进行多次的着色运算
Lumen
Lumen是虚幻引擎5全新的全动态全局光照和反射系统,使用了多种光线追踪方法来处理全局光照和反射。
VSM是对应的阴影解决方案
全动态的间接光照管线意味着场景中的材质,光源属性等都可以实时改变
UE4的动态光照基本上都是用直接光照生成的,很难去计算间接光照。UE4的间接光照基本上都是粗略估算,或是基于烘焙的全局光照。
UE5创建的工程默认开启了Lumen,如果是从UE4升级的项目需要进行设置:
项目设置中选择动态全局光照方法
项目设置中选择反射方法
项目设置中开启网格距离场
Lumen支持特性
Color bleeding:Color bleeding使被光照射到的物体表面的颜色会影响周围物体表面的颜色
Soft indirect shadow:Soft indirect shadow(间接软阴影)可以使场景中没有受到直接光照的物体投下阴影,传统方法是使用AO贴图或屏幕空间的AO算法来粗略估算阴影的产生方式,UE5中Lumen完全取代了UE4中的SSAO,消除了实时生成AO贴图的需求,并提供了精确且柔和的阴影(ps:AO: Ambient Occlusion,三维图形渲染中用来表示物体之间相互影响效果的环境光遮蔽贴图,主要用于改善阴影 )
Multi-bounce indirect illumination:Multi-bounce indirect illumination(多次反弹间接照明)通过追踪前一帧的光照来计算当前帧的光照,这意味着光照结果是当前帧和前几帧混合在一起的结果 (ps:r.Lumen.Radiosity 0//关闭间接光照)
Emissive materia
Skylight emissive
Lumen原理说明
处理全局光照最常用的方法就是光线追踪,光线追踪通过追踪光线来模拟光线和物体相交时的效果并生成图像,全局光照需要大量的追踪来生成间接漫反射、软阴影和二次反射等。
Lumen使用了混合的追踪方法,首先它会追踪屏幕上的光线,但只追踪屏幕上的光线无法覆盖全部场景,所以Lumen还大量使用了硬件加速的光线追踪,为了支持老一些的设备,Lumen还通过有向距离场生成简化的场景来加速追踪,因此也提供了光线追踪的软件方案
另外由于直接采样追踪到的三角形会有巨大的消耗,Lumen通过采样表面缓存的方式来加速计算光照结果,通过Lumen Sence我们可以看到Lumen是如何照亮这个场景的,可以在可视化选项中查看Lumen Sence:
Lumen正是使用这些内容来生成全局光照、阴影和反射的,Lumen scene的内容也会被直接用来计算场景的反射,不再需要在场景里放置反射捕获,一旦在项目中启用了Lumen反射,它也会完全取代屏幕空间反射和光线追踪反射
UE4的屏幕空间反射和光线追踪反射会直接忽略粗糙材质,而在Lumen中能够为粗糙的表面计算出更好的反射结果
半透明物体
-
延迟渲染管线难以处理半透明材质
-
半透明渲染在渲染流程的后半段
-
使用前向渲染管线渲染半透明物体
半透明是延迟渲染器的弱项之一,也是实时渲染中最大的性能影响因素之一,不仅仅是虚幻引擎,任何延迟渲染引擎都会遇到这个困难
通常会将半透明渲染放在渲染流程中非常靠后的阶段,在前向渲染中渲染透明效果要简单得多,引擎使用的办法就是在前向渲染中完成半透明物体的渲染,然后将结果和延迟渲染的结果进行合并
前向渲染:
每个几何体从顶点着色器到像素着色器,输出到图元缓冲区后,再进行下一个物体的渲染,即一个一个的渲染,场景有多少物体就渲染多少次
优点
1.前向渲染是从头到尾走完一个着色模型,所以对于着色器的支持更好,可以使用更多种类着色器,和更多功能
2.特别适合半透明物体,每个物体的渲染都是单独的,不会出现透明物体渲染错误的情况
缺点
1.无效渲染太多,如前面的物体挡住了后面的物体,被挡住的部分相机看不见,但是依旧被渲染了出来
2.无法支持过多光源,每个物体都会走一遍着色器,每个着色器都会去进行光源的计算,如100个光源100个着色模型,那么光源就会被计算10000次
延迟渲染:
得到深度信息后,对场景里的所有物体一窝蜂一起进行渲染
优点
1.支持多光源,只渲染可见像素不会无效计算
缺点
1.支持的shader种类少
2.延迟渲染储存的信息大,带宽开销高
3.处理半透明物体比较困难
半透明性能提示
-
渲染半透明材质的对性能影响很大
-
像素被多层半透明材质覆盖,性能损耗很大
-
渲染排序也会增加性能的损耗
后处理效果
虚幻引擎中的后期处理效果 | 虚幻引擎 5.1 文档 | Epic Developer Community (epicgames.com)
后期处理就是在渲染流程的最未端应用的一个视觉特效,顾名思义这就是它为什么被称为后期处理,后期处理很大程度上也依赖于像素着色器,并且也是利用合成来实现,它通过再度使用G-buffer来计算各种效果
Bloom (泛光)
泛光是真实摄像机的光照瑕疵,它通过再现光源和反射性表面周围的辉光来增加所渲染图像的真实感
DOF (Depth of Field,景深)
景深根据焦点前后的距离为场景应用模糊效果。该效果用于根据深度将观看者的注意力吸引到镜头中的特定主体上。它还可以增加一种美感,使渲染的图像看起来更像照片或胶片
Lensflare (镜头光晕)
镜头光晕效果可模拟在查看明亮物体时由于摄像机镜头缺陷导致的光散射
Vignette (暗角)
暗角效果创建一个无边框窗口,使图像朝边缘淡出
Tonemapping (色调映射)
色调映射功能的目的是将广泛的高动态范围(HDR)颜色映射到显示器能够输出的低动态范围(LDR),可以将色调映射的过程想象成一种模拟胶片对光线的反应的方法
Motion Blur (动态模糊)
动态模糊基于对象运动情况使对象模糊。在摄影与电影中(如一系列帧),动态模糊源于捕获图像之前的对象移动,从而产生可见的模糊效果
Exposure (曝光)
曝光类目包含的属性用于选择要使用的曝光方法类型,以及指定场景在给定时间内应该变得多亮或多暗
自定义的后期处理材质需要把材质域设置为后期处理
Ray Tracing
虚幻引擎中的硬件光线追踪 | 虚幻引擎 5.1 文档 | Epic Developer Community (epicgames.com)
Ray Tracing(光线追踪)指追踪从摄像机出发的光线在场景中多次反弹的过程,光线的生成和反弹符合物理规律,使得渲染效果非常逼真
从相机发射一条光线交于场景中某一点,将这个点与场景中的光源连线,如果连线被其他物体阻挡,则这个点处于阴影中,如果与某个光源的连线没有被其他物体阻挡,则这个点是被该光源照亮的
如果一条光线射到一个光滑的表面上,可以根据这个光滑表面的法线计算出它的反射光线,再将反射光线所交的点的颜色值赋给这个点
性能测试(Profiling)
Stat命令
stat unit
查看不同线程执行的耗时
stat game
查看game线程
stat initviews
查看draw线程
stat gpu
查看gpu线程
使用Ctrl+Shift+,快捷键也可以显示GPU查看器
GPU Visualizer
Unreal Visualizer是一个独立的可执行程序,可以帮助开发者来识别瓶颈用于性能优化,还可以用于收集分析和显示引擎发出的数据,还可以轻松添加用户自身的分析数据
可以从里面活获得各个函数运行的时间、运行的次数、当前帧率、各线程使用情况等信息
Unreal Insight
unreal-engine/hardware-ray-tracing-in-unreal-engine?application_version=5.1)
Ray Tracing(光线追踪)指追踪从摄像机出发的光线在场景中多次反弹的过程,光线的生成和反弹符合物理规律,使得渲染效果非常逼真
从相机发射一条光线交于场景中某一点,将这个点与场景中的光源连线,如果连线被其他物体阻挡,则这个点处于阴影中,如果与某个光源的连线没有被其他物体阻挡,则这个点是被该光源照亮的
如果一条光线射到一个光滑的表面上,可以根据这个光滑表面的法线计算出它的反射光线,再将反射光线所交的点的颜色值赋给这个点
性能测试(Profiling)
Stat命令
stat unit
查看不同线程执行的耗时
stat game
查看game线程
stat initviews
查看draw线程
stat gpu
查看gpu线程
使用Ctrl+Shift+,快捷键也可以显示GPU查看器
GPU Visualizer
Unreal Visualizer是一个独立的可执行程序,可以帮助开发者来识别瓶颈用于性能优化,还可以用于收集分析和显示引擎发出的数据,还可以轻松添加用户自身的分析数据
可以从里面活获得各个函数运行的时间、运行的次数、当前帧率、各线程使用情况等信息
[外链图片转存中…(img-3HMDfrzp-1715853252511)]