# 从 VRChat 地图到浏览器三维舞台，线上数字演出空间该怎么继续做

> 研究报告
> 状态：ongoing working paper

## 一、为什么 `Balloon Live Space` 需要一篇研究报告

`太空气球 / Balloon Live Space` 不能只靠活动海报和几条日历节点来解释。

如果不把它的技术路线、历史背景和当前判断写清楚，这条线会一直被误解成两种东西之一：

- 一个“想象中很大”的未来虚拟场馆
- 一个临时做出来的网页直播间

这两个理解都不准确。

它真正要处理的问题是：在今天这个技术条件下，我们到底应该怎样搭一条**线上数字舞台**，既保留空间感和现场感，又不把第一次进入的人卡死在客户端、账号和环境配置上。

这份报告就是为这个问题写的。

## 二、这条线自己的历史起点

`Balloon Live Space` 的早期想法可以追到 `2022` 年。

当时比较自然的想象，是做一个能在 `VRChat` 里进入的演出空间。那时很多人对“在线上看 live set”最直接的期待，就是进入一个完整的虚拟场景，拥有自己的虚拟形象，跟其他人站在同一个空间里听、看、移动、聊天。

这个想法到今天也没有过时。它甚至仍然有一种很强的吸引力，因为它真正解决的是“线上活动为什么通常没有现场感”的问题。

但当我们把这个方向往实际公开路径上推时，很快就遇到了一组更硬的现实条件：

- 不是每个观众都愿意先下载完整客户端
- 不是每个观众都熟悉虚拟形象和世界进入流程
- 如果一场活动的第一步是安装和配置，那很多人会在看见作品之前就离开

所以 `Balloon Live Space` 后来的转向，不是背叛原本的空间理想，而是一次更诚实的路线收缩：

- 先把入口压轻
- 先让浏览器里的三维舞台成立
- 先把 live set、实时视觉和观看链路跑通
- 再决定要不要把更重的社交和场景交互层重新接回来

## 三、为什么 `VRChat` 路线当年那么自然

从官方创作者文档看，`VRChat` 的创作路径本身就带着“完整世界”的气质。

它的世界创作文档要求创作者通过 `Creator Companion`、`Unity` 和官方 SDK 去建立和发布项目；文档本身就是按桌面端项目创建流程来讲的，而不是轻量网页配置。对已经熟悉这套体系的人来说，这意味着：

- 可以使用成熟的世界与化身逻辑
- 可以把“演出”放进一个更完整的空间社交语境里
- 可以利用 `Unity` 的生态、工具和已有经验

这条路的优点很明确：空间厚度、社交临场感、虚拟化身和沉浸感都更容易成立。

如果你的目标本来就是“让大家进入一个完整的在线虚拟场所”，那 `VRChat` 的世界化逻辑确实天然合适。

## 四、但为什么它不适合作为我们当前对外测试的第一层入口

这里的问题不在于 `VRChat` 不好，而在于它和我们这条线的**当前阶段目标**不完全一致。

`Balloon Live Space` 现阶段优先要验证的，是下面这些更前置的问题：

1. 线上数字舞台本身能不能成立
2. 一条 live set 的音画关系能不能在网页里被稳定感知
3. 第一次来的观众，能不能在几乎没有准备成本的情况下进入
4. 观众愿不愿意继续回来

而 `VRChat` 的平台页又把它明确放进一个成熟的平台生态里：`Android`、`iOS`、`Meta Quest` 和 `Windows` 都是它支持的用户侧平台。这当然说明它已经是一套成熟的大型平台，但也意味着 `Balloon Live Space` 如果直接完全押到这条路上，就会把很多更重的条件一起带进来：

- 客户端下载
- 平台与设备要求
- 进入方式学习成本
- 更完整的社交和身份系统

这些要素并不是坏事，但如果我们现在就把它们全部带上，反而会让“演出到底成不成立”这个最核心的问题被入口成本盖掉。

换句话说，`VRChat` 更像一种**更完整、更厚重的场所方案**；而我们现在更需要一条**更轻、更快验证的舞台方案**。

## 五、为什么浏览器三维舞台是当前更合适的中间层

这正是 `PlayCanvas` 这类网页三维引擎方向值得认真研究的原因。

