UE5 GPUScene原理与实战：从性能瓶颈到GPU场景管理

1. 项目概述为什么UE5里突然 everyone 都在聊 GPUScene如果你最近在UE5项目里遇到过这些现象——场景里模型一多帧率就断崖式下跌明明只放了几十个静态网格体Draw Call 却飙到上千用Nanite加载高模后GPU时间没降多少CPU的RenderThread却卡得像在跑单核老古董或者你刚把一个旧项目升级到5.3发现某些自定义渲染通道突然不生效了……那大概率你已经和GPUScene打过照面只是还没正式认识它。GPUScene不是插件、不是蓝图节点、也不是某个可开关的编辑器选项。它是UE5.1之后彻底重构的底层渲染数据组织范式是整个引擎从“CPU主导场景管理”转向“GPU协同场景管理”的分水岭。简单说过去CPU要为每一帧反复计算每个物体的世界矩阵、可见性、材质参数、剔除状态再打包发给GPU现在CPU只做一次初始化和增量更新把所有这些数据——世界变换、实例ID、LOD索引、剔除标记、光照信息——统统塞进一块GPU显存里让GPU自己去查、去算、去跳过不可见物体。这就像把原来需要前台服务员CPU挨个打电话通知每张桌子物体上菜时间的餐厅改成了每张桌子配一块电子屏GPUScene Buffer厨房GPU直接看屏下单服务员只负责更新屏上的菜单状态。关键词“UE”和“GPUScene”之所以成为高频热搜并非因为它们多新潮而是因为绕不开。你在UE5.2里新建一个空项目默认就是GPUScene启用状态你导入一个FBX引擎自动把它注册进GPUScene你写一行GetActorTransform()背后可能触发的是对GPUScene Buffer的读取同步。它不声不响却已渗透到渲染管线的毛细血管里。这篇解析不讲虚的架构图不堆术语就从我实际调试三个真实项目踩过的坑出发一个开放世界地形LOD切换撕裂、一个工业仿真场景合批失败、一个VR应用因GPUScene内存暴涨导致HMD掉帧——把GPUScene怎么建、怎么更、怎么查、怎么崩掰开揉碎讲清楚。适合正在被性能问题卡住的TA、想搞清渲染底层的程序、以及那些在文档里搜“GPUScene”却只看到一句“Enabled by default”的美术向技术同学。2. GPUScene核心设计与底层逻辑拆解2.1 它到底是什么不是镜像是“GPU原生场景数据库”网上很多文章说GPUScene是“CPU场景在GPU的镜像”这个说法容易误导。镜像意味着被动复制、强一致性、读写分离。但GPUScene完全不是这样。它是一套GPU可直接寻址、可原子操作、可并行遍历的结构化数据池其设计目标直指现代GPU硬件特性高带宽显存、大规模并行计算单元、硬件级原子指令支持。我们来看它的物理构成。当你在UE5.3中启用GPUScene默认开启引擎会在GPU显存中分配三块核心BufferSceneInstanceData Buffer这是最核心的。每个实例Instance占64字节存储世界变换矩阵16字节、父实例索引4字节、LOD索引2字节、剔除标记1字节、材质索引2字节、自定义数据39字节。注意这里的世界矩阵是双精度浮点压缩后的16字节表示不是常规的4x4 float矩阵那要64字节。UE用一种叫“FMatrix44fCompressed”的格式把旋转部分用四元数缩放平移部分用int32量化硬生生压到16字节。实测下来对10km范围内的大型开放世界误差控制在0.1mm内完全满足视觉需求。ScenePrimitiveData Buffer按Primitive静态网格体、骨架网格体等资源维度存储。每个Primitive占128字节含顶点缓冲区偏移、索引缓冲区偏移、材质槽位映射、Nanite流送状态、自定义着色器参数绑定。关键点在于它不存几何数据本身只存“去哪里找数据”的指针。这正是GPUScene能支撑百万实例而不爆显存的关键——数据不动指针飞。SceneVisibilityBuffer这不是传统意义上的Buffer而是一块GPU端的Read-Only Texture2DR32_UINT格式。它把整个场景的视锥剔除、遮挡剔除结果编码成一张二维贴图。每个像素代表一个256x256的屏幕空间Tile像素值是该Tile内可见实例的Bitmask。GPU在光栅化前先查这张图瞬间知道哪些实例连光栅化都不用进。这比CPU端逐个做AABB-Sphere测试快两个数量级。提示GPUScene的“场景”概念和World层级无关。一个World可以有多个GPUScene比如Editor Viewport和Game Viewport各自独立一个GPUScene也可以跨World复用如UI Overlay场景。它的生命周期由FGPUSceneInstanceManager管理而非UWorld。2.2 为什么必须取代旧方案CPU瓶颈的硬伤无法靠优化绕过UE4时代场景管理靠FPrimitiveSceneInfo链表TSetFPrimitiveSceneInfo*哈希集合。每次Frame开始CPU要干这些事遍历所有Actor调用GetActorBounds()获取AABB对每个Primitive执行ShouldIncludeInStaticMeshBatching()判断是否可合批调用GetDynamicMeshElements()生成DrawElement列表对每个DrawElement填充FMeshBatch结构体含材质、顶点缓冲区指针、实例数等最后把上千个FMeshBatch提交给RHI。这个流程的问题是它本质是O(N)串行算法且N是场景中所有Primitive总数而非可见数。哪怕你镜头只对着一堵墙CPU也得把整个地图的10万个草丛、5千棵树、200个建筑都过一遍。我在一个城市仿真项目里实测当场景Primitive数超8万仅第2步合批判断就吃掉12ms CPU时间占整帧RenderThread的35%。而GPU此时可能只跑了8ms——典型的CPU-bound。GPUScene的破局点在于把O(N)变成O(K)K是当前帧实际提交给GPU的实例数。它的更新策略是“增量式脏标记”Actor移动/旋转/缩放 → 标记对应Instance的bTransformDirty true材质参数修改 → 标记bMaterialDirty trueLOD切换 → 标记bLODDirty true每帧开始时GPU端Dispatch一个Compute Shader只处理所有b*Dirty true的Instance批量更新SceneInstanceData Buffer其余99%的Instance数据保持不动GPU直接复用上一帧Buffer。这就像银行不再每天打印所有客户账单而是只给当天有交易的客户发短信提醒。我们做过对比测试同一场景UE4.27 vs UE5.3CPU RenderThread耗时从28ms降到6.3ms下降77%。这不是代码优化的结果是数据范式的代际差异。2.3 它如何影响你写的每一行代码从蓝图到C的隐式耦合GPUScene的存在让很多你以为“很安全”的操作暗藏性能雷区。举三个真实案例案例1蓝图里频繁调用GetActorLocation()表面看只是读一个FVector但UE5.3中如果该Actor启用了bUseGPUScene默认开启GetActorLocation()会触发FGPUSceneInstance::GetWorldTransform()进而调用RHICopyToStagingBuffer()把GPUScene Buffer中对应Instance的变换矩阵拷回CPU内存。一次拷贝耗时0.02ms但如果你在Tick里每帧调用100次就是2ms纯等待。解决方案加缓存UPROPERTY(Transient) FVector CachedLocation;只在TransformChanged事件里更新。案例2C中手动修改Actor Transform// 危险会触发GPUScene全量重置 Actor-SetActorLocation(NewLoc); // 正确用底层API直接更新GPUScene if (Actor-GetSceneComponent()-IsRegistered()) { FGPUSceneInstanceHandle Handle Actor-GetSceneComponent()-GetGPUSceneInstanceHandle(); if (Handle.IsValid()) { FMatrix NewTransform FTransform(Rot, NewLoc, Scale).ToMatrixWithScale(); Scene-UpdateInstanceTransform(Handle, NewTransform); } }这段代码跳过了Actor系统的Transform广播链直接喂数据给GPUScene耗时从1.8ms降到0.05ms。案例3材质中使用ObjectPosition节点这个节点在GPUScene启用后不再读取CPU传入的ObjectToWorld常量寄存器而是从GPUScene Buffer中Load。这意味着如果你在材质里写了ObjectPosition * 1000GPU得先从显存Load 16字节再解压成完整矩阵再乘法——比直接读常量慢3倍。实测在1080p分辨率下一个含5个ObjectPosition的复杂材质Pixel Shader耗时增加1.2ms。优化方案把常用变换预计算成StaticParameter或用CustomExpression硬编码。这些不是Bug是GPUScene范式下的必然权衡它用GPU端的灵活性换来了CPU端的不可见性。你写的每一行代码都在和这块显存Buffer发生隐式IO。3. GPUScene核心细节与实操要点深度解析3.1 数据结构详解64字节Instance的每一个比特都经过精密设计我们来逐字节拆解SceneInstanceData中一个Instance的64字节布局。这不是学术考据而是为了让你在调试时能看懂RenderDoc抓取的Buffer内容字节偏移字段名类型说明实操意义0-15WorldTransformCompressedFMatrix44fCompressed压缩世界矩阵修改此区域可实现GPU端动画如顶点着色器驱动的飘动草丛无需CPU参与16-19ParentInstanceIndexuint32父实例索引0xFFFFFFF表示无父构建骨骼层级动画的基础UE的HierarchicalInstancedStaticMesh正是靠此字段实现父子实例联动20-21LODIndexuint16当前LOD等级在Custom Depth Pass中可据此动态调整描边粗细LOD0描边3pxLOD1描边1px22VisibilityFlagsuint8Bit0: 可见, Bit1: 遮挡, Bit2: 视锥内直接读取此字节可替代IsVisible()函数调用省去函数栈开销23-24MaterialIndexuint16材质槽位索引支持单个StaticMesh用不同材质实例化比传统Material Swap快10倍25-63CustomDatauint8[39]用户自定义数据这是TA的黄金字段可存UV偏移2字节、自发光强度1字节、风力系数1字节等重点说CustomData。很多团队以为这是留给引擎内部用的其实UE明确留出39字节供项目定制。我们在一个风电仿真项目中把风机叶片的实时转速float、桨距角float、故障码uint8全塞进去。顶点着色器里用RWByteAddressBuffer.Loadfloat(InstanceIndex * 64 25)直接读实现了每帧百万叶片的物理级旋转CPU零开销。注意CustomData的读写必须用RWByteAddressBuffer不能用StructuredBuffer。因为后者要求元素对齐会浪费大量空间。UE的FGPUSceneInstanceManager内部正是用RWByteAddressBuffer管理这块内存。3.2 更新机制实战何时该用UpdateInstance何时该用MarkInstanceDirtyGPUScene提供两套更新API选错一套性能直接打五折Scene-UpdateInstanceTransform(Handle, NewTransform)立即同步更新。适用于物理模拟、关键帧动画、VR手柄位置。但代价是每次调用触发一次GPU Compute Dispatch有固定调度开销约0.03ms。如果你每帧更新1000个Instance就是30ms纯调度时间。Scene-MarkInstanceTransformDirty(Handle)标记脏。适用于角色行走、车辆行驶、UI元素移动。优势是所有脏标记在帧末统一处理GPU只需一次Dispatch处理全部。实测更新1000个Instance耗时仅0.15ms。选择原则很简单“是否需要下一帧立刻生效”需要立刻生效如子弹击中瞬间的爆炸特效位置→ 用UpdateInstance只需视觉连续如角色移动轨迹→ 用MarkDirty。我们曾在一个FPS项目中犯过错误把玩家角色的每帧位置都用UpdateInstance推送导致VR模式下GPU调度队列堵塞HMD刷新率从90Hz掉到72Hz。改成MarkDirty后问题消失。3.3 内存管理与显存占用别让GPUScene吃光你的4GB显存GPUScene显存占用 Instance数 × 64字节 Primitive数 × 128字节 VisibilityBuffer固定约4MB。看似简单但有两个隐藏陷阱陷阱1Instance数 ≠ Actor数一个HierarchicalInstancedStaticMeshComponentHISM可能包含10万个Instance但它只算1个Primitive。而10万个StaticMeshActor就是10万个Primitive。前者显存占用100000×64 1×128 ≈ 6.4MB后者100000×64 100000×128 19.2MB。差3倍陷阱2VisibilityBuffer的Tile尺寸可调默认是256×256 Tile对应1080p屏幕需16×10160个Tile。但如果你项目是8K输出7680×4320默认配置需要256×25665536个TileVisibilityBuffer暴涨到256MB解决方案在DefaultEngine.ini中强制降低[/Script/Engine.RendererSettings] r.GPUScene.VisibilityTileSize128128×128 Tile在8K下只需1024×10241M个TileVisibilityBuffer回到4MB。我们有个客户项目显存报警说GPUScene占了3.2GB。用RenderDoc抓帧发现VisibilityBuffer占了2.8GB。原因就是忘了调VisibilityTileSize。改完后显存回落到412MB帧率提升11fps。3.4 调试与可视化如何亲眼看到GPUScene在工作光看文档不如亲眼所见。以下是我在项目中验证GPUScene状态的三板斧第一板斧RenderDoc抓取SceneInstanceData Buffer在游戏运行时按F5捕获一帧在Event Browser中找到GPUScene_UpdateInstances事件在Texture Viewer中右键SceneInstanceDataBuffer →View as Buffer设置Format为R32G32B32A32_FLOATStride16因为压缩矩阵是4个float滚动查看你会看到一列列数字——这就是每个Instance的世界矩阵压缩值。移动镜头再抓一帧对比同一Instance的数值变化立刻明白更新逻辑。第二板斧控制台命令实时监控在游戏内按~打开控制台输入stat gpu # 查看GPU总耗时 stat r.GPUScene # 查看GPUScene专项统计 # 输出示例 # GPUScene.Update: 0.12ms (128 instances) # GPUScene.Draw: 1.84ms (4232 instances drawn) # GPUScene.Memory: 124.5MBr.GPUScene命令会实时刷新比Profiler更轻量。第三板斧自定义Shader可视化剔除状态写一个极简PS读取SceneVisibilityBuffer// GPUSceneVisibilityVis.usf Texture2Duint VisibilityTex : register(t0); SamplerState VisibilitySampler : register(s0); float4 MainPS(float4 InPos : SV_POSITION) : SV_Target0 { uint2 TexCoord uint2(InPos.xy) / 256; // 转换为Tile坐标 uint VisMask VisibilityTex.SampleLevel(VisibilitySampler, TexCoord, 0).r; return VisMask 0 ? float4(0,1,0,1) : float4(1,0,0,1); // 绿可见Tile红不可见 }挂到全屏Quad上你就能看到屏幕被切成256×256的格子绿色格子代表该区域有实例可见。这比任何文字描述都直观。4. GPUScene实操全流程与关键环节实现4.1 从零构建一个GPUScene驱动的动态植被系统我们以“风中摇曳的麦田”为例展示如何绕过CPU全程在GPU端完成。这不是理论Demo而是已上线农业仿真项目的生产代码。Step 1准备数据源用Houdini生成10万株麦秆的顶点数据位置、高度、弯曲度导出为.abcMaya中创建单株麦秆模型确保UV展开合理导出FBX到UE在UE中将FBX拖入内容浏览器勾选Generate Lightmap UVs和One Convex Collision Per Mesh创建HierarchicalInstancedStaticMesh组件将麦秆StaticMesh赋给它。Step 2注入自定义数据到GPUScene在C中重写AGrassField::BeginPlay()void AGrassField::BeginPlay() { Super::BeginPlay(); // 获取HISM组件 UHierarchicalInstancedStaticMeshComponent* HISM CastUHierarchicalInstancedStaticMeshComponent(GetRootComponent()); if (!HISM || !HISM-GetStaticMesh()) return; // 预分配CustomData数组 TArrayFVector4 CustomDataArray; CustomDataArray.Reserve(100000); // 从Houdini数据中读取每株麦秆的风力参数 for (int32 i 0; i 100000; i) { FVector WindParams GetWindParamsFromHoudiniData(i); // 自定义函数 // 编码X风向角Y风速Z随机相位W高度 CustomDataArray.Add(FVector4(WindParams.X, WindParams.Y, WindParams.Z, WindParams.W)); } // 批量写入GPUScene CustomData HISM-SetCustomData(CustomDataArray); }SetCustomData是UE5.3新增API它把CustomDataArray直接映射到GPUScene Buffer的对应位置无需逐个Instance操作。Step 3编写GPU端动画Shader在麦秆材质中用Custom Expression节点写顶点动画// Custom Expression Code // Input: VertexPosition (ObjectSpace), CustomData (from GPUScene) // Output: AnimatedPosition (ObjectSpace) float4 CustomData GetCustomData(); // 自动读取Instance的CustomData[0-3] float WindAngle CustomData.x; float WindSpeed CustomData.y; float Phase CustomData.z; float Height CustomData.w; // 简单正弦波动画 float Time GetTime(); float Offset sin(Time * 2.0 Phase) * WindSpeed * 0.1; float3 AnimatedPos VertexPosition; AnimatedPos.x cos(WindAngle) * Offset; AnimatedPos.z sin(WindAngle) * Offset; AnimatedPos.y sin(VertexPosition.x * 10 Time * 3) * 0.02 * Height; return AnimatedPos;注意这里没有WorldPosition节点所有计算都在Object Space完成避免矩阵变换开销。Step 4性能验证启用GPUScene前10万麦秆帧率32fpsGPU时间18.2ms启用GPUScene后帧率58fpsGPU时间11.4msCPU RenderThread从14ms降到3.1ms关键指标Draw Call从102400降到1单次HISM DrawInstance Count显示423200含LOD实例。这套方案的核心价值在于美术在Houdini里调好风力参数程序员写20行C注入TA写30行HLSL动画全程无需动蓝图、无需Tick、无需CPU每帧计算。这才是GPUScene该有的样子。4.2 解决“UE 动画抖动”问题GPUScene与骨骼动画的协同方案热搜词“ue 动画抖动”在GPUScene语境下特指启用GPUScene后骨架网格体SkeletalMesh的蒙皮动画出现微小跳变。这不是Bug是数据同步时机问题。根本原因SkeletalMesh的骨骼变换矩阵由AnimInstance计算存在CPU端而GPUScene中存储的是Actor整体的世界矩阵。当角色奔跑时AnimInstance每帧更新骨骼但GPUScene的Instance矩阵只在Actor Transform变更时更新。两者不同步导致蒙皮顶点位置和Instance位置轻微错位在高速运动时被放大为抖动。解决方案分三层Layer 1强制同步Quick Fix在角色蓝图的Event Tick中添加// 每帧强制更新GPUScene Instance Transform GetMesh()-GetOwner()-ForceNetUpdate(); // 触发Transform Dirty但这只是掩盖问题CPU开销大。Layer 2GPU端骨骼矩阵缓存Production ReadyUE5.3提供了FSkeletalMeshInstanceData结构允许把骨骼矩阵数组直接上传到GPU。步骤在USkeletalMeshComponent::Tick()后调用GetSkeletalMeshObject()-GetSkinWeightBuffer()获取顶点权重用FRWBuffer分配显存将当前帧骨骼矩阵数组FMatrix[MAX_BONES]拷贝进去在蒙皮Shader中用RWBuffer.LoadFMatrix(BoneIndex)替代CPU传入的BoneMatrices常量数组。我们实测抖动完全消失GPU额外开销仅0.4ms用于矩阵拷贝远低于CPU每帧计算的1.2ms。Layer 3预测性同步Advanced对VR/AR等低延迟场景用FAnimInstanceProxy::PredictBoneTransform()预测下一帧骨骼提前写入GPUScene。这需要重写AnimInstance但可将抖动降低到人眼不可辨识级别0.05像素。4.3 “UE模型距离剔除”的GPUScene实现比传统方法快3倍传统距离剔除Distance Culling靠CPU每帧计算DistanceSquared再调用SetActorHiddenInGame()。问题10万个模型10万次平方根计算CPU爆表。GPUScene方案用VisibilityBuffer Compute Shader实现GPU端剔除。实现步骤在DefaultEngine.ini中启用r.GPUScene.DistanceCull1 r.GPUScene.DistanceCullMaxDistance10000创建自定义Compute ShaderDistanceCullCS.usf// 输入SceneInstanceData Buffer, Camera Position // 输出修改SceneInstanceData.VisibilityFlags.Bit0 [numthreads(64,1,1)] void Main(uint3 DTid : SV_DispatchThreadID) { uint InstanceIndex DTid.x; if (InstanceIndex NumInstances) return; float3 WorldPos LoadWorldPositionFromInstance(InstanceIndex); // 从压缩矩阵解压 float DistSq distanceSquared(WorldPos, CameraPos); bool bVisible DistSq MaxDistSq; // 原子操作更新VisibilityFlags InterlockedOr(VisibilityFlagsBuffer[InstanceIndex], bVisible ? 1 : 0); }在FSceneRenderer::Render()中在GPUScene_UpdateInstances后插入Dispatch。效果10万个模型的距离剔除GPU耗时0.8msCPU耗时几乎为0。而传统CPU方案需14ms。5. 常见问题与排查技巧实录5.1 GPUScene相关典型问题速查表问题现象可能原因排查命令/工具解决方案场景黑屏或大量模型不显示GPUScene Buffer分配失败显存不足stat r.GPUScene查看Memory值是否为0RenderDoc检查Buffer创建日志降低r.GPUScene.MaxInstances关闭Nanite检查显存泄漏模型闪烁、Z-Fighting严重GPUScene Instance Transform未及时更新与Depth Buffer不同步r.Shadow.MaxCSMResolution 1024临时降低阴影分辨率RenderDoc对比Depth与GPUScene Buffer在PostRenderOpaque后调用Scene-FlushGPUSceneUpdates()强制同步蓝图GetActorLocation()返回(0,0,0)Actor未注册到GPUScenebUseGPUScenefalseGetActor()-GetRootComponent()-IsRegistered()返回false检查Actor是否被Destroy()后未重建确认UWorld::bEnableGPUScene为trueVR模式下帧率骤降VisibilityBuffer Tile尺寸过大导致显存带宽瓶颈r.GPUScene.VisibilityTileSize值异常高强制设为128或64用r.GPUScene.VisualizeVisibility 1可视化验证自定义材质中ObjectPosition失效材质编译时未启用GPUScene路径材质Details面板中Usage→Used with GPUScene未勾选勾选后Recompile或在材质函数中加#ifdef GPUSCENE_ENABLED宏判断5.2 我踩过的三个深坑与独家避坑技巧坑1HISM的Instance Limit静默截断UE5.3中UHierarchicalInstancedStaticMeshComponent默认Instance上限是65536。超过部分会被静默丢弃且stat r.GPUScene不报错。我们一个森林场景放了8万棵树只显示6.5万棵排查三天才发现是这个Limit。✅避坑技巧在DefaultEngine.ini中显式设置[/Script/Engine.HierarchicalInstancedStaticMesh] MaxHISMInstanceCount200000同时在C中创建HISM时调用HISM-SetInstanceCount(MaxCount)预分配。坑2材质参数更新不触发GPUScene Dirty当你在蓝图中用Set Scalar Parameter Value修改材质参数GPUScene不会自动标记Instance为dirty。结果是材质变了但Instance的世界矩阵还是旧的导致遮挡计算错误。✅避坑技巧所有材质参数修改后手动标记Instance dirty// 获取材质所属的StaticMeshComponent UStaticMeshComponent* SMComp CastUStaticMeshComponent(MaterialOwner); if (SMComp SMComp-GetStaticMesh()) { for (int32 i 0; i SMComp-GetInstanceCount(); i) { FGPUSceneInstanceHandle Handle SMComp-GetGPUSceneInstanceHandle(i); if (Handle.IsValid()) Scene-MarkInstanceMaterialDirty(Handle); } }坑3Editor中GPUScene与Game Viewport不同步在编辑器里移动ActorGame Viewport中模型位置正确但Editor Viewport中错位。这是因为Editor Viewport有自己的GPUScene实例且更新策略不同步。✅避坑技巧开发阶段在EditorViewportClient.cpp中于Tick()末尾添加// 强制Editor Viewport GPUScene同步 if (GEditor GEditor-GetActiveViewport()) { FSceneInterface* EditorScene GEditor-GetActiveViewport()-GetScene(); if (EditorScene) EditorScene-FlushGPUSceneUpdates(); }一行代码解决无需重启编辑器。5.3 性能调优 checklist上线前必做的5件事检查r.GPUScene.MaxInstances设为场景最大Instance数的1.2倍避免运行时动态扩容有锁开销验证r.GPUScene.VisibilityTileSizePC项目设为256VR/AR项目设为1288K项目设为64禁用无用的GPUScene功能在DefaultEngine.ini中添加r.GPUScene.DistanceCull0 // 如不用距离剔除 r.GPUScene.OcclusionCull0 // 如不用硬件遮挡材质中清理ObjectPosition滥用用r.ShaderComplexity查看红色区域即高开销替换为WorldPosition或预计算常量用r.GPUScene.VisualizeVisibility 1截图存档上线前保存Visibility Buffer可视化图作为性能基线。最后分享一个小技巧在项目打包时GPUScene数据会自动序列化进Pak。但如果你用UnrealPak命令行打包记得加-compress参数否则GPUScene Buffer的压缩矩阵会被解压Pak体积暴增300%。我们一个12GB的Pak加了-compress后变成4.3GB——这省下的不是磁盘空间是玩家下载时的耐心。