UE5 建筑可视化全流程：从 BIM 数据到 VR 交互的工程决策链

建筑可视化项目失败的原因，很少是“画面不够好看”。更常见的场景是：模型导入后层级结构崩坏，动画相机与交互逻辑争夺控制权，VR 帧率在头显里掉到 45fps 以下引发眩晕。这三类问题共享同一个根源——把全流程当成线性的“导入→做动画→加交互→打包”，而不是一条前后耦合的决策链。Datasmith 的合并策略决定了后续蓝图可操作的粒度，Sequencer 的相机设计决定了交互入口如何切换，VR 的渲染路径又反过来约束了前两步能用的技术选型。沿这条链走一遍，每一步的代码都对应一个需要在当下锁定的工程约束。

Datasmith 导入：合并策略是整条链的“宪法”

建筑模型导入 UE5 的第一步不是点 Import，而是决定在导出阶段合并到什么层级。Navisworks 的 Datasmith 导出中，“合并最后 N 个对象”参数直接控制层级深度：0 保留全部螺栓、螺丝级细节，导入后蓝图要操作一堵墙可能需要遍历上百个 Actor；3 将对象合并到三层深度，层级干净，但会丢失细粒度的构件标识。这个选择没有“正确值”，只有与后续交互粒度匹配的决策：如果项目需要“点击单扇门”，合并层级必须允许门作为独立 Actor 存在；如果只需要“整层楼显示/隐藏”，合并到楼层级反而更高效。

导入时还应关闭 Datasmith 自带的灯光、相机和动画，只保留几何体、材质和纹理，避免建筑数据中的冗余资产污染场景。Datasmith 会保留 BIM 的元数据，这为后续按“构件类型”或“楼层”做程序化筛选提供了数据基础，但前提是导入时没有因为过度合并而丢失这些字段。

# UE5 Python：导入后按 Actor 名称中的楼层标记做程序化分组
import unreal

def group_by_floor(actor_folder="/Game/ArchViz/Actors"):
    actors = unreal.EditorLevelLibrary.get_all_level_actors()
    for a in actors:
        label = a.get_actor_label()
        for floor in ["B1", "F1", "F2", "F3"]:
            if floor in label:
                a.set_folder_path(unreal.Name(f"ArchViz/{floor}"))
                break

group_by_floor()

分组本身不产生视觉价值，但它把“楼层抽离”这类交互从逐个指定 Actor 变成了对文件夹的集合操作，后续蓝图的输入参数从“一个 Actor 数组”降维为“一个文件夹路径”。

Sequencer 动画：相机是“可被交互接管的轨道”

建筑动画的核心决策不是关键帧打得多细，而是相机在 Sequencer 中的存在方式。Spawned Camera 由 Sequencer 在播放时生成，适合纯过场动画；Possessable Camera 在关卡中持久存在，可以被蓝图 Possess、被交互逻辑切换。VR 和交互式漫游必须选择 Possessable，否则玩家无法在动画结束后接管视角。

Cine Camera Actor 的 Filmback 和 Focus Settings 应作为动画的一部分被关键帧化，而不是在蓝图里硬编码。景深和焦距的过渡本身是建筑叙事的语言：从广角客厅推到长焦装饰细节，视觉引导的效果远强于单纯移动相机位置。蓝图播放序列时，用 Play 节点绑定 On Finished 委托，在动画结束时把控制权交还给玩家 Pawn，是“过场→交互”切换的最小可靠模式：

// C++：在动画结束时将控制权移交玩家
void AArchVizDirector::PlayWalkthrough(ULevelSequence* Seq)
{
    FMovieSceneSequencePlaybackSettings Settings;
    Settings.bAutoPlay = false;
    ULevelSequencePlayer* Player = ULevelSequencePlayer::CreateLevelSequencePlayer(
        GetWorld(), Seq, Settings, SequenceActor);

    Player->OnFinished.AddDynamic(this, &AArchVizDirector::OnWalkthroughFinished);
    Player->Play();
}

