使用 Reality Composer Pro 3 加速你的空间工作流程

一句话判断

这场 Session 最值得关注的一件事是：Reality Composer Pro 3 (RCP3) 终于把 visionOS 的场景搭建从“程序员手搓代码”变成了“TA（技术美术）和设计师能直接上手的节点连线游戏”。以前做个 NPC 巡逻或者复杂粒子，得在 Xcode 里写一堆 Swift 和 RealityKit API，改个参数就要重新编译；现在直接在 RCP3 里连节点就能搞定，这对开发效率的提升是降维打击级别的。

这场 Session 讲了什么

visionOS 刚出那会儿，RCP 充其量只是个高级模型查看器。稍微复杂点的动画混合、交互逻辑、粒子系统，全得在 Xcode 里硬写，迭代极其痛苦，美术和策划只能干瞪眼。

RCP3 直接把 Animation Graph（动画图）、Behavior Tree（行为树）、Script Graph（脚本图）、Navigation Mesh（导航网格）和 Compute Graph（计算图）全塞进了编辑器。这意味着你可以像用 Unreal Engine 蓝图一样，在 Mac 上连节点搞定状态机、NPC 巡逻逻辑、点击事件和 GPU 粒子，戴上 Vision Pro 用 Live Preview（实时预览）秒看结果。

这对有 TA 团队的公司和独立开发者影响最大。策划和美术可以直接在编辑器里闭环 80% 的视觉和基础交互，程序员只需要最后写点胶水代码把场景嵌进 App，彻底解放了生产力。

值得深挖的点

Behavior Tree（行为树）与 Script Graph（脚本图）的无缝联动

Apple 在 RCP3 里内置 Behavior Tree（行为树）而不是简单的 Timeline（时间线），说明他们真懂了空间计算场景的痛点。空间场景不是线性播放的电影，NPC 需要自主决策。行为树里的 Sequence（顺序）、Selector（选择）和 Parallel（并行）节点是游戏工业界做 AI 的标准答案。

结合 Script Graph 的事件驱动（比如 On Tap 节点），你能在编辑器里实现“用户点击 -> 修改参数 -> 行为树条件触发 -> 动画图切换”的完整闭环。这种设计把逻辑和表现层彻底解耦了。不过坑也很明显：节点一多，RCP 的 UI 连线会变成蜘蛛网，而且可视化调试绝对不如 Xcode 打断点看变量直观，复杂逻辑还是得靠程序员接管。

Compute Graph（计算图）接管 GPU 粒子

以前 RealityKit 的 Particle Emitter（粒子发射器）比较基础，想做 3A 级 VFX 只能靠 Shader 硬写或者外部烘焙。现在 Compute Graph 直接暴露了 Metal 算力，把粒子生命周期拆成 Emitter（发射）、Initialize（初始化）、Simulate（模拟）和 Output（输出）四个阶段。

这让 RCP 具备了做高端视觉特效的能力，比如大锅冒烟这种带自定义碰撞和颜色渐变的粒子。Trade-off 是学习曲线极其陡峭。不懂 GPU 并行计算和生命周期管理的人，连出来的节点可能直接让 Vision Pro 掉帧甚至发热降频。它给了你上限，但也把搞崩性能的风险交给了你。

代码片段

虽然 RCP3 主打无代码，但最终还是要和 Swift 业务逻辑对接。这里给两个最实用的对接示例。

1. 在 Swift 中动态修改 Behavior Tree 参数

场景：用户在 App 里点了个 UI 按钮，需要通知 RCP 里的炼金师 NPC 停止当前动作，去干别的事。

import RealityKit

// 假设在 RCP 中，你给 NPC 挂了一个自定义 Component 来暴露 Behavior Tree 参数
struct AlchemistStateComponent: Component {
    var isWalking: Bool = false
    var readyToBrew: Bool = false
}

func triggerBrewing(for npcEntity: Entity) {
    // 获取 RCP 暴露的自定义组件
    guard var state = npcEntity.components[AlchemistStateComponent.self] else {
        return
    }
    
    // 修改参数，Script Graph 或 Behavior Tree 会在下一帧自动读取这个变化
    state.readyToBrew = true
    state.isWalking = true
    
    // 写回组件
    npcEntity.components.set(state)
}

坑：RCP 里的 Input 参数名必须和 Swift 里的 Component 属性名严格对应，拼错一个字母在运行时不会报错，只会静默失效。

2. 代码控制 Animation Graph 的 State Machine

场景：不用 Behavior Tree，纯靠代码驱动 RCP 里做好的 Animation Graph 状态机。

import RealityKit

func updateAnimationState(for entity: Entity, isMoving: Bool) {
    // 更稳妥的做法：通过 RCP 暴露的 Custom Component 传递状态给 Animation Graph
    if var animState = entity.components[AnimationStateComponent.self] {
        // 这个属性会直接映射到 RCP Animation Graph 里的 isWalking Input 节点
        animState.isWalking = isMoving
        entity.components.set(animState)
    }
}

坑：RealityKit 原生的 AnimationPlaybackController 只能控制简单的 Clip 播放，对于 RCP3 里复杂的 State Machine（状态机）和 Blend Space（混合空间），必须通过自定义 Component 把参数传进 RCP 的 Input 节点，别试图在代码里硬算混合权重。

最佳实践

老项目别急着全推翻。把最耗时的粒子特效（迁移到 Compute Graph）和复杂材质（迁移到 Shader Graph）先搬进 RCP3，原有的 Swift 交互逻辑可以保留，通过 Component 桥接。

新项目强制要求 TA 或美术在 RCP 里闭环 80% 的视觉效果和基础交互。程序员只写业务数据流和核心玩法，把“调参数看效果”的循环从 Xcode 编译转移到 RCP 的 Live Preview 里。

实战中最容易踩的坑是过度依赖 Mac 上的预览。Compute Graph 和复杂的 Shader Graph 在 Mac 上跑得很欢，一上 Vision Pro 真机就可能因为算力瓶颈导致掉帧。一定要频繁戴上头显看真实的性能和发热情况。

还有什么值得关注

Shader Graph 新增 RealityKit PBR Surface 2：支持了 sheen（光泽）和 subsurface scattering（次表面散射），做皮肤和布料材质终于不用靠假反射糊弄了。
Hair Surface shader：专门针对毛发 strand lighting（发丝光照）优化的着色器，做虚拟人 avatar 的质感提升巨大。
Portal-rendering support：原生支持传送门渲染，做空间穿透和“窗户”效果有了官方节点，不用自己手写 stencil buffer 了。