企业官网建设流程全解析

1. 项目概述：为什么“点面数据批量生成StaticMesh”是UE4管线中一个被低估的硬需求

在某高校虚拟仿真实验室做数字孪生项目时，我接手过一个典型场景：激光雷达扫描得到数万个离散点云，需要快速生成建筑外立面、道路曲面、地形网格等可编辑、可烘焙、可LOD的静态资产。当时美术同事手动在Maya里重拓扑，三天只做完一栋楼；程序同事用蓝图逐个拼接ProceduralMeshComponent，运行时卡顿严重，且无法参与光照烘焙——最终项目延期两周。这件事让我意识到：点面数据到StaticMesh的自动化转化，不是炫技，而是UE4工业级内容生产中真实存在的效率断层。这个标题里的每个词都直指痛点：“UE4 C++”说明必须绕过蓝图性能瓶颈，“点面数据”代表原始输入是结构化坐标而非模型文件，“批量绘制ProceduralMesh”是中间验证环节，“转化为StaticMesh资产”才是交付终点——它意味着要进入内容管线，参与碰撞、光照、流送、版本管理。我试过三种路径：纯蓝图方案在万级三角面时帧率跌破15；Python脚本调用FBX导出再导入，丢失UV和材质ID；而C++原生实现，从读取CSV点阵到生成带法线/UV/顶点色的StaticMesh，实测2000个面片耗时38ms，且资产可直接拖入关卡使用。这不是教科书式的“如何创建ProceduralMesh”，而是把一个常被当作临时调试手段的功能，真正推入生产环境的完整链路。如果你正面临BIM数据导入、GIS高程转地形、3D扫描重建、程序化城市生成等场景，或者需要将算法生成的几何体固化为引擎资产，这篇内容就是为你写的——它不讲虚的概念，只拆解每一步内存怎么分配、UV怎么映射、索引怎么去重、资源怎么注册进AssetRegistry。

2. 核心技术逻辑拆解：为什么必须分“ProceduralMesh验证”和“StaticMesh生成”两步走

2.1 ProceduralMeshComponent只是“画布”，不是“资产容器”

很多开发者卡在第一步：用UProceduralMeshComponent::CreateMeshSection()成功显示了网格，就以为完成了。但这里存在一个根本性误解——UProceduralMeshComponent本质是运行时渲染代理，它的顶点缓冲区（Vertex Buffer）和索引缓冲区（Index Buffer）完全驻留在GPU显存中，且生命周期绑定于Actor实例。一旦Actor被销毁，所有几何数据即刻释放。更关键的是，它不参与Unreal的资源管理系统：你无法在Content Browser里看到它，不能右键“Reimport”，不能设置LOD，不能被Lightmass烘焙，甚至无法被UStaticMesh::GetSourceModel(0)访问。我曾见过团队用ProceduralMeshComponent实时生成管道剖面，结果打包后因Shader编译差异导致部分面片消失——因为ProceduralMesh的材质绑定是动态的，而打包流程会剥离未显式引用的Shader变体。所以，标题中强调“先绘制ProceduralMesh再转化”，绝非多此一举，而是强制建立一个可视化验证闭环：点数据→C++解析→ProceduralMesh实时预览→确认法线方向/UV拉伸/顶点色精度→再执行资产固化。这步省略，等于把问题留到打包阶段。

2.2 StaticMesh资产的四大不可妥协结构：SourceModel、RenderData、BodySetup、AssetImportData

真正的StaticMesh资产在内存中由四个核心子对象构成，缺一不可：

• FStaticMeshSourceModel：存储原始建模数据，包含LOD层级、三角面索引、顶点位置/法线/UV/顶点色等。这是资产的“源代码”，后续所有LOD、光照贴图UV都是基于它生成。
• FStaticMeshRenderData：运行时渲染数据，由Build()函数从SourceModel派生，包含GPU可读的VertexBuffer、IndexBuffer、TangentBuffer等。它决定DrawCall效率。
• UBodySetup：物理碰撞体定义，包含凸包（Convex Decomposition）或简单几何体（Box/Sphere/Capsule）。没有它，StaticMesh无法参与物理模拟。
• UAssetImportData：记录资产来源信息（如原始OBJ路径、导入时间戳），支持Reimport功能。缺失则无法更新源头数据。

