项目背景：一个被老板拍脑袋定下来的需求
事情要从去年秋天说起。我们工作室接了一个智慧城市的可视化项目，甲方要求在一台移动端平板上流畅展示整个CBD区域，包括每一栋楼的每一扇窗户、每一棵树、每一盏路灯。当时我们天真地以为，只要把模型做精、贴图画好，再用UE5的Nanite一压，就万事大吉了。结果第一版demo跑起来，帧率直接掉到个位数，GPU的负裁曲线比过山车还刺激。老板在会议室里当着甲方的面，脸绿得跟场景里的草地一样。
复盘下来，问题出在“大量重复物体”上。CBD区域里有几千栋楼、几万棵树、十几万扇窗户，每个都是独立的Static Mesh Actor，每个都有自己的Transform、自己的Draw Call。哪怕模型面数不高，Draw Call一多，CPU就跪了，GPU反而闲得发慌。这就是典型的“CPU-bound”瓶颈。我们需要的是一把能把这些成千上万的实例捏合成一次绘制的“瑞士军刀”——于是，ISM（Instanced Static Mesh）登场了。
技术选型：为什么是ISM，而不是Nanite或HISM？
当时团队里有人提议用Nanite，毕竟UE5主打卖点，但Nanite在移动端支持有限，而且它擅长的是高模细节，对“大量重复低模”的场景并不友好。还有人提议用HISM（Hierarchical Instanced Static Mesh），也就是带层级结构的实例化网格，它确实支持视锥裁剪和LOD，但它的实例数据存在一个巨大的Buffer里，更新单个实例需要重建整个Buffer，对于需要动态变化的场景（比如灯光的开关、车辆的移动）会非常痛苦。
ISM（Instanced Static Mesh）则是最直接的方案：它把同一份Static Mesh的多个实例，合并成一次Draw Call。每个实例只存一个Transform（位置、旋转、缩放），GPU在渲染时通过Instance ID来区分每个实例。这意味着，无论你有1000个还是10000个实例，只要它们的Mesh和材质相同，Draw Call数都是1。
技巧提示：ISM和HISM的选择，关键看两点：一是实例数量是否巨大（几万以上选HISM），二是是否需要频繁修改单个实例（需要则选ISM，配合Custom Primitive Data）。
我们最终选了ISM，因为我们的场景里，楼宇和树木虽然多，但大多是静态的，而且我们后续要做的交互是“点击高亮”，这需要快速修改单个实例的颜色，ISM的Custom Primitive Data正好能派上用场。
踩坑实录：那些年我们踩过的ISM大坑
坑1：Transform矩阵的坑——你以为的旋转，不是你以为的旋转
ISM的实例Transform是FTransform类型，它包含位置、旋转（四元数）、缩放。我们最初用MakeTransform节点去拼接，结果发现旋转用的是欧拉角，而ISM内部存储的是四元数，转换不对就会出现“万向锁”式的诡异旋转。后来我们统一用SplitStructPin和MakeTransform，并且严格使用Quat，才解决了问题。
// 蓝图示例：创建ISM组件并添加实例
UInstancedStaticMeshComponent* ISMComp = NewObject<UInstancedStaticMeshComponent>(ThisActor);
ISMComp->SetStaticMesh(MyMesh);
ISMComp->RegisterComponent();
for (int i = 0; i < 1000; i++) {
FTransform T;
T.SetLocation(FVector(RandomX, RandomY, RandomZ));
T.SetRotation(FQuat(FRotator(0, RandomYaw, 0)));
T.SetScale3D(FVector(1.0f));
ISMComp->AddInstance(T, true);
}坑2：材质里的World Position Offset——一改全局崩
我们为了让树木有风吹动的效果，在材质里加了World Position Offset（WPO）。结果一运行，所有实例的WPO都叠加到了同一个位置——因为ISM的每个实例虽然共享材质，但WPO的偏移量是相对于实例原点的，而实例的Transform在GPU上是以Instance Buffer传入的，材质里必须用PerInstanceCustomData或InstanceLocalPosition来获取当前实例的位置，否则所有实例都会朝同一个方向飘。后来我们用了一个技巧：在材质里用GetPerInstanceRandom配合时间偏移，实现了每个实例独立的风吹效果，但代价是无法使用静态光照烘焙，只能走动态光照。
坑3：碰撞检测——你以为的精准，其实是“盒体”
ISM的碰撞默认是“Use Complex Collision as Simple”，也就是每个实例都用复杂碰撞，这会导致性能爆炸。我们一开始没注意，结果点击高亮时，帧率骤降。后来我们改为“Use Simple Collision as Complex”，并且把碰撞体简化成盒体或球体，帧率立刻回升。但注意，这样做的代价是物理穿透会不精准，对于需要精确拾取的场景，建议用MultiTraceByChannel配合PerInstanceHitResult来手动处理。
实战方案：从“卡成PPT”到“千人同屏”的优化之路
确定了ISM方案后，我们开始重构场景。首先，把所有重复的树木、路灯、长椅、窗户替换成ISM组件。我们写了一个Python脚本，扫描关卡里的所有Static Mesh Actor，按Mesh和Material分组，然后为每组生成一个ISM组件，并批量添加实例。
但光有ISM还不够，我们还需要处理两个问题：一是内存占用，几万个实例的Transform数据要占不少内存；二是LOD，虽然ISM支持LOD，但默认情况下每个实例都使用最高LOD。我们给树木和建筑设置了远景LOD，并开启了LOD Distance Scaling，让远处的实例自动降低面数。
此外，我们还用到了Cull Distance Volume（剔除距离体积），把超出一定距离的实例直接剔除，进一步减少渲染压力。最终，我们把整个CBD场景的Draw Call从原来的2万+降到了不到500，帧率从8FPS提升到了60FPS（在PC上），在移动端也能稳定在30FPS。
数据驱动的实例管理：用DataTable控制一切
为了让非程序同事也能方便地调整场景，我们做了一个数据驱动方案：用DataTable存储每个实例的类型、位置、旋转、缩放、颜色等信息，然后通过蓝图批量生成ISM。这样，美术同学只需要在Excel里改数据，就能重新布局整个城市。
// 结构体示例：FInstanceData
USTRUCT(BlueprintType)
struct FInstanceData {
GENERATED_BODY()
UPROPERTY() FVector Location;
UPROPERTY() FRotator Rotation;
UPROPERTY() FVector Scale;
UPROPERTY() FLinearColor Color;
};我们还利用ISM的Custom Primitive Data（每个实例最多可存4个float），把颜色、随机种子等信息塞进去。在材质里通过PerInstanceCustomData节点读取，实现了每个实例的独立颜色和随机变化，而这一切都不需要额外的Draw Call。
交付效果：从“被甲方嫌弃”到“被甲方吹爆”
最终，我们交付的版本在平板上流畅运行，甲方领导戴上VR头盔，在虚拟CBD里“飞行”了一圈，兴奋得当场拍板追加预算。我们后来还把这套方案扩展到了整个城市的数字孪生项目，用ISM管理了几十万个建筑部件和市政设施，效果依然能打。
复盘整个项目，我最大的感触是：技术选型不能跟风，要理解底层原理。Nanite虽好，但不是万金油；ISM虽老，但用对了地方，依然是性能利器。
注意事项：ISM并非没有缺点：一是无法单独剔除实例（除非用HISM），二是无法单独接收阴影（除非用Virtual Shadow Map），三是实例数量过多时，实例Buffer会占用大量内存。所以，合理规划实例数量，配合LOD和Cull Distance，才是王道。
结语：给后来者的三点建议
- 先分析瓶颈，再选技术。用Profile工具（如Unreal Insights）查看CPU/GPU耗时，确定是Draw Call限制还是渲染像素限制。
- ISM+HISM组合使用。场景中动静分离：静态物体用HISM（方便LOD和裁剪），动态物体用ISM（方便更新），两者互补。
- 数据驱动是王道。把实例数据放到DataTable或CSV里，用蓝图或Python批量生成，后期调整成本极低。
希望这篇复盘能帮你少走一些弯路。记住，技术没有绝对的优劣，只有适合不适合。ISM这剂“老药”，在合适的场景下，依然是特效救心丸。
评论(0)