1.UE5引擎Paper2D插件上的源码用PaperFlipbookComponent.h文件源码解读分析
2.UE5实践1.配置环境以及简单的shadingmodel添加
3.UE5在iOS上的DataDrivenPlatformInfo.ini文件源码解读分析
4.UE5在Windows平台上的WindowsEngine.ini文件源码解读分析
5.UE5 ModelingMode & GeometryScript源码学习（一）
6.游戏引擎随笔 0x36：UE5.x Nanite 源码解析之可编程光栅化（下）
UE5引擎Paper2D插件上的PaperFlipbookComponent.h文件源码解读分析
深入探讨Unreal Engine 5（UE5）Paper2D插件中的UPaperFlipbookComponent.h文件，让我们从整体框架开始。控制Paper2D插件是源码用UE5专为2D游戏开发设计的，内置了一系列构建2D平面动画与图形的控制工具。在这些工具中，源码用UPaperFlipbookComponent扮演着关键角色，控制c 编译nodejs源码它负责管理和播放序列帧动画。源码用
文件中的控制`private`和`public`关键字，明确划分了类的源码用成员访问权限。`private`区域内的控制成员方法仅供类内使用，而`public`区域则可供任何访问类实例的源码用代码使用。此外，控制`virtual`关键字标识了可在派生类中重写的源码用方法，`override`关键字则表明该方法重写了基类中的控制虚拟方法，这是源码用实现多态的关键。
UPaperFlipbookComponent是UE5中的一个重要组件，它允许开发者轻松添加2D动画至游戏对象。动画通过一系列帧构成，这些帧按照特定顺序和速度播放，从而创造出动画效果。
从功能和属性的推测来看，UPaperFlipbookComponent的核心功能可能包括动画播放逻辑、帧管理、速度控制以及循环播放设置。在实际应用中，开发者可能会遇到如何优化动画性能、处理复杂动画序列以及与其他游戏对象交互等问题。
尽管无法直接访问源代码的具体实现，通过理解类的结构和功能，我们可以推测UPaperFlipbookComponent在动画处理上的设计思路和潜在的实现细节。作为Paper2D插件的核心组件，它对2D游戏动画播放的支持至关重要。
UE5实践1.配置环境以及简单的shadingmodel添加
环境配置：使用Windows 系统，Unreal引擎版本5.0.2，Rider版本.1.1，Epic Games。首先，需要关联GitHub账户以访问私有引擎源码，通过github.com/EpicGames/Unreal获取源码。
构建项目：解压源码后，执行Setup命令，等待下载引擎文件，大约需时G左右，注意预留足够的磁盘空间。接着运行GenerateProjectFiles生成项目文件，此时可以看到.sln文件，可使用Rider或Visual Studio打开并构建项目。构建过程中可能会耗时较长，例如在晚上:开始构建，次日3:左右完成，最终成功启动引擎。
解决BUG：启动引擎后可能会遇到模块加载问题，这通常与使用Rider导致的插件加载问题有关。解决方法是在代码中将相关插件的EnabledByDefault属性设置为false即可。
自定义着色模型：在配置环境后，可以参考相关文章进行自定义着色模型的添加。具体步骤包括修改C++文件中的c serial 源码EngineTypes.h、MaterialShader.cpp、Material.cpp、MaterialShared.cpp等文件，以实现着色模型的添加。同时，需要修改HLSLMaterialTranslator.cpp、ShaderMaterial.h、ShaderMaterialDerivedHelpers.cpp、ShaderGenerationUtil.cpp等文件，以完成Gbuffer的写入。此外，调整PixelInspectorResult.h、PixelInspectorResult.cpp、PixelInspectorDetailsCustomization.cpp等文件，以优化序列化显示。
修改着色模型部分：通过修改ShadingCommon.ush、Definitions.usf、BasePassCommon.ush、DeferredShadingCommon.ush、ShadingModelsMaterial.ush等文件，实现自定义着色模型的添加。同时，需要调整ToonShadingCommon.ush、ShadingModels.ush、BasePassPixelShader.usf文件，以支持多光源的自定义着色模型。
最终效果：通过上述步骤，可以实现自定义着色模型的添加，支持多光源渲染，并得到支持多光源的CustomShadingModel效果。此外，还存在一种无需修改引擎代码的方法实现自定义着色模型。
UE5在iOS上的DataDrivenPlatformInfo.ini文件源码解读分析
Unreal Engine 5（UE5）提供了强大的数据驱动平台信息体系，开发者通过配置文件能对不同平台实现精准设置。此配置确保游戏在多平台下展现一致表现与体验。本文深入剖析了DataDrivenPlatformInfo.ini文件在UE5项目中对iOS平台的参数设定。平台基础信息涵盖：
常规设置 图标路径与教程路径 编译器与组平台设置 预览平台设置涉及： IOSMetal与IOSMetalSM5 预览特性 着色器平台设置包含： ShaderPlatform METAL ShaderPlatform METAL_MRT 通过精细配置DataDrivenPlatformInfo.ini，UE5开发者可针对iOS设备特性优化游戏。每一项设置旨在最大化利用硬件，同时确保跨平台一致性。随着UE5与iOS硬件发展，理解与应用这些配置项对于游戏成功至关重要。UE5在Windows平台上的WindowsEngine.ini文件源码解读分析
引言： 在深入探究UE5的底层结构时，WindowsEngine.ini文件的作用不可小觐。
它是Unreal Engine 5中对Windows平台特有的设置和优化的集合体，从音频处理到贴图流，再到系统级的性能配置，每一行代码都蕴含着引擎开发者对于性能和用户体验的考量。
本文将详尽地解析WindowsEngine.ini文件的每个部分，揭示其背后的逻辑和设计哲学。
每一条注释都紧跟在对应的设置项后面，解释该设置项的功能和目的。这些注释对于理解和维护配置文件至关重要，尤其是在涉及多人协作或长期项目维护时。
1、[Audio] 部分
2、新引流源码[TextureStreaming] 部分
3、[SystemSettings] 部分
4、[PlatformCrypto] 部分
结语： WindowsEngine.ini文件不仅仅是一系列配置项的罗列，更是UE5为Windows平台精心调优的证明。
通过这些设置，开发者能够为玩家提供更佳的视听体验和更流畅的游戏性能。
这份文件的每一项配置都是引擎优化和平台兼容性工作的见证，展现了Unreal Engine在跨平台支持方面的卓越能力。
UE5 ModelingMode & GeometryScript源码学习（一）
前言
ModelingMode是虚幻引擎5.0后的新增功能，用于直接在引擎中进行3D建模，无需外接工具，实现快速原型设计和特定需求的模型创建。GeometryScript是用于通过编程方式创建和操控3D几何体的系统，支持蓝图或Python脚本，提供灵活控制能力。
本文主要围绕ModelingMode与GeometryScript源码学习展开，涵盖DMC简介、查找感兴趣功能源码、动态网格到静态网格的代码介绍。
起因
在虚幻4中，通过RuntimeMeshComponent或ProceduralMeshComponent组件实现简单模型的程序化生成。动态网格组件（DynamicMeshComponent）在UE5中提供了额外功能，如三角面级别处理、转换为StaticMesh/Volume、烘焙贴图和编辑UV等。
将动态网格对象转换为静态网格对象时，发现官方文档对DMC与PMC对比信息不直接涉及此转换。通过搜索发现，DynamicMesh对象转换为StaticMesh对象的代码位于Source/Runtime/MeshConversion目录下的UE::Modeling::CreateMeshObject函数中。
在UE::Modeling::CreateMeshObject函数内，使用UEditorModelingObjectsCreationAPI对象进行动态网格到静态网格的转换，通过HasMoveVariants()函数接受右值引用参数。UEditorModelingObjectsCreationAPI::CreateMeshObject函数进一步处理转换参数，UE::Modeling::CreateStaticMeshAsset函数负责创建完整的静态网格资产。
总结转换流程，DynamicMesh对象首先收集世界、变换、资产名称和材质信息，通过FCreateMeshObjectParams对象传递给UE::Modeling::CreateMeshObject函数，该函数调用UE::Modeling::CreateStaticMeshAsset函数创建静态网格资产。
转换为静态网格后，程序创建了一个静态网格Actor和组件。此过程涉及静态网格属性设置，最终返回FCreateMeshObjectResult对象表示转换成功。
转换静态网格为Volume、动态网格同样在相关函数中实现。
在Modeling Mode中添加基础形状涉及UInteractiveToolManager::DeactivateToolInternal函数，当接受基础形状时，调用UAddPrimitiveTool::GenerateAsset函数，根据面板选择的输出类型创建模型。
最后，UAddPrimitiveTool::Setup函数创建PreviewMesh对象，UAddPrimitiveTool::UpdatePreviewMesh()函数中通过UAddPrimitiveTool::GenerateMesh生成网格数据填充FDynamicMesh3对象，进而更新到PreviewMesh中。
文章总结了Modeling Mode与GeometryScript源码的学习路径，从动态网格到静态网格的科技主页源码转换、基础形状添加到输出类型对应函数，提供了一条完整的流程概述。
游戏引擎随笔 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时的光栅化源码，对于未启用部分，除可编程光栅化外，与原有固定光栅化版本差异不大，不再详细解释。
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 Nanite 源码解析之渲染篇：BVH 与 Cluster 的 Culling
在UE5 Nanite的渲染深度中，一个关键组件是其独特的剔除策略，特别是通过高效的BVH（Bounded Volume Hierarchy）和Cluster Culling技术。Nanite的目标在于智能地控制GPU资源，避免不必要的三角形绘制，确保每一点计算都被最大化利用。
首先，Nanite的渲染流程中，异步数据传输和GPU初始化完成后，进入CullRasterize阶段，其中的PersistentCulling pass至关重要。它分为两个步骤： BVH Node Culling 和 Cluster Culling，每个阶段都利用多线程并行处理，实现了GPU性能的极致发挥。
在Node Culling中，每个线程处理8个节点，通过Packed Node数据结构，确保数据的一致性和同步性。每组个线程间通过MPMC Job Queue协同工作，保证了负载均衡，避免了GPU资源的浪费。GroupNodeMask和NodeReadyMask等优化策略，确保了节点处理的高效性和准确性。
核心部分是TGS GroupNodeData，它接收并处理来自候选节点的Packed Node，进行实例数据、动态数据和BVH节点数据的整合。通过Frustum Culling，仅保留可见的节点，非叶节点的计数更新和候选Cluster的生成，都在这个过程中完成。
叶节点的Cluster Culling更为精细，通过计算Screen Rect，判断是否适合渲染。当遇到硬件光栅化需求时，Nanite会利用上一帧的LocalToClip矩阵进行HZB遮挡剔除，确保每个Cluster的可见性和正确性。
在硬件光栅化中，VisibleClusterOffset的计算和Cluster的有序写入，体现了UE5团队对性能的精心调教。而软光栅化则采取相反的存储策略，确保了渲染的高效执行。
尽管Nanite在百万面模型处理上展现出惊人的0.5ms速度，但它并非无懈可击，如不支持Forward Rendering。然而，随着UE5技术的不断迭代，Nanite的潜力和优化空间将继续扩展，推动着游戏开发的创新边界。
总之，UE5 Nanite的渲染篇是技术与艺术的完美融合，通过深度剖析其渲染流程，我们不仅能领略到高效剔除策略的魅力，更能感受到Unreal团队在性能优化上的匠心独运。深入源码，解锁游戏引擎的内在魔力，让我们一起期待Nanite在未来的更多可能。
UE5 源码结构解读——Unreal Engine 5文件系统详细导览
欢迎加入“虚幻之核：UE5源码全解”，探索Unreal Engine 5（UE5）的深层秘密。作为一款行业领先的游戏引擎，UE5不仅集成了Nanite虚拟化微多边形几何系统和Lumen动态全局光照等革新技术，还提供了一个深度解析专栏，帮助开发者、图形程序员和技术艺术家从源码级别理解其核心构造。
UE5不仅仅是一个游戏引擎，它代表了虚幻技术的巅峰，赋予了创造创新视觉和互动体验的无限可能。我们的专栏将深入探讨这些技术背后的源代码，揭示它们的工作原理，并展示如何在您的项目中实现和优化它们。
每一期专栏都是一个精心设计的知识模块，旨在让读者不仅掌握UE5的功能，更从源码层面掌握其实现细节。从资产流水线到渲染过程，从物理模拟到AI行为树，无论您希望优化当前项目性能，还是探索UE5隐藏的功能和技巧，这里都将为您提供宝贵的资源。
“虚幻之核：UE5源码全解”是您探索虚幻引擎深层秘密的起点，让我们用源码解答虚幻世界中的奥秘。
游戏引擎随笔 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端流程图展示了核心数据和操作。UE5在编辑器本地化上的Editor.ini文件源码解读分析
在UE5的开发流程中，本地化为游戏触及全球玩家提供了关键支持。Editor.ini文件作为本地化流程的核心组件，负责定义从源代码到最终本地化资源的完整路径。注释详尽，为开发者提供深入理解，便于管理并控制本地化工作。
一、通用设置在[CommonSettings]部分，定义了本地化流程的基础，包括支持的文化和本地化文件存放位置。此配置确保流程覆盖所需文化，精准控制文件布局。
文本收集流程分为多个步骤，从源码到编辑器资产，再到项目元数据，全面覆盖所需文本。
（1）从源码收集步骤使用GatherTextFromSource命令，精准设定搜索路径、排除规则和文件类型，确保收集相关文件。
（2）从资产收集步骤聚焦于编辑器内的UMAP和UASSET文件，提取编辑器内容，包括地图和其他资源，确保全面覆盖。
（3）从元数据收集步骤专注于项目设置和配置，预加载模块和路径设定实现精细控制，确保内容范围精准。
本地化文件生成流程包括清单、档案、导入PO文件、生成本地化资源、导出到PO文件和生成报告等步骤，形成完整的工作流。
（1）清单生成使用GenerateGatherManifest命令，创建包含待翻译文本的清单。
（2）档案文件存储翻译文本，GenerateGatherArchive命令实现，并清除过时的空条目。
（3）InternationalizationExport命令导入翻译人员提供的PO文件。
（4）生成.locres文件，UE5运行时使用的本地化资源格式，通过GenerateTextLocalizationResource命令实现。
（5）导出到PO文件步骤为后续的翻译或审核工作提供便利。
（6）生成报告审计和质量保证，包括词数统计和文本冲突，维护高质量本地化至关重要。
Editor.ini文件在UE5的本地化工作流中扮演核心角色，从源头到最终资源，提供清晰路径，确保开发流程国际化，提升效率和翻译质量。