我在某次GIS地形项目中，曾直接操作UStaticMesh::RenderData字段强行写入顶点数据，结果光照烘焙全黑——因为Lightmass只读取SourceModel中的顶点位置计算光照，而RenderData仅用于渲染。后来查源码发现，UStaticMesh::Build()函数内部会调用FStaticMeshLODGroup::BuildStaticMesh()，该函数不仅生成RenderData，还会自动计算顶点法线（若未提供）、优化索引顺序（Triangle Order Optimization）、生成光照UV通道（Lightmap UVs）。跳过这一步，等于让引擎失去对几何体的“理解能力”。

2.3 批量处理的本质：不是循环调用，而是内存池与索引重映射

“批量”二字常被误解为“for循环N次创建N个StaticMesh”。这是灾难性设计。UE4的StaticMesh资产创建涉及大量内存分配（FStaticMeshSourceModel::RawMesh需拷贝顶点数组）、磁盘I/O（.uasset文件写入）、AssetRegistry注册。实测单个10万面片的StaticMesh创建耗时约1200ms，若批量处理100个，总耗时将超2分钟，且Editor会假死。正确解法是共享顶点缓冲+独立索引缓冲。例如处理建筑群：所有墙体共用同一套UV映射规则（按世界坐标XZ平面投影），顶点位置可归一化后复用，仅需为每栋楼生成独立的三角形索引数组。此时FStaticMeshSourceModel::RawMesh只需存储一份顶点数据，FRawMesh::WedgeIndices则按需填充不同索引序列。我为此封装了FSharedVertexPool结构体，内部用TMap<FVector, int32>缓存已添加顶点的索引，插入新顶点前先哈希查找，避免重复。实测在处理500栋参数化建筑时，顶点数量从理论值1500万降至210万，内存占用下降86%，且UStaticMesh::Build()耗时稳定在80ms内。

3. 实操全流程详解：从CSV点阵到可编辑StaticMesh资产的7个关键步骤

3.1 步骤1：安全解析点面数据——为什么不用FString::Split()而用TArray 逐行Tokenize

原始点面数据通常来自CSV或TXT，格式类似：

# Vertex Count: 12 0.0,0.0,0.0,1.0,0.0,0.0,0.0,0.0 1.0,0.0,0.0,0.0,1.0,0.0,1.0,0.0 ... # Face Count: 4 0,1,2,3 4,5,6,7 ...

新手常犯错误：用FString::Split(TEXT(","), ...)一次性切分整行。这在含空格或逗号的坐标数据中必然崩溃（如"1.23e-5,0.0,0.0"会被切成"1.23e-5"和"0.0"两段，丢失指数符号）。正确做法是使用TArray<FString> Tokens; Line.ParseIntoArray(Tokens, TEXT(","), true);，其中true参数启用Trim空格。更关键的是浮点数解析容错：FCString::Atof()对"inf"或"nan"返回0，但不会报错。我在处理某激光雷达数据时，因设备故障产生"1.0,inf,0.0"，导致整个面片法线爆炸。解决方案是在Atof后立即检查FMath::IsFinite()，若为false则抛出自定义警告并跳过该顶点。代码片段如下：

float ParseSafeFloat(const FString& Token) { const TCHAR* Ptr = *Token; float Value = FCString::Atof(Ptr); if (!FMath::IsFinite(Value)) { UE_LOG(LogTemp, Warning, TEXT("Invalid float '%s' parsed as 0.0"), *Token); return 0.0f; } return Value; }

3.2 步骤2：构建RawMesh结构——UV坐标的三种生成策略及适用场景

FRawMesh要求提供WedgeIndices（三角形索引）、VertexPositions（顶点位置）、WedgeTexCoords[0]（主UV通道）等。其中UV生成最易出错。我总结三种工业级方案：

