使用 Reality Composer Pro 3 加速空间场景迭代

一句话判断

Reality Composer Pro 终于脱离 Xcode 变成独立应用，并补齐了 Prefab（原型）和真机实时预览，Apple 算是正式把它当正经 3D 引擎编辑器来做了。

这场 Session 讲了什么

以前用 Reality Composer Pro (RCP) 做个稍微复杂点的 visionOS 场景能把人逼疯。它死死绑在 Xcode 里，改个材质、调个灯光都要等 Xcode 编译，场景复用全靠手工拷贝，毫无工作流可言。

现在 RCP 3 变成了独立 App，直接去官网下载就能用。最爽的是加了 Live Preview（实时预览），改完直接推送到头显里看效果；加了 Prototypes（原型），也就是 Unity 里的 Prefab，改一个实例源，所有实例跟着变；还加了 Lightmaps（光照贴图）烘焙和内置的 AI 3D 生成助手。

这套更新对做 visionOS 沉浸式空间体验、复杂 3D 场景的开发者影响最大。如果你只是放个 3D 模型做个简单 AR，感知不强；但如果你在做类似游戏或大型虚拟展厅，这套工作流能帮你省下一半的等待时间。

值得深挖的点

Prototypes (原型) 与实例化系统

大型场景必然需要复用，比如森林里的树、村庄里的房子。以前在 RCP 里只能复制实体（Entity），改一个材质要改几百个节点。RCP 3 引入的 Prototypes 就是为了解决这个痛点，它和 Unity 的 Prefab 几乎一模一样。

Apple 在这里的设计选择非常聪明：采用了非破坏性的 Override（覆盖）机制。你可以把 Prototype 拖进场景变成 Instance（实例），然后修改实例的特定属性（比如颜色、位置），这不会破坏源 Prototype。如果不满意，右键 Reset（重置）就能恢复源值。你甚至可以把实例的修改 Propagate（传播）回源，批量更新所有实例。

和旧方案相比，这简直是降维打击。但实战中有个坑：在团队协作时，必须严格规范谁有权限修改源 Prototype。如果 someone 不小心把实例的奇葩修改反向传播回了源，会导致场景里所有同类实例瞬间发生不可预期的变化。

Live Preview (实时预览) 与 Lightmaps (光照贴图)

visionOS 的空间体验在 Mac 屏幕上看和戴在头显里看完全是两码事。以前必须走完整的 Build & Run 流程，现在 Live Preview 直接把编辑器画面推流到 Vision Pro。这牺牲了一定的运行时真实性（有些复杂的 SwiftUI 附件或系统权限在预览里跑不起来），但换取了极致的迭代速度，所见即所得。

为了让静态场景在头显里看起来更真实且不卡顿，RCP 3 加入了 Lightmaps。它可以烘焙 Indirect lighting（间接光照）、Ambient occlusion（环境遮挡）和 Beauty maps（美化贴图）。这其实就是用空间换时间，把昂贵的全局光照（GI）计算提前算好，贴在模型上。

坑在于动态与静态的穿帮。一旦你烘焙了 Lightmap，场景里的间接光就固定了。如果此时用户在场景里打了一个动态光源（比如手里拿的手电筒），动态光和烘焙贴图的交互可能会非常违和。你必须严格区分静态几何体和动态几何体，动态物体千万别参与 Lightmap 烘焙。

代码片段

1. 动态实例化 Prototype 并应用 Override

场景：在代码中动态生成 Prototype 实例，并修改其覆盖属性（如灯光颜色）。

// 从 Bundle 中加载名为 "MagicEffect" 的 Prototype
if let prototype = try? await Entity(named: "MagicEffect", in: realityKitContentBundle) {
    // 克隆实例，recursive 必须为 true 以保留子实体结构
    let instance = prototype.clone(recursive: true)
    
    // 修改实例的点光源组件，这属于 Override，不会影响源 Prototype
    if var light = instance.components[PointLightComponent.self] {
        light.color = .blue
        light.intensity = 5000
        instance.components.set(light)
    }
    
    root.addChild(instance)
}

坑：clone 出来的实体如果修改了特定组件，记得检查是否破坏了 Prototype 的引用关系。在 RCP 编辑器里重置 Override 很容易，但在代码里手动 Override 后，想恢复源值需要重新读取原始组件数据。

2. 为实体挂载 Compute Graph 启动 GPU 模拟

场景：在代码中为实体添加 Compute Simulation 组件，以运行在 RCP 中创建的 GPU 计算图。

// 假设你在 RCP 中创建了一个名为 "MagicGraph" 的 Compute Graph
var simComponent = ComputeSimulationComponent()
simComponent.graphName = "MagicGraph" 

// 将组件挂载到目标实体上
entity.components.set(simComponent)

// 启动模拟（通常在 RCP 的 Simulation 标签页中自动处理，代码中需确保场景已激活）

坑：Compute Graph 只在模拟阶段（Simulation phase）运行。如果你在代码的 update 循环里手动修改了被 Compute Graph 接管的属性（比如粒子位置），两者会产生冲突，导致画面闪烁或物理计算崩溃。

最佳实践

老项目迁移时，第一步是把 Xcode 里的 RCP 包剥离出来，用独立版 RCP 3 打开。花半天时间把场景里重复的实体（如树木、道具、灯光组）全部转为 Prototype，这会让你的场景层级（Hierarchy）清爽 80%。

新项目建议第一天就建好 Prototype 库。对于不需要动态光影的静态场景（如建筑外壳、固定家具），无脑上 Lightmaps，把 Indirect 和 AO 烘焙出来，能大幅降低 Vision Pro 的 GPU 负载，防止设备发热降频。

Live Preview 虽然快，但涉及复杂 SwiftUI 附件、手势识别或特定系统权限（如空间音频、透视遮挡）的功能，还是得老老实实 Build & Run 到真机测试。另外，AI 助手生成的 3D 模型拓扑通常很烂，只能做白盒占位，千万别直接放进最终发布包。

还有什么值得关注

独立应用下载：RCP 3 不再捆绑 Xcode，非开发者（如 3D 美术、技术美术）现在可以直接去 developer.apple.com 下载并使用，打破了职能壁垒。
Compute Graph 可视化：让 GPU 编程对所有人都可访问，不用写 Metal 代码，通过节点连线就能搞定复杂的粒子系统和流体模拟。
内置 AI 助手：可以直接用自然语言在编辑器里生成 3D 物体和材质，虽然精度有限，但在早期原型设计阶段用来填补场景空白非常顺手。