1.mapavatermeshè½å å
2.UE动画优化之URO(UpdateRateOptimizations)源码解析
3.游戏引擎随笔 0x36:UE5.x Nanite 源码解析之可编程光栅化(下)
4.游戏引擎随笔 0x29:UE5 Lumen 源码解析(一)原理篇
5.Unreadable-Mesh内存占用翻倍问题
6.UE4源码剖析——光照贴图(LightMap) 之 由烘焙到渲染流程
mapavatermeshè½å å
æ¯æ¸¸æçå°å¾å è½½æ件ï¼æ¯å¦æ¢¦å¹»è¯ä»è¿æ ·ç游æçå°å¾æ件é½æ¯è¿æ ·æ ¼å¼çï¼å¯ä»¥å é¤ç
å°å¾å é¤æ»ç¥
1ãç´æ¥å¸è½½æ客æ·ç«¯éæ°å®è£ å³å¯
2ãå¨ææºçåºç¨ä¸æ¾å°å平精è±ï¼è¿å ¥åå¨ç®¡çé项ï¼å¨è¿ä¸ªé项ä¸éæ©å é¤æ°æ®åæ¸ ç©ºç¼åï¼è¿æ ·ä¸æ¥å°±å¯ä»¥æ¸ çæå·²ç»ä¸è½½ç游æå°å¾
3ãåªæå®åç¨æ·å¯ä»¥ä½¿ç¨ï¼éè¦å¨æ¸¸æä¸æ¾å°
Android/data/com.android.tencent.tmgp.PUBGmhd/files/UE4Game/ShadowTrackerExtra/ShadowTrackerExtra/Saved/Packs/å®è£ å°å
å¨è¿ä¸ªå°åä¸åå¨äºå¤§éå游ææå ³çæ°æ®å ï¼å ¶ä¸å°å¾å°±æ¯å ¶ä¸ä¹ä¸ï¼æ¾å°å¯¹åºçå°å¾å¹¶å é¤å³å¯ï¼å°å¾çæ ¼å¼ä¸è¬ä¸ºmap_xxxx_æ°åçæ¬å·ãä¸è¿éè¦æ³¨æï¼é»è®¤å°å¾æµ·å²avatermeshä¸è¦å é¤ã
UE动画优化之URO(UpdateRateOptimizations)源码解析
1. URO技术是Unreal Engine动画优化的重要组成部分,它通过智能调整远离摄像头的对象的动画帧率,实现了动画质量和性能的平衡。
2. 在UE中,URO与LOD和VisibilityBasedAnimTick协同工作,核心动画处理主要在USkeletalMeshComponent的抄底老手源码TickComponent和TickPose中执行。
3. FAnimUpdateRateManager负责指挥整个动画更新频率的调整过程,根据对象距离、LOD等因素动态地进行优化,确保每一帧的动画都既流畅又经济。
4. USkinnedMeshComponent通过TickUpdateRate和FAnimUpdateRateManager的配合,实现了URO的效果。开发者可以通过SetTrailMode和SetLookAheadMode等函数,对动画参数进行精细调整,使角色动作既自然又节能。
5. 要掌握URO,关键在于四个策略:命令行魔法、距离阈值决定论、LOD定制策略和插值选项。这些策略可以通过CVarEnableAnimRateOptimization、CVarForceAnimRate、MaxDistanceFactor、LODToFrameSkipMap等参数进行调整。
6. SkeletalMesh组件提供了VisibilityBasedAnimTickOption设置,以实现不同状态下的动画表现一致性。
7. 使用DisplayDebugUpdateRateOptimizations,开发者可以可视化URO的运行情况,帮助精准调整优化策略,提升游戏性能。
8. 通过细致的设置,URO就像一位精密的调音师,为游戏世界赋予了动态且高效的动画生命。
游戏引擎随笔 0x:UE5.x Nanite 源码解析之可编程光栅化(下)
书接上回。
在展开正题之前,先做必要的铺垫,解释纳尼特(Nanite)技术方案中的Vertex Reuse Batch。纳尼特在软光栅路径实现机制中,将每个Cluster对应一组线程执行软光栅,每ThreadGroup有个线程。在光栅化三角形时访问三角形顶点数据,但顶点索引范围可能覆盖整个Cluster的个顶点,因此需要在光栅化前完成Cluster顶点变换。纳尼特将变换后的诺言源码网顶点存储于Local Shared Memory(LDS)中,进行组内线程同步,确保所有顶点变换完成,光栅化计算时直接访问LDS,实现软光栅高性能。
然而,在使用PDO(Masked)等像素可编程光栅化时,纳尼特遇到了性能问题。启用PDO或Mask时,可能需要读取Texture,根据读取的Texel决定像素光栅化深度或是否被Discard。读取纹理需计算uv坐标,而uv又需同时计算重心坐标,增加指令数量,降低寄存器使用效率,影响Active Warps数量,降低延迟隐藏能力,导致整体性能下降。复杂材质指令进一步加剧问题。
此外,当Cluster包含多种材质时,同一Cluster中的三角形被重复光栅化多次,尤其是材质仅覆盖少数三角形时,大量线程闲置,浪费GPU计算资源。
为解决这些问题,纳尼特引入基于GPU SIMT/SIMD的Vertex Reuse Batch技术。技术思路如下:将每个Material对应的三角形再次分为每个为一组的Batch,每Batch对应一组线程,每个ThreadGroup有个线程,正好对应一个GPU Warp。利用Wave指令共享所有线程中的变换后的顶点数据,无需LDS,减少寄存器数量,增加Warp占用率,提升整体性能。
Vertex Reuse Batch技术的启用条件由Shader中的NANITE_VERT_REUSE_BATCH宏控制。
预处理阶段,纳尼特在离线时构建Vertex Reuse Batch,核心逻辑在NaniteEncode.cpp中的BuildVertReuseBatches函数。通过遍历Material Range,统计唯一顶点数和三角形数,达到顶点去重和优化性能的狂风3源码目标。
最终,数据被写入FPackedCluster,根据材质数量选择直接或通过ClusterPageData存储Batch信息。Batch数据的Pack策略确保数据对齐和高效存储。
理解Vertex Reuse Batch后,再来回顾Rasterizer Binning的数据:RasterizerBinData和RasterizerBinHeaders。在启用Vertex Reuse Batch时,这两者包含的是Batch相关数据,Visible Index实际指的是Batch Index,而Triangle Range则对应Batch的三角形数量。
当Cluster不超过3个材质时,直接从FPackedCluster中的VertReuseBatchInfo成员读取每个材质对应的BatchCount。有了BatchCount,即可遍历所有Batch获取对应的三角形数量。在Binning阶段的ExportRasterizerBin函数中,根据启用Vertex Reuse Batch的条件调整BatchCount,表示一个Cluster对应一个Batch。
接下来,遍历所有Batch并将其对应的Cluster Index、Triangle Range依次写入到RasterizerBinData Buffer中。启用Vertex Reuse Batch时,通过DecodeVertReuseBatchInfo函数获取Batch对应的三角形数量。对于不超过3个材质的Cluster,DecodeVertReuseBatchInfo直接从Cluster的VertReuseBatchInfo中Unpack出Batch数据,否则从ClusterPageData中根据Batch Offset读取数据。
在Binning阶段的AllocateRasterizerBinCluster中,还会填充Indirect Argument Buffer,将当前Cluster的Batch Count累加,用于硬件光栅化Indirect Draw的Instance参数以及软件光栅化Indirect Dispatch的ThreadGroup参数。这标志着接下来的光栅化Pass中,每个Instance和ThreadGroup对应一个Batch,以Batch为光栅化基本单位。
终于来到了正题:光栅化。本文主要解析启用Vertex Reuse Batch时的软光栅源码,硬件光栅化与之差异不大,此处略过。此外,本文重点解析启用Vertex Reuse Batch时的光栅化源码,对于未启用部分,除可编程光栅化外,与原有固定光栅化版本差异不大,不再详细解释。真爱法宝源码
CPU端针对硬/软光栅路径的Pass,分别遍历所有Raster Bin进行Indirect Draw/Dispatch。由于Binning阶段GPU中已准备好Draw/Dispatch参数,因此在Indirect Draw/Dispatch时只需设置每个Raster Bin对应的Argument Offset即可。
由于可编程光栅化与材质耦合,导致每个Raster Bin对应的Shader不同,因此每个Raster Bin都需要设置各自的PSO。对于不使用可编程光栅化的Nanite Cluster,即固定光栅化,为不降低原有性能,在Shader中通过两个宏隔绝可编程和固定光栅化的执行路径。
此外,Shader中还包括NANITE_VERT_REUSE_BATCH宏,实现软/硬光栅路径、Compute Pipeline、Graphics Pipeline、Mesh Shader、Primitive Shader与材质结合生成对应的Permutation。这部分代码冗长繁琐,不再详细列出讲解,建议自行阅读源码。
GPU端软光栅入口函数依旧是MicropolyRasterize,线程组数量则根据是否启用Vertex Reuse Batch决定。
首先判断是否使用Rasterizer Binning渲染标记,启用时根据VisibleIndex从Binning阶段生成的RasterizerBinHeaders和RasterizerBinData Buffer中获取对应的Cluster Index和光栅化三角形的起始范围。当启用Vertex Reuse Batch,这个范围是Batch而非Cluster对应的范围。
在软光栅中,每线程计算任务分为三步。第一步利用Wave指令共享所有线程中的Vertex Attribute,线程数设置为Warp的Size,目前为,每个Lane变换一个顶点,最多变换个顶点。由于三角形往往共用顶点,直接根据LaneID访问顶点可能重复,为确保每个Warp中的每个Lane处理唯一的顶点,需要去重并返回当前Lane需要处理的唯一顶点索引,通过DeduplicateVertIndexes函数实现。同时返回当前Lane对应的三角形顶点索引,用于三角形设置和光栅化步骤。
获得唯一顶点索引后,觅搭 源码进行三角形设置。这里代码与之前基本一致,只是写成模板函数,将Sub Pixel放大倍数SubpixelSamples和是否背面剔除bBackFaceCull作为模板参数,通过使用HLSL 语法实现。
最后是光栅化三角形写入像素。在Virtual Shadow Map等支持Nanite的场景下,定义模板结构TNaniteWritePixel来实现不同应用环境下Nanite光栅化Pipeline的细微差异。
在ENABLE_EARLY_Z_TEST宏定义时,调用EarlyDepthTest函数提前剔除像素,减少后续重心坐标计算开销。当启用NANITE_PIXEL_PROGRAMMABLE宏时,可以使用此机制提前剔除像素。
最后重点解析前面提到的DeduplicateVertIndexes函数。
DeduplicateVertIndexes函数给每个Lane返回唯一的顶点索引,同时给当前Lane分配三角形顶点索引以及去重后的顶点数量。
首先通过DecodeTriangleIndices获取Cluster Local的三角形顶点索引,启用Cluster约束时获取所有Lane中最小的顶点索引,即顶点基索引。将当前三角形顶点索引(Cluster Local)减去顶点基索引,得到相对顶点基索引的局部顶点索引。
接下来生成顶点标志位集合。遍历三角形三个顶点,将局部顶点索引按顺序设置到对应位,表示哪些顶点已被使用。每个标志位是顶点的索引,并在已使用的顶点位置处设置为1。使用uint2数据类型,最多表示个顶点位。
考虑Cluster最多有个顶点,为何使用位uint2来保存Vertex Mask而非位?这是由于Nanite在Build时启用了约束机制(宏NANITE_USE_CONSTRAINED_CLUSTERS),该机制保证了Cluster中的三角形顶点索引与当前最大值之差必然小于(宏CONSTRAINED_CLUSTER_CACHE_SIZE),因此,生成的Triangle Batch第一个索引与当前最大值之差将不小于,并且每个Batch最多有个唯一顶点,顶点索引差的最大值为,仅需2个位数据即可。约束机制确保使用更少数据和计算。
将所有Lane所标记三个顶点的Vertex Mask进行位合并,得到当前Wave所有顶点位掩码。通过FindNthSetBit函数找出当前Lane对应的Mask索引,加上顶点基索引得到当前Lane对应的Cluster Local顶点索引。
接下来获取当前Lane对应的三角形的Wave Local的三个顶点索引,用于后续通过Wave指令访问其他Lane中已经计算完成的顶点属性。通过MaskedBitCount函数根据Vertex Mask以及前面局部顶点索引通过前缀求和得到当前Lane对应的Vertex Wave Local Index。
最后统计Vertex Mask所有位,返回总计有效的顶点数量。
注意FindNthSetBit函数,实现Lane与顶点局部索引(减去顶点基索引)的映射,返回当前Lane对应的Vertex Mask中被设置为1的位索引。如果某位为0,则返回下一个位为1的索引。如果Mask中全部位都设置为1,则实际返回为Lane索引。通过二分法逐渐缩小寻找索引范围,不断更新所在位置,最后返回找到的位置索引。
最后,出于验证目的进行了Vertex Reuse Batch的性能测试。在材质包含WPO、PDO或Mask时关闭Vertex Reuse Batch功能,与开启功能做对比。测试场景为由每颗万个三角形的树木组成的森林,使用Nsight Graphics进行Profiling,得到GPU统计数据如下:
启用Vertex Reuse Batch后,软光栅总计耗时减少了1.毫秒。SM Warp总占用率有一定提升。SM内部工作量分布更加均匀,SM Launch的总Warp数量提升了一倍。长短板Stall略有增加,但由于完全消除了由于LDS同步导致的Barrier Stall,总体性能还是有很大幅度的提升。
至此,Nanite可编程光栅化源码解析讲解完毕。回顾整个解析过程,可以发现UE5团队并未使用什么高深的黑科技,而是依靠引擎开发者强悍的工程实现能力完成的,尤其是在充分利用GPU SIMT/SIMD机制榨干机能的同时,保证了功能与极限性能的实现。这种能力和精神,都很值得我们学习。
游戏引擎随笔 0x:UE5 Lumen 源码解析(一)原理篇
Lumen 原理与核心组件介绍
实时全局光照(RTGI)一直是图形渲染领域的追求目标。UE5的Lumen是基于Epic的新一代游戏引擎开发的RTGI解决方案,它结合了SDF、Voxel Lighting、Radiosity等技术,并且支持软件和硬件光线追踪的混合使用。Lumen的复杂性在于其庞大的源码库,包含个Pass和众多文件,涉及RTGI技术的集成和优化。核心理念
Lumen聚焦于解决Indirect Lighting中的漫反射,利用粗粒度场景描述和非物理精确计算来达到实时性能。核心数学原理是渲染方程,通过Monte Carlo积分简化计算。加速结构与SDF Ray Marching
Ray Tracing依赖加速结构,但GPU并行计算有限。Lumen使用SDF的Ray Marching技术,特别是Mesh DF(距离场)和Global DF(全局距离场)来实现无需硬件支持的SWRT,分别用于短距离和长距离的光线追踪。Surface Cache与Radiance Cache
Surface Cache存储物体表面的材质属性,通过Cube Map简化获取。Radiance Cache则整合了直接光照信息,支持无限反弹全局光照。Lumen Scene与Screen Space Probe
Lumen的低精度粗粒度场景由SDF(Mesh)和Surface Cache(Material)构建,Screen Space Probe用于自适应放置并生成光照信息。Voxel Lighting与Radiosity Indirect Lighting
Voxel Lighting体素化相机周围空间,存储光照信息,通过Radiosity生成间接光照,弥补了Lumen单次Bounce的限制。World Space Probe与降噪
Word Space Probe提供更稳定的远距离光照,通过Clipmap优化性能。降噪策略包括Temporal\Spatial Filter和Importance Sampling。总结与流程
Lumen的Indirect Diffuse流程涉及多个步骤,包括Lumen Scene更新、Lighting以及Final Gather,其GPU端流程图展示了核心数据和操作。Unreadable-Mesh内存占用翻倍问题
1)Unreadable-Mesh内存占用翻倍问题
部分Mesh在未开启Readable的情况下也会占用CPU部分的内存开销。经过对比发现是m_KeepVertices与m_keepIndices参数的差异所导致。网络上部分源码揭示该参数影响内存释放。尝试修改文件或使用SerializedObject方式修改均无法保存,Unity内部会自行修正。需要了解导致内存保留CPU端所有数据的具体Mesh数据情况及预防措施。
2)在TMP中计算书名号《》高度的问题
输入文字中包含书名号《》时,使用ContentSizeFitter计算的高度出现错误,导致文字没有正确换行。对比默认的Text组件,问题得以解决。希望有经验的朋友能提供在TMP中正确计算书名号高度的方法。
3)Mipmap如何限定层级
如何在项目中仅使用特定层级的Mipmap,比如从Mipmap0到Mipmap2,而省略Mipmap3到Mipmap。寻求有经验的朋友分享解决方案。
4)FMOD设置中关于Virtual Channel Count&Real Channel Count的参数疑问
在FMOD的设置中,Virtual Channel Count和Real Channel Count这两个参数的合理设置值是开发者经常面临的疑问。了解如何根据项目需求调整这两个值以平衡CPU负担,希望有经验的开发者提供指导。
UE4源码剖析——光照贴图(LightMap) 之 由烘焙到渲染流程
在离线编辑器阶段,通过构建(Build)按钮启动光照烘焙流程,UE4引擎在构建场景光照、反射球信息、预计算静态网格可见性、构建导航网格、构建HLOD、构建流式贴图等,仅关注光照相关只构建光照(Build Lighting Only)阶段,Lightmass系统负责计算光照,Swarm分布式工具加速并分担计算任务。
Swarm初始化并启动烘焙流程,Startup阶段计算光照构建的关卡与灯光信息,统计静态几何体数据并初始化Swarm,Swarm分为协调与代理程序,负责数据导出与任务分配。AmortizedExport阶段进行分摊式数据导出,SwarmKickoff阶段Swarm全面启动,AsynchronousBuilding阶段消费者程序执行任务,完成光照信息计算。AutoApplyingImport阶段根据配置决定是否自动导入烘焙结果,WaitingForImport与ImportRequested阶段等待导入烘焙数据,Import阶段完成数据导入,Finished阶段地图构建完成。
光照贴图合并大图过程,为每个静态几何体独立生成光照贴图后,UE4将多张贴图尽可能合并到一张大贴图中,以优化IO加载与渲染性能。合并算法简单,通过排序、读取最大尺寸限制与重新摆放光照贴图完成。
贴图像素设置与Mipmap生成,合并后的光照贴图设置像素值,为每种类型的光照贴图创建,最终将数据以真实形式存储。贴图包含SkyOcclusionTexture、AOMaterialMaskTexture、ShadowMapTexture与低分辨率系数贴图。
贴图渲染资源合并中,判断不同几何体使用的贴图集合是否一致,优化判断效率。创建FLightmapClusterResourceInput类代表贴图集合,并统计所有集合用于判断几何体是否使用相同贴图集合。
运行时光照贴图传递到Shader流程包括UE4几何体渲染架构窥探、光照信息存储、赋值LCI与生成渲染批次、绑定Shader。FLODInfo类存储光照信息,FMeshBatchElement中设置LCI字段,FBasePassMeshProcessor绑定贴图集合到Shader。在Shader代码中访问LightmapResourceCluster变量访问贴图集合中的光照贴图。
UE4通过Swarm分布式框架、Lightmass光照系统与优化的贴图合并与传递流程,实现了高效、实时的光照计算与渲染。
以上内容详细介绍了UE4引擎中光照贴图从烘焙到渲染的完整流程,包括分布式工具、数据合并、贴图存储与Shader访问,实现了高性能的光照计算与渲染。
Recast Navigation 源码剖析 - Meadow Map论文解析与实验
本文深入解析了Meadow Map论文及其在Recast Navigation中的应用。Recast Navigation是一款常见的游戏开发寻路库,源于芬兰开发者Mikko Mononen的初始工作。Meadow Map方法,由Ronald C. Arkin于年提出,为现代Navmesh系统奠定了基础,特别强调长时间存储地图的有效策略。
Meadow Map通过凸多边形化动机,提出了一种优化存储和访问3D地图数据的方法。相较于传统的基于网格的寻路方法,Meadow Map采用凸多边形化来减少节点数量,从而提高性能效率,特别是针对平坦区域。凸多边形化的核心在于利用凸多边形内部任意两点直接相连的特性,构建寻路图。
Recast Navigation系统使用凸多边形化来处理3D场景,通过算法自动将3D场景转换为2.5D形式,以便于寻路。与Meadow Map类似,Recast也采用了基于凸多边形边缘中点作为寻路节点的策略,构建寻路图以供A*算法使用。这种方法简化了搜索空间,提高了寻路效率。
在实现Meadow Map时,需解决多边形分解成多个凸多边形的问题。此过程通过不断消除多边形中的非凸角,递归生成凸多边形,实现多边形化。同时,处理多边形内部的障碍物(holes)时,需找到与可见顶点相连的内部对角线,将空洞并入多边形内部。
路径改进方面,Recast Navigation采用String Pulling方法,旨在优化路径,避免路径的抖动和非最优行为。这一策略在实际应用中提升了路径质量,使得寻路过程更为流畅。
总之,Meadow Map和Recast Navigation在采用凸多边形化来构建寻路图的基础上,通过不同实现细节和优化策略,有效提高了游戏中的路径寻路效率和性能。通过深入理解这两种方法,游戏开发者可以更好地选择和应用合适的寻路库,以满足不同游戏场景的需求。