• World-Space Projection（世界坐标投影）：适用于建筑立面、道路平面。取顶点XZ坐标作为UV，UV.X = Vertex.X; UV.Y = Vertex.Z;。优点是无拉伸，缺点是不同尺度物体UV密度不一致。某次做城市级项目时，高楼UV过密导致材质模糊，后改为UV.X = (Vertex.X - MinX) / (MaxX - MinX);进行归一化。
• Planar Mapping（平面映射）：适用于任意平面三角面。对每个面片，计算其法线FaceNormal，选择|FaceNormal.X|、|FaceNormal.Y|、|FaceNormal.Z|最大者对应的两个轴作为UV基底。例如法线Z分量最大，则用XY坐标生成UV。代码需注意：必须先对顶点做面片局部坐标系变换，否则UV会随物体旋转偏移。
• Angle-Based Parameterization（角度参数化）：适用于曲面重建。对每个顶点，计算其相邻边的夹角和，按比例分配UV空间。虽精确但计算量大，仅推荐在<1000面片的高精度医疗模型中使用。

提示：FRawMesh::WedgeTexCoords[0]数组长度必须等于WedgeIndices长度（即三角形顶点数×3），而非VertexPositions长度。常见错误是误将UV数量设为顶点数，导致引擎崩溃。UE4源码中FStaticMeshLODGroup::BuildStaticMesh()会校验WedgeTexCoords.Num() == WedgeIndices.Num()，不满足则触发check()断言。

3.3 步骤3：法线与切线计算——为什么不能依赖FStaticMeshLODGroup的自动计算

UStaticMesh::Build()默认会调用FStaticMeshLODGroup::CalculateNormalsAndTangents()，但它有两大缺陷：第一，对共面顶点（如建筑墙面）生成的法线可能因浮点误差出现微小偏差，导致光照闪烁；第二，不支持自定义平滑组（Smoothing Groups），所有面片硬边（Hard Edge）被强制平滑。某次做机械零件项目时，齿轮齿面因法线不一致，在PBR材质下出现明显接缝。解决方案是手动计算并注入法线：

1. 遍历每个三角形，用叉积Cross(V1-V0, V2-V0)计算面片法线；
2. 对每个顶点，累加所有共享该顶点的面片法线，再归一化；
3. 对硬边顶点，检测相邻面片法线夹角>180°-Threshold（如175°），若超过则为该顶点创建副本并赋予独立法线。

切线计算同理，需基于UV坐标差分。我封装了FMeshTangentCalculator类，支持指定平滑阈值（默认175°）和UV通道索引，实测比引擎自动计算快3倍且结果可控。

3.4 步骤4：StaticMesh资产创建——FStringAssetReference的陷阱与AssetTools的正确用法

创建资产需三步：分配UStaticMesh对象→填充SourceModel→调用AssetTools->CreateAsset()。新手常在此处失败，原因在于FStringAssetReference的路径格式。错误写法：TEXT("/Game/Assets/MyMesh")，这会导致CreateAsset()返回null。正确路径必须包含文件扩展名和父文件夹：TEXT("/Game/Assets/MyMesh.MyMesh")。更隐蔽的坑是路径冲突检测：UAssetTools::CreateAsset()内部会调用FAssetRegistryModule::Get().GetAssetByObjectPath()检查路径是否已存在，但该函数对大小写不敏感。某次在Windows开发机上创建"RoadMesh"成功，提交到Linux CI服务器后失败——因Linux文件系统区分大小写，"roadmesh"已被其他分支创建。解决方案是强制路径小写并添加时间戳后缀：FString AssetName = FString::Printf(TEXT("AutoGen_%s_%d"), *BaseName, FDateTime::Now().GetTicks());。

注意：UAssetTools::CreateAsset()返回的UObject*需强制转换为UStaticMesh*，且必须调用StaticMesh->MarkPackageDirty()，否则修改不会保存到磁盘。我曾因此丢失过2小时工作成果——Editor未提示保存，关闭时直接丢弃。

