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，统计唯一顶点数和三角形数，达到顶点去重和优化性能的怎么混淆源码目标。

       最终，数据被写入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时的光栅化源码，对于未启用部分，除可编程光栅化外，与原有固定光栅化版本差异不大，不再详细解释。slwrest源码解析

       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对应的三角形顶点索引，用于三角形设置和光栅化步骤。

       获得唯一顶点索引后，ipad查看源码进行三角形设置。这里代码与之前基本一致，只是写成模板函数，将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在采用凸多边形化来构建寻路图的基础上，通过不同实现细节和优化策略，有效提高了游戏中的路径寻路效率和性能。通过深入理解这两种方法，游戏开发者可以更好地选择和应用合适的寻路库，以满足不同游戏场景的需求。