1. 项目概述深入UE5光线追踪的几何体收集机制如果你正在UE5里折腾光线追踪想让你的场景在RTX下跑得又快又稳那么“几何体收集”这个环节绝对是你绕不开的核心。这不仅仅是把场景里的静态网格体丢给RT Core那么简单。想象一下你有一个庞大的开放世界里面有成千上万个模型从一棵草到一座山每个模型的顶点数据、材质属性、实例变换信息都不同。光线追踪渲染每一帧时都需要知道“光线可以打到哪些几何体”。UE5的“光线追踪几何体收集”过程本质上就是在渲染一帧开始前高效、精准地构建这份“可命中目标清单”。这个过程发生在CPU端是连接传统光栅化管线与硬件光线追踪管线的桥梁。它的性能直接决定了RT效果的渲染效率和质量。如果收集不全就会出现物体“漏光”或根本不参与光线交互的Bug如果收集效率低下每一帧都会在提交GPU工作前产生CPU瓶颈导致帧率骤降。因此理解源码中175这个版本或特定提交标识下的实现就等于掌握了UE5优化RT场景性能的一把钥匙。无论你是图形程序员、技术美术还是对引擎底层有浓厚兴趣的开发者拆解这部分代码都能让你对现代实时渲染引擎的架构有更深刻的认识。2. 核心流程与架构设计解析UE5中光线追踪几何体的收集并非一个孤立的函数而是一个贯穿渲染模块多个层次的协作体系。其核心目标是构建一个名为FRayTracingGeometry的数据结构这个结构最终会被转换为底层图形API如DirectX 12的DXR或Vulkan的VK_KHR_ray_tracing所能理解的加速结构Acceleration Structure AS数据。2.1 收集流程的顶层视图整个收集流程可以概括为“筛选 - 提取 - 转换 - 提交”四个阶段。筛选阶段并非所有场景中的UStaticMeshComponent或USkeletalMeshComponent都会进入光线追踪管线。引擎会根据组件的属性进行筛选例如bVisibleInRayTracing这是组件上最直接的开关。如果为false则直接跳过。RayTracingGroupId用于分组管理可以实现仅对特定组的物体进行光线追踪。距离和屏幕尺寸剔除对于非常远或屏幕空间占比极小的物体可能被剔除以节省构建加速结构BLAS的开销。LOD选择与光栅化类似会根据距离选择适当的LOD层级其顶点数据将用于构建光线追踪几何体。提取阶段对于通过筛选的组件需要从其渲染代理如FStaticMeshSceneProxy中提取几何数据。这主要包括顶点缓冲区位置信息是必须的。通常使用组件世界空间下的位置。索引缓冲区定义三角形如何由顶点构成。变换矩阵实例化静态网格体ISM/HISM可能有多个实例每个实例都有自己的世界变换矩阵这些矩阵需要被收集并用于几何体的实例化。转换阶段将提取的原始网格数据转换为FRayTracingGeometry所需的数据格式。这个结构体内部管理着Initializer描述几何体的初始化参数包括顶点/索引缓冲区格式、三角形数量、标志位如是否双面、是否不透明等。RayTracingGeometryRHI一个指向底层RHI渲染硬件接口资源的指针真正的加速结构BLAS对象。这个阶段的一个关键决策是是否启用“动态几何体”路径。对于每一帧顶点都可能变化的物体如蒙皮的骨骼网格体UE5会将其标记为动态并采用不同的更新策略完全重建或部分更新这比静态几何体的开销大得多。提交阶段将所有收集并初始化好的FRayTracingGeometry实例以及它们的实例变换矩阵提交给RHI层以构建顶层加速结构TLAS。TLAS是所有BLAS实例的索引是光线追踪查询的最终入口点。2.2 关键代码模块与类职责要阅读相关源码你需要关注以下几个核心模块和类Renderer模块这是主战场。特别是RayTracing相关的源文件。SceneVisibility.cpp中的FDeferredShadingSceneRenderer::GatherRayTracingWorldInstances或其类似函数这里是收集的起点。它遍历场景中的FPrimitiveSceneInfo根据条件决定哪些图元需要收集。RayTracingGeometryManager.cpp/.h管理FRayTracingGeometry生命周期的核心管理器。负责创建、更新、销毁几何体资源。RayTracingInstanceBufferUtil.cpp处理实例化数据的工具函数对于ISM/HISM的大量实例收集至关重要。FRayTracingGeometry类这个类是核心数据结构定义在RayTracingGeometry.h中。它封装了底层加速结构的所有信息。阅读其Init()、Update()等方法能理解数据是如何填充的。MeshDrawCommands管线UE5的渲染合批与状态管理核心。光线追踪几何体的收集与Mesh Draw Command的生成紧密相关因为很多材质、着色器绑定信息需要从这里同步。查看FMeshDrawCommand中与RayTracing相关的标志位和数据。RHI层抽象在DynamicRHI.h和平台特定的RHI实现如D3D12RayTracing.cpp中可以找到FRayTracingGeometryRHI接口的具体实现了解加速结构是如何在GPU上创建和更新的。实操心得定位入口点对于像“175”这样的特定版本或提交最好的方法是先在代码库中全局搜索“GatherRayTracing”或“RayTracingGeometry”等关键词。重点关注DeferredShadingRenderer类中的大型渲染函数如Render()里面通常会有分阶段的任务。光线追踪收集通常发生在“InitViews”和“PrePass”之后在“BasePass”之前的一个独立阶段。找到这个阶段函数就找到了阅读的入口。3. 核心数据结构与资源管理深度剖析理解数据是如何被组织和管理的是优化性能的基础。FRayTracingGeometry是这个体系的心脏。3.1 FRayTracingGeometry 的构成一个FRayTracingGeometry对象代表一个可供光线击中的几何体单元。其内部结构设计考虑了静态与动态、单个与实例化等多种用例。// 简化示意非实际源码 struct FRayTracingGeometryInitializer { TArrayFRayTracingGeometrySegment Segments; // 几何体分段对应不同的LOD或材质槽 EPrimitiveType PrimitiveType; // 三角形列表等 EAccelerationStructureFlags BuildFlags; // 静态/动态允许更新/压缩等 // ... 其他如顶点/索引格式、数量等 }; class FRayTracingGeometry { public: FRayTracingGeometryInitializer Initializer; FRayTracingGeometryRHIRef RayTracingGeometryRHI; // 底层加速结构 TArrayFTransforms InstanceTransforms; // 如果是实例化存储变换矩阵 bool bIsDynamic; bool bIsCompacted; // 是否经过压缩优化 void InitResource(FRHICommandListBase RHICmdList); void ReleaseResource(); void UpdateVertexBuffer(FRHICommandListBase RHICmdList, ...); };Segments分段这是关键设计。一个静态网格体可能有多个材质槽Material Slots在光线追踪中每个材质槽通常对应一个几何体分段。当光线击中一个三角形时除了位置信息还需要知道它属于哪个分段从而索引到正确的材质和着色器数据。分段信息将网格的几何数据与渲染管线中的着色器绑定表Shader Binding Table SBT关联起来。BuildFlags构建标志RAYTRACING_ACCELERATION_STRUCTURE_BUILD_FLAG_PREFER_FAST_TRACE与RAYTRACING_ACCELERATION_STRUCTURE_BUILD_FLAG_PREFER_FAST_BUILD之间的权衡。对于静态物体我们选择FAST_TRACE以获得最佳遍历性能对于每帧更新的动态物体则可能选择FAST_BUILD以加快构建速度。ALLOW_UPDATE标志允许增量更新而非完全重建对于顶点动画微变的物体是重要优化。InstanceTransforms实例变换对于实例化静态网格体UE5不会为每个实例创建独立的BLAS。相反它只创建一个共享的FRayTracingGeometryBLAS然后在构建TLAS时为每个实例提供一个变换矩阵。这极大地节省了内存和构建时间。3.2 资源生命周期与更新策略几何体资源的管理遵循“懒创建按需更新”的原则。首次创建当一个图元首次被判定需要光线追踪且其FRayTracingGeometry尚未初始化时管理器会调用InitResource。这个过程会根据网格数据填充Initializer。通过RHI接口在GPU上分配内存并触发底层API的加速结构构建命令。这是一个相对耗时的操作通常安排在帧的早期或空闲时间。静态几何体一旦创建在网格数据不变的情况下其BLAS可以被无限期重用。TLAS每帧重建时只需引用这个静态的BLAS和新的实例变换如果物体移动了。动态几何体对于骨骼网格体或顶点动画物体需要每帧更新。完全重建如果几何体拓扑改变三角形数量变化或没有设置ALLOW_UPDATE标志则需要完全重建BLAS开销最大。增量更新如果只是顶点位置变化如蒙皮且BLAS支持更新则可以只更新顶点缓冲区并触发一个更快的“更新”操作而不是“重建”。在源码中你会看到对bIsDynamic的判断以及对RHICmdList.BuildRayTracingAccelerationStructure()与RHICmdList.UpdateRayTracingAccelerationStructure()的不同调用。释放当图元被移除或不再需要光线追踪时其FRayTracingGeometry会被标记资源在适当的时机如帧末被释放回池中或直接销毁。注意事项内存与性能的平衡BLAS池为了避免频繁创建销毁带来的开销UE5可能会实现一个FRayTracingGeometry对象池。对于形状相同但位置不同的物体如同一种树木可以复用同一个BLAS资源仅更新TLAS中的实例变换。在阅读源码时可以留意是否有类似TRayTracingGeometryPool或引用计数的机制。压缩Compaction在加速结构构建完成后可以触发一个压缩操作释放构建过程中使用的临时内存和碎片。bIsCompacted标志可能与此相关。这是一个用时间换空间的操作通常在加载后或流送完成时进行。流送Streaming对于开放世界高精度模型的BLAS构建很慢。UE5可能会将BLAS的构建与网格体的流送绑定当高LOD模型流送进来时异步构建其光线追踪几何体。这涉及到更复杂的优先级和依赖管理。4. 实例化静态网格体的高效处理机制在现代游戏中使用实例化静态网格体Instanced Static Mesh ISM或层级实例化静态网格体Hierarchical ISM HISM来渲染大量重复物体如草地、碎石、森林是标准做法。光线追踪必须高效支持这一特性。4.1 收集过程的优化策略UE5不会为ISM的每一个实例单独收集和创建几何体数据那将是灾难性的。其核心优化在于“实例化数据”与“几何体数据”的分离。几何体数据单例化对于同一个静态网格体资产UStaticMesh无论它在场景中被实例化多少次在光线追踪上下文中只对应一个FRayTracingGeometry对象即一个BLAS。这个BLAS基于该网格体的顶点和索引数据创建。实例数据的批量收集在收集阶段系统会识别出所有使用同一UStaticMesh的ISM组件。遍历这些组件的每一个实例收集其世界变换矩阵FMatrix或FTransform并将这些矩阵存储在一个线性的缓冲区中。这个缓冲区就是后续构建TLAS时所需的实例描述符Instance Descriptor数组。GPU实例缓冲区收集到的实例变换矩阵会被上传到一个GPU缓冲区如StructuredBuffer中。这个缓冲区在构建TLAS时被引用。TLAS中的每个实例记录都包含对应的BLAS的索引、实例变换矩阵的索引、实例掩码Instance Mask用于光线过滤、命中组偏移Hit Group Offset等。在源码中的体现你需要关注FInstanceCullingContext或类似的实例剔除上下文。在光线追踪收集路径中会有一个并行或集成的过程来填充“光线追踪实例数据”。函数如GatherRayTracingInstances或UploadRayTracingInstanceData会负责将成千上万的实例变换打包、压缩例如使用FMatrix44f代替FMatrix以减少带宽并准备给RHI层使用。4.2 实例剔除与LOD的交互光线追踪下的实例剔除比光栅化更复杂因为它影响的是加速结构的质量而非仅仅是绘制调用。视锥剔除与光栅化一样不在摄像机视锥内的实例不需要被包含在TLAS中。这发生在CPU端收集阶段。距离剔除对于非常远的实例可以完全跳过其光线追踪几何体或者使用一个更简化的代理几何体低LOD的BLAS来代表。LOD选择ISM组件本身可能支持每实例LOD。在收集时需要根据实例的距离决定为其引用哪个LOD层级对应的FRayTracingGeometry。这意味着同一个UStaticMesh可能需要为它的不同LOD准备多个BLAS。收集过程需要为每个实例正确索引到对应的BLAS。实操心得调试实例化问题如果发现实例化物体在光线追踪下显示异常如缺失、错位一个有效的调试方法是在渲染线程中找到构建TLAS的命令提交处通常是RHICmdList.BuildRayTracingAccelerationStructure()调用。检查传入的实例描述符数组的数量是否正确。抽取几个实例的描述符将其中的变换矩阵打印出来或与场景中对应Actor的变换进行比对确认数据一致性。检查实例掩码和命中组偏移是否正确设置这关系到光线击中后能否调用正确的着色器。5. 动态几何体与每帧更新策略详解动态几何体如骨骼网格体、变形体、破碎的物体是光线追踪性能的“杀手”也是源码中最具挑战性的部分之一。5.1 动态路径的判定与数据流一个网格体何时走动态路径这通常在FStaticMeshSceneProxy或FSkeletalMeshSceneProxy创建其FRayTracingGeometry时就决定了。判定标志对于骨骼网格体代理其bIsDynamic通常直接设为true。对于静态网格体如果其顶点位置可能通过材质参数或顶点着色器动画发生改变也需要标记为动态。这通常由材质或网格体上的自定义标志控制。在FRayTracingGeometryInitializer的BuildFlags中会包含RAYTRACING_ACCELERATION_STRUCTURE_BUILD_FLAG_ALLOW_UPDATE。数据更新流水线动画线程对于骨骼网格体动画系统先在游戏线程或并行的工作线程中计算好最终的蒙皮矩阵。渲染线程提交在渲染线程中通过FGPUSkinCache或其他路径将蒙皮后的顶点数据计算并填充到顶点缓冲区中。这个过程可能直接在GPU上进行Compute Shader也可能在CPU上计算后上传。几何体更新拥有新顶点数据的顶点缓冲区被绑定。然后渲染线程通过FRayTracingGeometry::UpdateVertexBuffer接口或类似的RHI命令通知底层RHI层“这个BLAS的顶点数据已经变了请更新它。”异步构建/更新RHI层收到更新命令后可能会将“更新加速结构”的任务加入命令队列。在支持硬件加速更新的情况下这是一个相对快速的操作但依然有开销。5.2 性能优化与权衡动态几何体的处理充满了权衡更新 vs 重建如果几何体的拓扑三角形连接关系发生变化ALLOW_UPDATE将无效必须完全重建BLAS开销巨大。因此对于可破碎的物体通常的策略是破碎前是一个静态BLAS破碎后将碎片作为新的静态或动态物体处理原来的BLAS被丢弃。更新粒度是更新整个顶点缓冲区还是只更新变化的部分UE5通常采用全量更新因为识别增量变化的管理开销可能超过全量更新的成本。但对于只有局部顶点动画的物体如飘动的旗帜理论上可以优化。帧间延迟由于GPU命令的异步性顶点数据的更新和加速结构的更新可能不会立即完成。这意味着在某一帧光线追踪查询可能还在使用上一帧的几何体形状。这在高速运动的物体上可能导致视觉瑕疵“鬼影”。引擎需要仔细管理这种依赖关系确保在光线追踪通道开始前所有需要的加速结构更新都已经完成。常见问题排查动态物体不更新或闪烁检查更新标志首先确认FRayTracingGeometry的bIsDynamic是否为true且初始化标志包含ALLOW_UPDATE。验证顶点数据在渲染线程中检查用于更新BLAS的顶点缓冲区内容是否正确。可以在更新命令前后插入GPU捕获查看缓冲区数据。检查命令顺序确保UpdateRayTracingAccelerationStructure的命令在TraceRays的DispatchRays命令之前被提交。使用图形调试器如RenderDoc、Nsight查看命令列表的顺序。资源屏障顶点缓冲区在更新后需要正确的资源状态转换Resource Barrier到RAYTRACING_ACCELERATION_STRUCTURE状态才能被加速结构构建操作安全读取。缺失屏障是导致数据不同步的常见原因。6. 与渲染管线的集成及同步挑战光线追踪几何体的收集不是孤立的它必须无缝嵌入UE5庞大的渲染框架中并与传统的光栅化管线保持同步。6.1 收集时机的选择在FDeferredShadingSceneRenderer::Render这个主渲染函数中几何体收集发生在哪个阶段至关重要。在Visibility计算之后收集必须发生在场景可见性计算ComputeViewVisibility之后。因为我们需要知道哪些图元是可见的或可能对光线追踪有贡献才能决定是否收集它们。这避免了为完全不可见的物体浪费资源。在BasePass之前Lighting之后实际上光线追踪几何体的收集可能独立于主光栅化通道。它可能在一个名为GatherRayTracingWorldInstances的独立函数中执行这个函数在InitViews之后被调用为后续可能的光线追踪通道如环境光遮蔽、全局光照、反射准备数据。异步收集的可能性为了降低CPU端的帧时间收集工作可以被并行化。例如将场景分块由多个工作线程并行收集不同区域的实例数据最后合并。在源码中你可能会看到ParallelFor或任务图Task Graph被用于此目的。6.2 与MeshDrawCommand的同步这是集成中最微妙的部分。FMeshDrawCommand封装了绘制一个网格体所需的所有状态顶点缓冲区、索引缓冲区、着色器绑定、PSO等。对于光线追踪当一条光线击中一个三角形时它需要知道该执行哪个着色器命中着色器。这个映射关系就是通过MeshDrawCommand来建立的。命中组索引在收集几何体时每个FRayTracingGeometrySegment几何体分段需要关联到一个“命中组Hit Group”。这个命中组在着色器绑定表SBT中有一个索引。而这个索引通常来源于该分段对应的材质在MeshDrawCommand中的某种标识。着色器绑定光线追踪使用的着色器如最近命中着色器ClosestHitShader需要访问与光栅化相同的材质参数、纹理等。因此在构建SBT时需要将MeshDrawCommand中的着色器资源绑定SRV/UAV/CBV等信息也关联到对应的命中组记录中。数据一致性任何影响MeshDrawCommand生成的因素如材质切换、纹理流送、着色器编译都可能影响光线追踪命中组的正确性。引擎必须确保在光线追踪通道开始时SBT中的命中组描述与当前帧实际使用的MeshDrawCommand状态完全一致。实操心得调试着色器绑定错误如果光线击中物体后出现粉红错误Missing Shader或显示错误材质问题很可能出在SBT的绑定上。使用调试工具如PIX for Windows捕获一帧检查SBT的结构。确认每个命中组记录指向的着色器标识符是否正确。在CPU端代码中跟踪从FPrimitiveSceneInfo-FMeshDrawCommand-RayTracing Hit Group Index的映射逻辑。确保在材质或网格体发生变化时这个映射被正确更新。检查FRayTracingGeometryInitializer中的Segments数组。每个分段是否正确地对应了网格体的一个材质槽分段的FirstPrimitive和NumPrimitives是否正确划分了三角形范围7. 平台差异与RHI抽象层实现UE5通过RHIRendering Hardware Interface层来抽象不同图形APID3D12, Vulkan, PlayStation的GNM等的差异。光线追踪几何体的收集最终要调用到具体的RHI实现。7.1 加速结构构建的API差异DirectX 12 DXR这是最成熟的路径。FRayTracingGeometryRHI在D3D12后端可能对应一个ID3D12Resource其内部存储着D3D12_RAYTRACING_ACCELERATION_STRUCTURE_BUILD_FLAGS。构建过程通过ID3D12GraphicsCommandList4::BuildRaytracingAccelerationStructure完成。DXR对实例化和更新有良好的原生支持。Vulkan Ray Tracing原理类似但API细节不同。使用VkAccelerationStructureKHR构建信息通过VkAccelerationStructureBuildGeometryInfoKHR等结构体描述。Vulkan的显存管理VkDeviceMemory和同步要求VkFence/VkSemaphore与D3D12有区别。软件回退路径对于不支持硬件光线追踪的平台UE5可能提供一种软件光线追踪的模拟路径。在这种情况下“加速结构”可能只是一个经过空间划分如BVH的CPU数据结构FRayTracingGeometry的收集过程则是在构建这个CPU侧的BVH。7.2 RHI层的接口设计在DynamicRHI.h中你会看到一组纯虚函数接口例如virtual FRayTracingGeometryRHIRef RHICreateRayTracingGeometry(FRHICommandListBase RHICmdList, const FRayTracingGeometryInitializer Initializer) 0; virtual void RHIBuildRayTracingAccelerationStructure(FRHICommandListBase RHICmdList, const FRayTracingGeometryBuildParams Params) 0; virtual void RHIUpdateRayTracingAccelerationStructure(FRHICommandListBase RHICmdList, const FRayTracingGeometryBuildParams Params) 0;RayTracingGeometryManager等上层模块调用这些RHI接口而不关心底层是D3D12还是Vulkan。阅读平台特定的RHI实现文件如D3D12RayTracing.cpp你可以看到这些抽象接口是如何映射到具体的API调用、内存分配和命令提交上的。注意事项内存对齐与生命周期不同API对加速结构的内存对齐和生命周期管理有不同要求。D3D12要求加速结构放置在特定的堆D3D12_HEAP_TYPE_DEFAULT中并且其地址在生命周期内保持不变除非释放。Vulkan也有类似的对齐VkAccelerationStructureMemoryRequirementsInfoKHR和绑定要求。RHI层需要妥善处理这些细节确保上层传递的顶点/索引数据格式符合要求并在加速结构不再需要时安全地释放内存。8. 性能剖析与优化实战指南阅读源码的最终目的是为了优化。以下是一些基于源码逻辑的实战优化思路。8.1 CPU端收集性能优化并行化收集检查GatherRayTracingWorldInstances函数。它是否在遍历所有FPrimitiveSceneInfo这个遍历是否可以并行化使用ParallelFor遍历图元数组将实例数据收集到线程本地存储TLS最后合并可以显著降低主线程耗时。增量式更新对于动态物体避免每帧全量收集。可以维护一个“脏标记”系统。只有当物体的变换、可见性状态或几何数据真正发生变化时才将其标记为“需要更新”并在收集阶段只处理这些脏物体。数据预计算与缓存对于静态物体的实例变换矩阵如果物体不会移动其矩阵可以预先计算并缓存避免每帧从组件变换中重新计算。8.2 GPU端加速结构构建优化BLAS构建的调度策略不要在同一帧同步构建大量大型BLAS。对于流送进来的复杂静态网格体可以将其BLAS构建任务分散到多帧中异步进行避免帧率卡顿。在源码中寻找类似AsyncRayTracingGeometryBuildTask的任务封装。合并小型几何体对于大量的小型、简单的几何体如树叶、碎石为每一个都构建独立的BLAS会带来巨大的元数据开销。考虑在CPU或GPU上将它们合并成一个更大的几何体然后构建一个统一的BLAS。这需要修改收集逻辑在特定条件下如材质相同、位置邻近将多个网格体的顶点/索引数据合并。压缩与量化在将实例变换矩阵上传到GPU缓冲区时使用FMatrix44f单精度浮点数代替FMatrix双精度。甚至可以考虑使用更紧凑的格式如平移FVector3f 旋转FQuat4f 缩放FVector3f并在着色器中重建矩阵。8.3 调试与性能分析工具的使用Stat Commands在游戏中输入stat rhi或更具体的stat raytracing可以查看每帧构建BLAS/TLAS的数量、时间以及内存使用情况。GPU Profiler使用RenderDoc或Nsight Graphics捕获一帧。在命令列表中找到BuildRayTracingAccelerationStructure和UpdateRayTracingAccelerationStructure命令查看它们的耗时。同时检查TraceRaysDispatch命令之前的资源屏障是否过多。CPU Profiler使用Unreal Insights或Visual Studio Profiler分析GatherRayTracingWorldInstances及其调用树的CPU时间。识别热点循环和频繁的内存分配。一个具体的优化案例流送世界中的BLAS管理在开放世界游戏中当玩家移动时新的网格体流送进来旧的流送出去。为每个流送进来的高精度网格体立即构建BLAS会导致卡顿。优化方案在流送系统通知网格体就绪后不立即构建BLAS而是将其加入一个低优先级的构建队列。在每帧的渲染线程中分配一个固定的时间预算例如2ms用于处理这个队列。在这个预算内按优先级如到摄像机的距离从队列中取出几个网格体发起异步的BLAS构建请求。在BLAS构建完成之前该物体要么不使用光线追踪要么使用一个预先准备好的、简化的代理BLAS如一个包围盒。在源码中实现此方案需要修改URayTracingGeometryManager增加一个待处理队列和异步任务管理逻辑并与流送系统的事件进行对接。深入UE5光线追踪几何体收集的源码就像拆解一台精密的钟表。每一个类、每一个函数调用、每一个数据标志都是为了在动态、复杂的实时渲染世界中高效、准确地为每一束光线准备好碰撞的目标。这个过程充满了权衡精度与性能、内存与速度、通用性与特化。理解它不仅能帮助你解决光线追踪相关的Bug和性能问题更能让你从底层把握现代游戏引擎渲染架构的设计哲学。当你下次在UE5中开启光线追踪时你会知道眼前绚丽的画面背后是成千上万个FRayTracingGeometry对象和无数行精心设计的代码在默默支撑。
UE5光线追踪几何体收集机制：从原理到源码优化实战
1. 项目概述深入UE5光线追踪的几何体收集机制如果你正在UE5里折腾光线追踪想让你的场景在RTX下跑得又快又稳那么“几何体收集”这个环节绝对是你绕不开的核心。这不仅仅是把场景里的静态网格体丢给RT Core那么简单。想象一下你有一个庞大的开放世界里面有成千上万个模型从一棵草到一座山每个模型的顶点数据、材质属性、实例变换信息都不同。光线追踪渲染每一帧时都需要知道“光线可以打到哪些几何体”。UE5的“光线追踪几何体收集”过程本质上就是在渲染一帧开始前高效、精准地构建这份“可命中目标清单”。这个过程发生在CPU端是连接传统光栅化管线与硬件光线追踪管线的桥梁。它的性能直接决定了RT效果的渲染效率和质量。如果收集不全就会出现物体“漏光”或根本不参与光线交互的Bug如果收集效率低下每一帧都会在提交GPU工作前产生CPU瓶颈导致帧率骤降。因此理解源码中175这个版本或特定提交标识下的实现就等于掌握了UE5优化RT场景性能的一把钥匙。无论你是图形程序员、技术美术还是对引擎底层有浓厚兴趣的开发者拆解这部分代码都能让你对现代实时渲染引擎的架构有更深刻的认识。2. 核心流程与架构设计解析UE5中光线追踪几何体的收集并非一个孤立的函数而是一个贯穿渲染模块多个层次的协作体系。其核心目标是构建一个名为FRayTracingGeometry的数据结构这个结构最终会被转换为底层图形API如DirectX 12的DXR或Vulkan的VK_KHR_ray_tracing所能理解的加速结构Acceleration Structure AS数据。2.1 收集流程的顶层视图整个收集流程可以概括为“筛选 - 提取 - 转换 - 提交”四个阶段。筛选阶段并非所有场景中的UStaticMeshComponent或USkeletalMeshComponent都会进入光线追踪管线。引擎会根据组件的属性进行筛选例如bVisibleInRayTracing这是组件上最直接的开关。如果为false则直接跳过。RayTracingGroupId用于分组管理可以实现仅对特定组的物体进行光线追踪。距离和屏幕尺寸剔除对于非常远或屏幕空间占比极小的物体可能被剔除以节省构建加速结构BLAS的开销。LOD选择与光栅化类似会根据距离选择适当的LOD层级其顶点数据将用于构建光线追踪几何体。提取阶段对于通过筛选的组件需要从其渲染代理如FStaticMeshSceneProxy中提取几何数据。这主要包括顶点缓冲区位置信息是必须的。通常使用组件世界空间下的位置。索引缓冲区定义三角形如何由顶点构成。变换矩阵实例化静态网格体ISM/HISM可能有多个实例每个实例都有自己的世界变换矩阵这些矩阵需要被收集并用于几何体的实例化。转换阶段将提取的原始网格数据转换为FRayTracingGeometry所需的数据格式。这个结构体内部管理着Initializer描述几何体的初始化参数包括顶点/索引缓冲区格式、三角形数量、标志位如是否双面、是否不透明等。RayTracingGeometryRHI一个指向底层RHI渲染硬件接口资源的指针真正的加速结构BLAS对象。这个阶段的一个关键决策是是否启用“动态几何体”路径。对于每一帧顶点都可能变化的物体如蒙皮的骨骼网格体UE5会将其标记为动态并采用不同的更新策略完全重建或部分更新这比静态几何体的开销大得多。提交阶段将所有收集并初始化好的FRayTracingGeometry实例以及它们的实例变换矩阵提交给RHI层以构建顶层加速结构TLAS。TLAS是所有BLAS实例的索引是光线追踪查询的最终入口点。2.2 关键代码模块与类职责要阅读相关源码你需要关注以下几个核心模块和类Renderer模块这是主战场。特别是RayTracing相关的源文件。SceneVisibility.cpp中的FDeferredShadingSceneRenderer::GatherRayTracingWorldInstances或其类似函数这里是收集的起点。它遍历场景中的FPrimitiveSceneInfo根据条件决定哪些图元需要收集。RayTracingGeometryManager.cpp/.h管理FRayTracingGeometry生命周期的核心管理器。负责创建、更新、销毁几何体资源。RayTracingInstanceBufferUtil.cpp处理实例化数据的工具函数对于ISM/HISM的大量实例收集至关重要。FRayTracingGeometry类这个类是核心数据结构定义在RayTracingGeometry.h中。它封装了底层加速结构的所有信息。阅读其Init()、Update()等方法能理解数据是如何填充的。MeshDrawCommands管线UE5的渲染合批与状态管理核心。光线追踪几何体的收集与Mesh Draw Command的生成紧密相关因为很多材质、着色器绑定信息需要从这里同步。查看FMeshDrawCommand中与RayTracing相关的标志位和数据。RHI层抽象在DynamicRHI.h和平台特定的RHI实现如D3D12RayTracing.cpp中可以找到FRayTracingGeometryRHI接口的具体实现了解加速结构是如何在GPU上创建和更新的。实操心得定位入口点对于像“175”这样的特定版本或提交最好的方法是先在代码库中全局搜索“GatherRayTracing”或“RayTracingGeometry”等关键词。重点关注DeferredShadingRenderer类中的大型渲染函数如Render()里面通常会有分阶段的任务。光线追踪收集通常发生在“InitViews”和“PrePass”之后在“BasePass”之前的一个独立阶段。找到这个阶段函数就找到了阅读的入口。3. 核心数据结构与资源管理深度剖析理解数据是如何被组织和管理的是优化性能的基础。FRayTracingGeometry是这个体系的心脏。3.1 FRayTracingGeometry 的构成一个FRayTracingGeometry对象代表一个可供光线击中的几何体单元。其内部结构设计考虑了静态与动态、单个与实例化等多种用例。// 简化示意非实际源码 struct FRayTracingGeometryInitializer { TArrayFRayTracingGeometrySegment Segments; // 几何体分段对应不同的LOD或材质槽 EPrimitiveType PrimitiveType; // 三角形列表等 EAccelerationStructureFlags BuildFlags; // 静态/动态允许更新/压缩等 // ... 其他如顶点/索引格式、数量等 }; class FRayTracingGeometry { public: FRayTracingGeometryInitializer Initializer; FRayTracingGeometryRHIRef RayTracingGeometryRHI; // 底层加速结构 TArrayFTransforms InstanceTransforms; // 如果是实例化存储变换矩阵 bool bIsDynamic; bool bIsCompacted; // 是否经过压缩优化 void InitResource(FRHICommandListBase RHICmdList); void ReleaseResource(); void UpdateVertexBuffer(FRHICommandListBase RHICmdList, ...); };Segments分段这是关键设计。一个静态网格体可能有多个材质槽Material Slots在光线追踪中每个材质槽通常对应一个几何体分段。当光线击中一个三角形时除了位置信息还需要知道它属于哪个分段从而索引到正确的材质和着色器数据。分段信息将网格的几何数据与渲染管线中的着色器绑定表Shader Binding Table SBT关联起来。BuildFlags构建标志RAYTRACING_ACCELERATION_STRUCTURE_BUILD_FLAG_PREFER_FAST_TRACE与RAYTRACING_ACCELERATION_STRUCTURE_BUILD_FLAG_PREFER_FAST_BUILD之间的权衡。对于静态物体我们选择FAST_TRACE以获得最佳遍历性能对于每帧更新的动态物体则可能选择FAST_BUILD以加快构建速度。ALLOW_UPDATE标志允许增量更新而非完全重建对于顶点动画微变的物体是重要优化。InstanceTransforms实例变换对于实例化静态网格体UE5不会为每个实例创建独立的BLAS。相反它只创建一个共享的FRayTracingGeometryBLAS然后在构建TLAS时为每个实例提供一个变换矩阵。这极大地节省了内存和构建时间。3.2 资源生命周期与更新策略几何体资源的管理遵循“懒创建按需更新”的原则。首次创建当一个图元首次被判定需要光线追踪且其FRayTracingGeometry尚未初始化时管理器会调用InitResource。这个过程会根据网格数据填充Initializer。通过RHI接口在GPU上分配内存并触发底层API的加速结构构建命令。这是一个相对耗时的操作通常安排在帧的早期或空闲时间。静态几何体一旦创建在网格数据不变的情况下其BLAS可以被无限期重用。TLAS每帧重建时只需引用这个静态的BLAS和新的实例变换如果物体移动了。动态几何体对于骨骼网格体或顶点动画物体需要每帧更新。完全重建如果几何体拓扑改变三角形数量变化或没有设置ALLOW_UPDATE标志则需要完全重建BLAS开销最大。增量更新如果只是顶点位置变化如蒙皮且BLAS支持更新则可以只更新顶点缓冲区并触发一个更快的“更新”操作而不是“重建”。在源码中你会看到对bIsDynamic的判断以及对RHICmdList.BuildRayTracingAccelerationStructure()与RHICmdList.UpdateRayTracingAccelerationStructure()的不同调用。释放当图元被移除或不再需要光线追踪时其FRayTracingGeometry会被标记资源在适当的时机如帧末被释放回池中或直接销毁。注意事项内存与性能的平衡BLAS池为了避免频繁创建销毁带来的开销UE5可能会实现一个FRayTracingGeometry对象池。对于形状相同但位置不同的物体如同一种树木可以复用同一个BLAS资源仅更新TLAS中的实例变换。在阅读源码时可以留意是否有类似TRayTracingGeometryPool或引用计数的机制。压缩Compaction在加速结构构建完成后可以触发一个压缩操作释放构建过程中使用的临时内存和碎片。bIsCompacted标志可能与此相关。这是一个用时间换空间的操作通常在加载后或流送完成时进行。流送Streaming对于开放世界高精度模型的BLAS构建很慢。UE5可能会将BLAS的构建与网格体的流送绑定当高LOD模型流送进来时异步构建其光线追踪几何体。这涉及到更复杂的优先级和依赖管理。4. 实例化静态网格体的高效处理机制在现代游戏中使用实例化静态网格体Instanced Static Mesh ISM或层级实例化静态网格体Hierarchical ISM HISM来渲染大量重复物体如草地、碎石、森林是标准做法。光线追踪必须高效支持这一特性。4.1 收集过程的优化策略UE5不会为ISM的每一个实例单独收集和创建几何体数据那将是灾难性的。其核心优化在于“实例化数据”与“几何体数据”的分离。几何体数据单例化对于同一个静态网格体资产UStaticMesh无论它在场景中被实例化多少次在光线追踪上下文中只对应一个FRayTracingGeometry对象即一个BLAS。这个BLAS基于该网格体的顶点和索引数据创建。实例数据的批量收集在收集阶段系统会识别出所有使用同一UStaticMesh的ISM组件。遍历这些组件的每一个实例收集其世界变换矩阵FMatrix或FTransform并将这些矩阵存储在一个线性的缓冲区中。这个缓冲区就是后续构建TLAS时所需的实例描述符Instance Descriptor数组。GPU实例缓冲区收集到的实例变换矩阵会被上传到一个GPU缓冲区如StructuredBuffer中。这个缓冲区在构建TLAS时被引用。TLAS中的每个实例记录都包含对应的BLAS的索引、实例变换矩阵的索引、实例掩码Instance Mask用于光线过滤、命中组偏移Hit Group Offset等。在源码中的体现你需要关注FInstanceCullingContext或类似的实例剔除上下文。在光线追踪收集路径中会有一个并行或集成的过程来填充“光线追踪实例数据”。函数如GatherRayTracingInstances或UploadRayTracingInstanceData会负责将成千上万的实例变换打包、压缩例如使用FMatrix44f代替FMatrix以减少带宽并准备给RHI层使用。4.2 实例剔除与LOD的交互光线追踪下的实例剔除比光栅化更复杂因为它影响的是加速结构的质量而非仅仅是绘制调用。视锥剔除与光栅化一样不在摄像机视锥内的实例不需要被包含在TLAS中。这发生在CPU端收集阶段。距离剔除对于非常远的实例可以完全跳过其光线追踪几何体或者使用一个更简化的代理几何体低LOD的BLAS来代表。LOD选择ISM组件本身可能支持每实例LOD。在收集时需要根据实例的距离决定为其引用哪个LOD层级对应的FRayTracingGeometry。这意味着同一个UStaticMesh可能需要为它的不同LOD准备多个BLAS。收集过程需要为每个实例正确索引到对应的BLAS。实操心得调试实例化问题如果发现实例化物体在光线追踪下显示异常如缺失、错位一个有效的调试方法是在渲染线程中找到构建TLAS的命令提交处通常是RHICmdList.BuildRayTracingAccelerationStructure()调用。检查传入的实例描述符数组的数量是否正确。抽取几个实例的描述符将其中的变换矩阵打印出来或与场景中对应Actor的变换进行比对确认数据一致性。检查实例掩码和命中组偏移是否正确设置这关系到光线击中后能否调用正确的着色器。5. 动态几何体与每帧更新策略详解动态几何体如骨骼网格体、变形体、破碎的物体是光线追踪性能的“杀手”也是源码中最具挑战性的部分之一。5.1 动态路径的判定与数据流一个网格体何时走动态路径这通常在FStaticMeshSceneProxy或FSkeletalMeshSceneProxy创建其FRayTracingGeometry时就决定了。判定标志对于骨骼网格体代理其bIsDynamic通常直接设为true。对于静态网格体如果其顶点位置可能通过材质参数或顶点着色器动画发生改变也需要标记为动态。这通常由材质或网格体上的自定义标志控制。在FRayTracingGeometryInitializer的BuildFlags中会包含RAYTRACING_ACCELERATION_STRUCTURE_BUILD_FLAG_ALLOW_UPDATE。数据更新流水线动画线程对于骨骼网格体动画系统先在游戏线程或并行的工作线程中计算好最终的蒙皮矩阵。渲染线程提交在渲染线程中通过FGPUSkinCache或其他路径将蒙皮后的顶点数据计算并填充到顶点缓冲区中。这个过程可能直接在GPU上进行Compute Shader也可能在CPU上计算后上传。几何体更新拥有新顶点数据的顶点缓冲区被绑定。然后渲染线程通过FRayTracingGeometry::UpdateVertexBuffer接口或类似的RHI命令通知底层RHI层“这个BLAS的顶点数据已经变了请更新它。”异步构建/更新RHI层收到更新命令后可能会将“更新加速结构”的任务加入命令队列。在支持硬件加速更新的情况下这是一个相对快速的操作但依然有开销。5.2 性能优化与权衡动态几何体的处理充满了权衡更新 vs 重建如果几何体的拓扑三角形连接关系发生变化ALLOW_UPDATE将无效必须完全重建BLAS开销巨大。因此对于可破碎的物体通常的策略是破碎前是一个静态BLAS破碎后将碎片作为新的静态或动态物体处理原来的BLAS被丢弃。更新粒度是更新整个顶点缓冲区还是只更新变化的部分UE5通常采用全量更新因为识别增量变化的管理开销可能超过全量更新的成本。但对于只有局部顶点动画的物体如飘动的旗帜理论上可以优化。帧间延迟由于GPU命令的异步性顶点数据的更新和加速结构的更新可能不会立即完成。这意味着在某一帧光线追踪查询可能还在使用上一帧的几何体形状。这在高速运动的物体上可能导致视觉瑕疵“鬼影”。引擎需要仔细管理这种依赖关系确保在光线追踪通道开始前所有需要的加速结构更新都已经完成。常见问题排查动态物体不更新或闪烁检查更新标志首先确认FRayTracingGeometry的bIsDynamic是否为true且初始化标志包含ALLOW_UPDATE。验证顶点数据在渲染线程中检查用于更新BLAS的顶点缓冲区内容是否正确。可以在更新命令前后插入GPU捕获查看缓冲区数据。检查命令顺序确保UpdateRayTracingAccelerationStructure的命令在TraceRays的DispatchRays命令之前被提交。使用图形调试器如RenderDoc、Nsight查看命令列表的顺序。资源屏障顶点缓冲区在更新后需要正确的资源状态转换Resource Barrier到RAYTRACING_ACCELERATION_STRUCTURE状态才能被加速结构构建操作安全读取。缺失屏障是导致数据不同步的常见原因。6. 与渲染管线的集成及同步挑战光线追踪几何体的收集不是孤立的它必须无缝嵌入UE5庞大的渲染框架中并与传统的光栅化管线保持同步。6.1 收集时机的选择在FDeferredShadingSceneRenderer::Render这个主渲染函数中几何体收集发生在哪个阶段至关重要。在Visibility计算之后收集必须发生在场景可见性计算ComputeViewVisibility之后。因为我们需要知道哪些图元是可见的或可能对光线追踪有贡献才能决定是否收集它们。这避免了为完全不可见的物体浪费资源。在BasePass之前Lighting之后实际上光线追踪几何体的收集可能独立于主光栅化通道。它可能在一个名为GatherRayTracingWorldInstances的独立函数中执行这个函数在InitViews之后被调用为后续可能的光线追踪通道如环境光遮蔽、全局光照、反射准备数据。异步收集的可能性为了降低CPU端的帧时间收集工作可以被并行化。例如将场景分块由多个工作线程并行收集不同区域的实例数据最后合并。在源码中你可能会看到ParallelFor或任务图Task Graph被用于此目的。6.2 与MeshDrawCommand的同步这是集成中最微妙的部分。FMeshDrawCommand封装了绘制一个网格体所需的所有状态顶点缓冲区、索引缓冲区、着色器绑定、PSO等。对于光线追踪当一条光线击中一个三角形时它需要知道该执行哪个着色器命中着色器。这个映射关系就是通过MeshDrawCommand来建立的。命中组索引在收集几何体时每个FRayTracingGeometrySegment几何体分段需要关联到一个“命中组Hit Group”。这个命中组在着色器绑定表SBT中有一个索引。而这个索引通常来源于该分段对应的材质在MeshDrawCommand中的某种标识。着色器绑定光线追踪使用的着色器如最近命中着色器ClosestHitShader需要访问与光栅化相同的材质参数、纹理等。因此在构建SBT时需要将MeshDrawCommand中的着色器资源绑定SRV/UAV/CBV等信息也关联到对应的命中组记录中。数据一致性任何影响MeshDrawCommand生成的因素如材质切换、纹理流送、着色器编译都可能影响光线追踪命中组的正确性。引擎必须确保在光线追踪通道开始时SBT中的命中组描述与当前帧实际使用的MeshDrawCommand状态完全一致。实操心得调试着色器绑定错误如果光线击中物体后出现粉红错误Missing Shader或显示错误材质问题很可能出在SBT的绑定上。使用调试工具如PIX for Windows捕获一帧检查SBT的结构。确认每个命中组记录指向的着色器标识符是否正确。在CPU端代码中跟踪从FPrimitiveSceneInfo-FMeshDrawCommand-RayTracing Hit Group Index的映射逻辑。确保在材质或网格体发生变化时这个映射被正确更新。检查FRayTracingGeometryInitializer中的Segments数组。每个分段是否正确地对应了网格体的一个材质槽分段的FirstPrimitive和NumPrimitives是否正确划分了三角形范围7. 平台差异与RHI抽象层实现UE5通过RHIRendering Hardware Interface层来抽象不同图形APID3D12, Vulkan, PlayStation的GNM等的差异。光线追踪几何体的收集最终要调用到具体的RHI实现。7.1 加速结构构建的API差异DirectX 12 DXR这是最成熟的路径。FRayTracingGeometryRHI在D3D12后端可能对应一个ID3D12Resource其内部存储着D3D12_RAYTRACING_ACCELERATION_STRUCTURE_BUILD_FLAGS。构建过程通过ID3D12GraphicsCommandList4::BuildRaytracingAccelerationStructure完成。DXR对实例化和更新有良好的原生支持。Vulkan Ray Tracing原理类似但API细节不同。使用VkAccelerationStructureKHR构建信息通过VkAccelerationStructureBuildGeometryInfoKHR等结构体描述。Vulkan的显存管理VkDeviceMemory和同步要求VkFence/VkSemaphore与D3D12有区别。软件回退路径对于不支持硬件光线追踪的平台UE5可能提供一种软件光线追踪的模拟路径。在这种情况下“加速结构”可能只是一个经过空间划分如BVH的CPU数据结构FRayTracingGeometry的收集过程则是在构建这个CPU侧的BVH。7.2 RHI层的接口设计在DynamicRHI.h中你会看到一组纯虚函数接口例如virtual FRayTracingGeometryRHIRef RHICreateRayTracingGeometry(FRHICommandListBase RHICmdList, const FRayTracingGeometryInitializer Initializer) 0; virtual void RHIBuildRayTracingAccelerationStructure(FRHICommandListBase RHICmdList, const FRayTracingGeometryBuildParams Params) 0; virtual void RHIUpdateRayTracingAccelerationStructure(FRHICommandListBase RHICmdList, const FRayTracingGeometryBuildParams Params) 0;RayTracingGeometryManager等上层模块调用这些RHI接口而不关心底层是D3D12还是Vulkan。阅读平台特定的RHI实现文件如D3D12RayTracing.cpp你可以看到这些抽象接口是如何映射到具体的API调用、内存分配和命令提交上的。注意事项内存对齐与生命周期不同API对加速结构的内存对齐和生命周期管理有不同要求。D3D12要求加速结构放置在特定的堆D3D12_HEAP_TYPE_DEFAULT中并且其地址在生命周期内保持不变除非释放。Vulkan也有类似的对齐VkAccelerationStructureMemoryRequirementsInfoKHR和绑定要求。RHI层需要妥善处理这些细节确保上层传递的顶点/索引数据格式符合要求并在加速结构不再需要时安全地释放内存。8. 性能剖析与优化实战指南阅读源码的最终目的是为了优化。以下是一些基于源码逻辑的实战优化思路。8.1 CPU端收集性能优化并行化收集检查GatherRayTracingWorldInstances函数。它是否在遍历所有FPrimitiveSceneInfo这个遍历是否可以并行化使用ParallelFor遍历图元数组将实例数据收集到线程本地存储TLS最后合并可以显著降低主线程耗时。增量式更新对于动态物体避免每帧全量收集。可以维护一个“脏标记”系统。只有当物体的变换、可见性状态或几何数据真正发生变化时才将其标记为“需要更新”并在收集阶段只处理这些脏物体。数据预计算与缓存对于静态物体的实例变换矩阵如果物体不会移动其矩阵可以预先计算并缓存避免每帧从组件变换中重新计算。8.2 GPU端加速结构构建优化BLAS构建的调度策略不要在同一帧同步构建大量大型BLAS。对于流送进来的复杂静态网格体可以将其BLAS构建任务分散到多帧中异步进行避免帧率卡顿。在源码中寻找类似AsyncRayTracingGeometryBuildTask的任务封装。合并小型几何体对于大量的小型、简单的几何体如树叶、碎石为每一个都构建独立的BLAS会带来巨大的元数据开销。考虑在CPU或GPU上将它们合并成一个更大的几何体然后构建一个统一的BLAS。这需要修改收集逻辑在特定条件下如材质相同、位置邻近将多个网格体的顶点/索引数据合并。压缩与量化在将实例变换矩阵上传到GPU缓冲区时使用FMatrix44f单精度浮点数代替FMatrix双精度。甚至可以考虑使用更紧凑的格式如平移FVector3f 旋转FQuat4f 缩放FVector3f并在着色器中重建矩阵。8.3 调试与性能分析工具的使用Stat Commands在游戏中输入stat rhi或更具体的stat raytracing可以查看每帧构建BLAS/TLAS的数量、时间以及内存使用情况。GPU Profiler使用RenderDoc或Nsight Graphics捕获一帧。在命令列表中找到BuildRayTracingAccelerationStructure和UpdateRayTracingAccelerationStructure命令查看它们的耗时。同时检查TraceRaysDispatch命令之前的资源屏障是否过多。CPU Profiler使用Unreal Insights或Visual Studio Profiler分析GatherRayTracingWorldInstances及其调用树的CPU时间。识别热点循环和频繁的内存分配。一个具体的优化案例流送世界中的BLAS管理在开放世界游戏中当玩家移动时新的网格体流送进来旧的流送出去。为每个流送进来的高精度网格体立即构建BLAS会导致卡顿。优化方案在流送系统通知网格体就绪后不立即构建BLAS而是将其加入一个低优先级的构建队列。在每帧的渲染线程中分配一个固定的时间预算例如2ms用于处理这个队列。在这个预算内按优先级如到摄像机的距离从队列中取出几个网格体发起异步的BLAS构建请求。在BLAS构建完成之前该物体要么不使用光线追踪要么使用一个预先准备好的、简化的代理BLAS如一个包围盒。在源码中实现此方案需要修改URayTracingGeometryManager增加一个待处理队列和异步任务管理逻辑并与流送系统的事件进行对接。深入UE5光线追踪几何体收集的源码就像拆解一台精密的钟表。每一个类、每一个函数调用、每一个数据标志都是为了在动态、复杂的实时渲染世界中高效、准确地为每一束光线准备好碰撞的目标。这个过程充满了权衡精度与性能、内存与速度、通用性与特化。理解它不仅能帮助你解决光线追踪相关的Bug和性能问题更能让你从底层把握现代游戏引擎渲染架构的设计哲学。当你下次在UE5中开启光线追踪时你会知道眼前绚丽的画面背后是成千上万个FRayTracingGeometry对象和无数行精心设计的代码在默默支撑。