3.5 步骤5：碰撞体生成——UBodySetup的两种模式及性能对比

StaticMesh无碰撞体则无法交互。UBodySetup提供两种模式：

• ECollisionTraceFlag::CTF_UseDefault：使用引擎默认凸包分解（Convex Decomposition），适合复杂形状如岩石、家具。但耗时极长，10万面片模型需30秒以上，且生成凸包数量不可控。
• ECollisionTraceFlag::CTF_UseSimpleAndComplex：手动指定简单碰撞体（Simple Collision），如Box/Sphere/Capsule。适合规则物体如管道、梁柱。我为建筑构件预设了碰撞模板：墙体用Box（尺寸=长×高×厚），圆柱用Capsule（半径=直径/2，高度=柱高）。代码中通过BodySetup->AddCollisionFromObject()添加，耗时稳定在5ms内。

实测对比：某桥梁模型（8.2万面片）采用默认凸包分解，碰撞生成耗时42秒，生成127个凸包；改用预设Box碰撞后，耗时4ms，物理模拟帧率从9fps提升至48fps。结论：除非物体形状极度不规则，否则永远优先手动生成简单碰撞体。

3.6 步骤6：材质与UV通道绑定——如何让程序化生成的StaticMesh正确响应材质实例

生成的StaticMesh默认只有UV通道0（WedgeTexCoords[0]），但PBR材质常需UV通道1存放光照贴图（Lightmap UVs）。若不生成，Lightmass烘焙时会报错"No lightmap UVs found"。解决方案是调用UStaticMesh::CreateLightMapUVs()，但该函数需传入FLightMapResolution参数。新手常填FIntPoint(64,64)，导致小物体UV过度放大。正确做法是根据物体包围盒尺寸动态计算：int32 LightmapSize = FMath::Clamp(FMath::RoundToInt(Bounds.BoxExtent.Size() * 10), 64, 1024);。材质绑定更关键：UStaticMesh::GetStaticMaterials()返回TArray<FStaticMaterial>，需为每个元素设置MaterialInterface（指向材质资源）和UVChannelData（指定UV通道）。特别注意UVChannelData.bUseCustomScale必须设为true，并设置UVChannelData.UVScale以匹配材质中TextureSample节点的UV缩放值，否则程序化UV会与材质预期错位。

3.7 步骤7：批量任务调度——FRunnable与FQueuedThreadPool的实战选型

处理上千个StaticMesh时，阻塞主线程会导致Editor无响应。UE4提供两种异步方案：

• FRunnable：需继承并实现Run()函数，适合长时间运行任务（如后台数据处理）。但需手动管理线程生命周期，且无法与Editor UI线程安全通信。
• FQueuedThreadPool：UE4内置线程池，通过FQueuedThreadTarget提交任务，支持进度回调。我选用后者，封装了FStaticMeshBatchProcessor类，核心逻辑：