根据 `PlayCanvas` 官方首页和产品页，它把自己定义成浏览器里的 3D / WebGL / WebXR 工作流，强调：

- `In-browser WebGL editor`
- `live updates across multiple devices`
- 浏览器中的实时协作式编辑环境
- 面向网页的发布路径
- `WebGPU` 与 `WebXR` 这类面向现代浏览器图形接口的能力

官方文档还明确说明它的 `XR` 能力建立在 `WebXR` 之上，支持网页里的 `VR` 与 `AR` 场景接入。这一点很关键，因为它意味着这条路天然站在“网页分发”这一侧，而不是“先进入一个封闭客户端平台”这一侧。

对我们来说，这条路线的优势不是“技术更高级”，而是更贴合当前阶段的任务：

### 1. 入口轻

人打开链接就能进。

这会直接改变一场活动的第一步体验。你不再要求每个人先完成安装、注册、配置和平台学习，而是先让他看到内容本身。

### 2. 迭代快

网页三维舞台的前台、入口、说明页、观看入口和活动日历更容易接成一条线。

这件事看起来像运营问题，实际上是创作结构问题。因为线上舞台如果不能被快速修正、快速上新、快速测试，它就会一直停留在“一个想法”。

### 3. 更容易纳入现有 GitHub / Luma / 页面前台结构

我们现在已经明确把 `Collective`、`SpacePort` 和 `Luma` 分成三层：

- `Collective` 负责团队与活动入口
- `SpacePort` 负责知识网络、档案和更深的结构源
- `Luma` 负责时间、订阅和公开发生

浏览器三维舞台更容易被纳入这三层之间：

- 可以从 `Luma` 进入
- 可以在 `SpacePort` 里有研究和档案页
- 可以在 `Collective` 被当成公开活动和作品线的一部分

## 六、但浏览器路线也不是“轻松胜利”

如果把网页三维舞台讲成“只要换到浏览器就一切简单”，那也是另一种自欺。

这条路有自己的硬问题：

### 1. 浏览器兼容性和性能依然是实际问题

官方文档里，`PlayCanvas` 明确把 `WebXR`、`WebGL`、`WebGPU` 和设备能力当作平台条件来谈。这说明网页路线并不是“没有技术门槛”，而是把门槛从“安装客户端”换成了“浏览器性能、GPU 能力和设备支持”。

对线上舞台来说，这意味着：

- 不同设备体验差异会很大
- 音画同步和帧率需要更谨慎地压预算
- 视觉效果不能无限往上堆

### 2. 网页前台天然更容易碎片化

客户端平台的一个好处，是很多进入、身份和空间规则已经内建了。

网页路线的代价是：很多事情你都得自己重新组织。

例如：

- 从哪进入
- 先看什么
- 观看说明怎么写
- 测试怎么收反馈
- 一场活动结束后，内容留在哪里

所以网页舞台不是“少做工作”，而是把更多组织工作拉回团队自己手里。

### 3. 社交临场感需要重新设计

`VRChat` 那条路天然带有化身、同场、空间共处感。

浏览器三维舞台如果只保留“视频 + 背景场景”，很容易退化成一个稍微复杂一点的直播页。

所以真正的问题不只是“能不能播放”，而是：

- 怎样让观众感到自己进入了一个舞台，而不是打开一个网页
- 怎样让视觉空间、音乐结构和观看路线形成关系
- 怎样在不增加太重门槛的前提下，慢慢加回空间感和共处感

## 七、`VRChat` 和 浏览器三维舞台，不是谁取代谁

这份报告最重要的判断之一，就是不要把这两条路看成非此即彼。

更准确的理解是：

- `VRChat` 更像完整场所层
- 浏览器三维舞台更像轻入口和快速发布层

如果未来 `Balloon Live Space` 跑顺，完全可以是这样的关系：

1. 先用浏览器入口承接第一次公开观看
2. 用轻量网页三维舞台跑 live set、共测和初步发布
3. 当内容、合作和回访足够稳定后，再把更重的场所方案接回来

也就是说，浏览器路线不一定是“终点”，但它非常适合做今天这条线的**现实起跑线**。

## 八、为什么 `PlayCanvas` 当前值得作为调查重点

官方产品页和文档给了几个很重要的判断依据。