void AArchVizDirector::OnWalkthroughFinished()
{
    APlayerController* PC = GetWorld()->GetFirstPlayerController();
    PC->Possess(PlayerPawn);   // 相机控制权从 Sequencer 交回玩家
    OnWalkthroughCompleted.Broadcast();
}

OnFinished 的绑定顺序必须在 Play() 之前，否则序列极短时可能在委托注册前就已播完，控制权永远回不到玩家手里。

蓝图交互：触发器决定“意图”，Timeline 决定“手感”

建筑交互的三件套——开门、开关灯、换材质——在工程上是同一个模式：触发器捕获意图，Timeline 驱动过渡，动态材质实例执行结果。点击适合“有意图的操作”（打开这扇门、切换这个材质），重叠触发适合“空间自动响应”（走近入口门自动滑开）。两者不是互斥的，常见做法是自动门用重叠，材质切换用点击，因为后者需要客户主动比较不同选项。

材质切换最常见的错误是直接改 Set Material 而不是用 Create Dynamic Material Instance。直接替换材质资产会丢失该实例上的参数化差异（不同房间的同一父材质可能有不同的标量参数），正确的模式是运行时创建 MID，只改需要变的参数：

// 点击材质样本后，在目标网格体上创建 MID 并设置参数
void AFinishSwitcher::ApplyFinish(UMeshComponent* Target, UMaterialInterface* ParentMat, FName Param, float Value)
{
    UMaterialInstanceDynamic* MID = Target->CreateDynamicMaterialInstance(0, ParentMat);
    if (MID)
    {
        MID->SetScalarParameterValue(Param, Value);
        Target->SetMaterial(0, MID);
    }
}

Timeline 的作用是让“变化”有物理感。门从 0° 到 90° 如果用 Set Relative Rotation 一帧完成，观感是“瞬移”；Timeline 配合 Lerp (Rotator) 在 0.6–0.8 秒内插值，才产生“门被推开”的重量感。Timeline 的 Finished 引脚还承担着状态复位或触发下一步交互的责任，把它当成一个显式的状态机边沿，而不是单纯的动画曲线。

VR：渲染路径的约束反向决定前两步的选型

VR 是整条链上约束最硬的一环，因为它把“帧率”从画质问题变成了生理问题。Epic 的 XR 最佳实践给出的项目设置是确定的：Forward Shading、MSAA、Instanced Stereo、vr.PixelDensity=1、关闭 r.SeparateTranslucency 和 r.HZBOcclusion。这些不是可选的“优化建议”，而是 VR 项目的准入配置。如果前两步用了大量依赖延迟渲染的半透明材质或复杂后处理，到这里就必须回退重做。

像素流式 VR 进一步引入了额外的约束。Pixel Streaming 与 OpenXR 冲突，启用流式 VR 时必须禁用 OpenXR，并且 VR 模板中的 TryTeleport 函数存在 Z 轴偏移，需要手动加 100 修正传送落点。更关键的一条工程判断来自流式服务商的文档：VR 像素流目前仍处于实验阶段，输入映射、头显追踪抖动和编解码帧率稳定性均未达到生产级，只适合原型和内部演示，不应作为面向消费者的交付形态。这意味着“VR 走像素流让客户用浏览器体验”在 2026 年仍是一个需要向客户明确标注风险的技术选择，而不是默认的部署方案。原生 OpenXR 构建 + 本地头显运行，仍然是建筑 VR 交付的可靠基线。

全流程的收敛点：每一步的输出是下一步的约束

Datasmith 的合并粒度决定蓝图能操作什么，Sequencer 的相机类型决定交互如何接管，蓝图的材质策略决定 VR 渲染路径是否可行，VR 的帧预算反过来否定过度依赖后处理的视觉方案。这条链上不存在“先做完再优化”的余地——VR 的 90fps 目标必须在 Datasmith 导入时就被当作几何复杂度的上限来对待，而不是等到头显里掉帧才回头删模型。全流程的专业性，体现在每一步的代码选择都预先承认了后续环节的约束。