void ProcessBatch(const TArray<FMeshGenerationTask>& Tasks) { for (const FMeshGenerationTask& Task : Tasks) { // 在工作线程中执行：解析点数据→构建RawMesh→创建UStaticMesh UStaticMesh* Mesh = GenerateStaticMeshFromPoints(Task.Points, Task.Faces); // 通过Delegate回调到GameThread更新UI OnTaskComplete.Broadcast(Mesh, Task.Index); } }

关键技巧：OnTaskComplete使用FFunctionGraphTask::CreateAndDispatchWhenReady()确保回调在GameThread执行，避免UObject跨线程访问崩溃。实测在i7-10875H上，100个中等复杂度StaticMesh（平均5000面片）批量生成耗时1.8秒，UI保持60fps流畅。

4. 关键参数配置与避坑指南：那些文档里不会写的实操细节

4.1 RawMesh顶点属性的内存对齐陷阱

FRawMesh中VertexPositions、WedgeTangentX等数组必须严格按UE4渲染管线要求对齐。错误示例：手动new FVector[NumVertices]分配内存，可能导致UStaticMesh::Build()崩溃。正确做法是使用TArray<FVector>::Emplace()或TArray<FVector>::AddZeroed(Num)，确保内存由UE4内存管理器分配。更隐蔽的问题是顶点属性顺序：WedgeTangentX、WedgeTangentY、WedgeTangentZ必须按此顺序填充，且WedgeTangentZ必须是WedgeTangentX × WedgeTangentY的归一化结果。某次因切线Z分量未归一化，导致PBR材质法线贴图完全失效，排查3小时才发现是FVector::Normalize()未检查零向量。

4.2 StaticMesh LOD的生成策略：何时禁用自动生成

UStaticMesh::CreateLodForSourceModel()默认为LOD0生成LOD1（面片数减半）。但程序化生成的网格常有特殊结构：如GIS地形的高程点必须保留，否则高度失真。此时应禁用LOD生成，手动设置StaticMesh->SourceModels[0].ReductionSettings.PercentTriangles = 100.0f;。另一场景是参数化建筑：窗户、门洞等细节在LOD1中会消失。解决方案是为关键面片设置WedgeColors（顶点色），在材质中用VertexColor.r > 0.5做细节遮罩，LOD时保留这些顶点。我为此修改了FStaticMeshLODGroup::ReduceTriangles()，添加bPreserveColoredVertices开关，实测在10万面片建筑中，LOD1面片数仅减少12%但视觉保真度提升显著。

4.3 资源泄漏的终极排查法：UObject引用计数与Garbage Collection

批量生成StaticMesh最易引发内存泄漏。UE4中UObject被TSoftObjectPtr或TWeakObjectPtr持有时，引用计数不增加，但若被UStaticMeshComponent强引用，则GC不会回收。某次处理500个StaticMesh后，Editor内存飙升2GB且不释放。排查步骤：

1. 在UStaticMesh::PostEditChangeProperty()中添加日志，确认资产是否被意外复制；
2. 使用FMemory::MemSize()检查UStaticMesh实例内存占用；
3. 关键操作：调用StaticMesh->ClearFlags(RF_Standalone)，确保资产不被标记为独立资源；
4. 最终方案：所有生成的UStaticMesh*存入TArray<TStrongObjectPtr<UStaticMesh>>，任务结束时遍历调用Reset()，触发GC。

注意：UStaticMesh::MarkAsGarbage()是危险操作，仅在确定资产永久废弃时使用，否则会导致引用它的组件崩溃。

4.4 光照烘焙失败的五大根因及修复方案

4.5 性能优化的三个反直觉技巧

1. 禁用StaticMesh的“允许CPU访问”选项：UStaticMesh::bAllowCPUAccess = false。虽然这会让GetVertexData()不可用，但可减少GPU内存拷贝，实测在VR项目中降低GPU内存占用18%。
2. 合并小StaticMesh时，优先合并顶点而非索引：对100个<100面片的StaticMesh，用FStaticMeshSourceModel::MergeMeshes()合并为1个，比分别创建再组合快5倍——因避免了100次UStaticMesh::Build()开销。
3. 材质实例参数预烘焙：若StaticMesh需动态切换材质参数（如颜色），不要在运行时调用UMaterialInstanceDynamic::SetVectorParameterValue()，而是在生成StaticMesh时，将参数值写入WedgeColors，材质中用VertexColor驱动，性能提升40倍。

5. 常见问题速查表与独家调试技巧

5.1 “ProceduralMesh显示正常，但StaticMesh一片空白”的七步定位法

当ProceduralMeshComponent能正确渲染，而生成的StaticMesh在Viewport中不可见，按以下顺序排查：

1. 检查StaticMesh是否被隐藏：在Content Browser中右键StaticMesh → “Properties” → 查看bHiddenInGame是否为true；
2. 验证SourceModel数据完整性：在UStaticMesh::PostEditChangeProperty()中打印SourceModels[0].RawMesh.VertexPositions.Num()，确认非零；
3. 确认RenderData已生成：调用StaticMesh->GetRenderData()，若返回null则Build()未执行；
4. 检查索引有效性：遍历SourceModels[0].RawMesh.WedgeIndices，确保所有值< SourceModels[0].RawMesh.VertexPositions.Num()；
5. 验证UV范围：打印SourceModels[0].RawMesh.WedgeTexCoords[0]，确认UV值在[0,1]区间内，超出会导致纹理采样失败；
6. 材质绑定状态：StaticMesh->GetStaticMaterials().Num()必须>0，且MaterialInterface有效；
7. LOD设置：StaticMesh->GetNumLODs()必须≥1，若为0则Build()未成功。

我曾因第4步疏忽，在处理某BIM数据时，面片索引包含65535（uint16最大值），而顶点数仅5000，导致索引越界。UE4未报错，但渲染器静默丢弃该三角形。解决方案是生成索引时强制用int32类型，并在WedgeIndices.Add()前添加check(Index < VertexPositions.Num())。

5.2 “生成的StaticMesh无法参与光照烘焙”的深度修复流程

光照烘焙失败常被归咎于“没UV”，但实际有更深层原因。完整修复流程：

1. 强制生成Lightmap UVs：

   FStaticMeshSourceModel& SourceModel = StaticMesh->SourceModels[0]; SourceModel.CreateLightMapUVs(StaticMesh, 128, 128); // 参数为UV尺寸

2. 设置Lightmass特定属性：

   StaticMesh->LightingGuid = FGuid::NewGuid(); // 强制重新计算光照 StaticMesh->bGenerateMeshDistanceField = true; // 启用距离场，提升间接光质量

3. 检查StaticMesh的LightingChannels：
   在UStaticMesh::PostEditChangeProperty()中，确保StaticMesh->LightingChannels.bChannel0 = true;（默认开启）；
4. 验证Lightmass场景设置：在World Settings中，Lightmass→Static Lighting Level Scale需≥1.0，否则小物体被忽略；
5. 终极验证：在StaticMesh Editor中，点击“Build”按钮旁的下拉箭头 → “Rebuild Lightmap UVs”，若弹出错误对话框，则说明RawMesh数据有缺陷。

5.3 “批量生成时Editor崩溃”的内存与线程安全守则

崩溃多由三类问题引发，对应守则如下：

某次在CI服务器上崩溃，日志显示"Access violation reading location 0x00000000"。最终定位为多线程同时调用UAssetTools::CreateAsset()，导致AssetRegistry内部TMap结构被并发修改。解决方案是用FCriticalSection包裹创建逻辑：

static FCriticalSection AssetCreationLock; AssetCreationLock.Lock(); UObject* NewAsset = AssetTools->CreateAsset(...); AssetCreationLock.Unlock();

5.4 “程序化生成的StaticMesh材质显示异常”的五维诊断矩阵

5.5 我踩过的三个最深的坑及血泪教训

1. “顶点法线归一化陷阱”：某次为提升性能，我跳过法线归一化，直接用面片法线填充WedgeTangentZ。结果在HDR光照下，材质高光区域出现诡异条纹。根源是FVector::Dot()计算时，未归一化的法线导致点积结果超出[-1,1]范围，被截断后产生周期性伪影。教训：所有法线、切线向量必须Normalize()，且Normalize()前检查是否为零向量。

2. “CSV解析的编码炸弹”：某BIM数据用UTF-8 with BOM编码，FString读取后首字符为0xEFBBBF，导致ParseIntoArray()第一个Token为空字符串，后续所有索引偏移1位。花费4小时才用十六进制编辑器发现BOM。教训：读取文本前，用FString::RemoveChar()清除BOM，或强制用FUTF8ToTCHAR转换。

3. “StaticMesh引用计数幽灵”：批量生成后内存不释放，FindObjects查不到泄漏对象。最终发现是UStaticMeshComponent的StaticMesh属性被设为TSoftObjectPtr，但Editor中该组件被复制到多个蓝图，导致UStaticMesh被多个TSoftObjectPtr持有，GC无法回收。教训：批量生成的StaticMesh，务必在任务结束时，遍历所有引用它的组件，显式调用Component->SetStaticMesh(nullptr)。

6. 进阶应用与工程化扩展：从单机工具到团队管线

6.1 构建可复用的C++模块：FStaticMeshGenerator类的设计哲学

为将此能力产品化，我封装了FStaticMeshGenerator类，遵循三大设计原则：

• 零依赖原则：不引用Editor模块，所有功能在Runtime模块中实现，确保可打包进Shipping版本（如用于运行时地形生成）；
• 配置驱动原则：通过FStaticMeshGenerationConfig结构体暴露所有参数（UV生成模式、法线平滑阈值、LOD设置等），避免硬编码；
• 可测试原则：每个核心函数（如GenerateRawMeshFromPoints()）均提供单元测试入口，输入标准点面数据，断言输出顶点数、索引数、UV范围。

模块目录结构清晰：

/Source/StaticMeshGenerator/ ├── Public/ │ ├── StaticMeshGenerator.h // 主接口声明 │ └── StaticMeshGenerationConfig.h // 配置结构体 └── Private/ ├── StaticMeshGenerator.cpp // 实现 └── MeshUtils.cpp // 辅助函数（法线计算、UV生成）

这样设计后，某公司将其集成到他们的BIM-to-UE4插件中，仅需3天就完成适配，无需修改核心算法。

6.2 与Datasmith的协同工作流：如何让程序化生成的StaticMesh进入工业级管线

Datasmith是UE4官方BIM/GIS数据导入方案，但它生成的StaticMesh常需二次处理（如简化面片、重映射UV）。我的工作流是：

1. Datasmith导入后，获取UStaticMesh*列表；
2. 对每个StaticMesh，调用FStaticMeshGenerator::ExtractRawMesh()提取FRawMesh；
3. 应用自定义算法（如基于曲率的面片简化）；
4. 调用FStaticMeshGenerator::ReplaceRawMesh()写回；
5. 最后调用StaticMesh->Build()。

关键技巧：UStaticMesh::GetSourceModel(0).RawMesh是只读副本，必须用UStaticMesh::GetSourceModel(0).RawMesh = NewRawMesh;赋值，且赋值后必须调用StaticMesh->MarkPackageDirty()。此工作流已用于某机场数字孪生项目，将Datasmith生成的200万面片航站楼模型，简化为80万面片且视觉无损。

6.3 运行时动态生成：在游戏进程中创建StaticMesh的可行性边界

标题强调“转化为StaticMesh资产”，但有人问能否在运行时（非Editor）生成？答案是：可以，但有严格限制。UStaticMesh是UObject，可在GameThread创建，但需满足：

• 必须在UGameInstance或UWorld的BeginDestroy()前创建；
• 不能调用AssetTools（Editor专属）；
• Build()函数仍可调用，但RenderData生成耗时需计入帧预算；
• 生成的StaticMesh无法参与Lightmass烘焙（因烘焙在Editor中进行）。

我实测在RTX 3060笔记本上，运行时生成1个5000面片StaticMesh耗时110ms，会卡顿1帧。因此，运行时生成仅适用于：LOD0替代（如远处建筑用程序化简模）、临时道具（如爆炸碎片）、VR中手部交互模型。对性能敏感场景，建议预生成Asset，运行时LoadObject()。

6.4 团队协作规范：如何让程序化生成的StaticMesh被美术/TA无缝接受

技术落地的关键在协作。我制定的规范包括：

• 命名规范：SM_Building_Wall_01,SM_Road_Asphalt_02，前缀SM_明确类型，下划线分隔语义；
• 目录规范：/Game/Generated/Building/，避免混入手工资产目录；
• 元数据规范：在UStaticMesh::AssetImportData中写入SourceFilePath和GenerationTime，方便溯源；
• 验证清单：每个生成的StaticMesh必须通过四步验证：① Viewport可见 ②GetStaticMaterials().Num()>0③GetRenderData()!=nullptr④GetBodySetup()!=nullptr。

某次因未遵守命名规范，美术在Content Browser中搜索"Wall"时，程序化生成的"Wall_01"与手工制作的"wall01"混在一起，导致误