### 1. 它天生站在网页前台这边

`PlayCanvas` 的产品和文档体系，都把浏览器发布当成第一现场，而不是附属选项。这和我们当前“先让大家进得来”的判断是对齐的。

### 2. 它对实时图形、WebXR、多人协作和快速发布的支持比较完整

哪怕现在还不直接做很重的多人协作壳，这套能力结构本身仍然适合线上舞台和活动型入口的迭代。

### 3. 它和 GitHub / 网页前台 / 公开链接的工作方式更容易接住

对 `VIRTURA` 来说，这不是纯技术选型，而是整个公开结构的问题。一个能和网页发布、仓库归档、活动入口配合的引擎，比一个理论上更完整、但第一步更重的系统，更适合当前阶段。

## 九、所以我们现在到底怎么判断 `Balloon Live Space`

如果要把这条线现在的判断压成一句话，就是：

`Balloon Live Space` 现阶段不是在做“最完整的虚拟场馆”，而是在做“最先成立的一条线上数字舞台”。

这句话背后有几个非常具体的策略：

### 1. 先用活动把路线跑活

所以我们会保留：

- `Alpha`
- `Session`
- `Beta`

这些节点不是形式主义，而是让这条线能被不断验证、不断纠偏。

### 2. 先把观演关系做出来，再谈更厚的社交壳

如果连“进来之后愿不愿意继续看”都没跑顺，那过早叠加更复杂的虚拟场景，只会让问题更难看清。

### 3. 把技术调查写成公开研究，而不是藏在脑子里

这也是为什么这份报告要放在 `SpacePort` 里。

一条线上舞台线如果想长成真正的公共基础设施，就不能只靠感觉。它需要有：

- 技术路线判断
- 失败路径记录
- 当前阶段目标
- 下一轮测试问题

## 十、接下来几轮最值得继续调查的问题

这份报告写完后，接下来最值得继续追的不是“还能不能再炫一点”，而是下面这些更硬的研究问题：

### 1. 浏览器路线的最低稳定配置到底是什么

我们需要知道：

- 观众用什么设备最稳
- 哪些视觉动作最容易把性能压垮
- 哪些交互值得保留，哪些该先砍掉

### 2. 一条线上数字舞台，最小可成立的空间感来自什么

是镜头调度？
是段落切换？
是舞台中景深关系？
是视觉和音乐结构对齐？

这类问题比“是不是 3D”更重要。

### 3. 什么时候值得把更重的场所层重新接回来

如果未来有足够稳定的观看习惯、足够明确的合作关系和足够清楚的内容结构，再重新考虑更完整的虚拟场所方案会更合理。

## 十一、当前阶段的结论

到目前为止，这份调查给出的结论不是“网页路线已经赢了”，也不是“VRChat 路线已经过时了”。

更准确的结论是：

- `VRChat` 更适合完整的空间社交场所
- 浏览器三维舞台更适合当前阶段的公开入口和快速测试
- `Balloon Live Space` 现阶段最需要的是稳定、清楚、能继续迭代的线上舞台结构

所以接下来这条线应该继续沿着这条顺序推进：

1. 继续做 `Alpha / Session / Beta`
2. 把每一轮问题认真归档
3. 把入口、舞台、视觉和反馈链路一起优化
4. 再判断更厚的空间层什么时候接回来

这才是更实事求是的推进方式。

## 参考与延伸阅读

### 官方资料

- [PlayCanvas 产品页：Editor](https://playcanvas.com/products/editor)
- [PlayCanvas 文档：XR](https://developer.playcanvas.com/user-manual/xr/)
- [PlayCanvas 首页](https://playcanvas.com/)
- [PlayCanvas 产品页：Engine](https://playcanvas.com/products/engine)
- [VRChat 创作者文档：Creating Your First World](https://creators.vrchat.com/worlds/creating-your-first-world/)
- [VRChat 创作者文档：Supported Platforms](https://creators.vrchat.com/platforms/supported-platforms/)

### 内部档案

- [Balloon Live Space 系列总入口](../README.md)
- [Alpha 测试档案](../balloon-live-space-alpha/README.md)
- [Session 02 档案](../session-02-live-set-2026-04/README.md)
- [Beta 共测夜档案](../beta-test-night-2026-05/README.md)