去年团队内部要做远程协同评审，试过腾讯会议、Zoom这些传统方案，发现大家对着共享屏幕讲PPT，根本看不出空间关系，机械结构的装配问题在二维画面里完全说不清楚。后来我们索性花了一个多月自研了一套基于VR的虚拟会议系统，把评审从“看图纸”变成了“人进到图纸里”。这篇就把当时从零搭建这套系统的完整思路、技术选型和踩坑记录整理出来，给正在考虑VR会议方案的朋友做个参考。
1. 项目缘起与整体定位
先说清楚这套系统解决什么问题。它不是一个简单的“用VR看视频会议”，而是让参会者以虚拟形象进入同一个三维空间，可以自由走动、用手势指物体、多人协作查看3D模型，同时保留传统会议的语音和共享功能。
当时我们明确了一个核心目标：让虚拟会议不只是“能开会”，而是“在场景里开会”。举个例子，建筑设计方案评审时，传统方式是主持人切PPT，大家轮流看静态渲染图；而VR会议里，参会者可以走进建筑模型内部，用手柄指着某根梁问“这根承重柱会不会挡消防通道”。这种空间理解能力是二维工具给不了的。
项目定位是面向中小团队的轻量级私有化部署方案，优先支持Windows平台，兼容主流VR头显（当时主要适配了Quest 2、Pico Neo 3和Valve Index），单房间并发目标做到15人左右。这个并发数不是拍脑袋定的——调研了团队实际业务后确认，方案评审会一般不超过12人，15人留了一点余量。
系统整体分为三端：
- VR客户端：Unity开发，跑在头显里，负责渲染3D场景、虚拟形象交互、语音传输
- 桌面客户端：Web端（基于Three.js）和Windows桌面端，给没有VR设备的参会者用，让他们能以“幽灵视角”参与
- 服务端：负责房间管理、信令交换、语音转发、场景资源分发
选Unity而不是Unreal，核心原因是团队更熟C#，而且Unity在Android端（Quest、Pico都是Android系统）的优化资料最多。Web端用Three.js则是为了让不带VR的人也能参会，顺便验证了热词里提到的“videojs vr”类全景播放方案——Web端我们确实用videojs接入过360度全景画面回放。
2. 技术选型与架构设计
2.1 VR交互框架选型：XR Interaction Toolkit 还是 VRTK？
当时Unity生态里主流有两个交互框架：Unity官方的XR Interaction Toolkit（XRI）和社区维护的VRTK（现已改名Tilia）。对比下来我们选了XRI，原因有三：
第一，官方框架与Unity版本同步迭代，Quest和Pico的SDK都优先适配XRI，出问题容易搜到解决方案。VRTK虽然组件丰富（比如传送、抓取、UI交互开箱即用），但版本对新Unity的支持有滞后，我们项目直接上Unity 2021.3 LTS，用VRTK有点赌。
第二，XRI的架构足够灵活。它把“交互”抽象成Interactor（射线、手势、近距抓取）和Interactable（可抓取物体、可触控UI），中间通过交互事件解耦。我们自定义了一个“激光笔白板指针”的Interactor，就是在XRI的RayInteractor基础上扩展的。
第三，学习成本低。XRI本身自带一套完整的Demo场景，新同事上手只要把Demo里的Player预制体拖到自己的场景里改改就行。我见过不少团队因为想“省时间”用VRTK，结果后期和自研SDK对接时各种别扭——框架选型这事，跟哪个走得稳就走哪个，别只图组件多。
配套选择了XR Plugin Management作为平台抽象层，一个API调Quest、Pico、Index三家的SDK。虚拟形象动捕则用Final IK插件做全身骨骼解算，手部跟踪优先用各个头显自带的手势识别，只有做精细操作时才要求用手柄。
2.2 通信架构与语音方案：自研信令 + 中间人转发
会议的通信链路我们拆成了三条独立通道：
- 信令通道：负责房间加入退出、用户位置同步、交互事件广播，用WebSocket
- 媒体通道：负责语音，用WebRTC的SFU模式（服务端转发）
- 数据通道：负责3D同步场景里的增删改操作（比如白板画线、模型标注），也用WebRTC DataChannel，保证低延迟
为什么语音不用传统MCU模式而选SFU？因为VR会议里语音有个硬需求：3D空间音效。两个人面对面站着和背对背说话，声音应该不一样——这就要求每个客户端的语音流单独编码并由客户端做方位处理，MCU把所有音频混成一路会把空间信息全丢光。SFU虽然服务器带宽消耗大（每人上行1路、下行N路），但对15人规模完全扛得住。
服务端我们用了开源的Janus Gateway做WebRTC媒体层——虽然配置比较繁琐，胜在稳定，社区里坑基本都被踩平了。信令服务自己用Node.js写了一个轻量服务，每小时能支撑上千次房间创建，对内部系统足够。
位置同步这里有个细节要想清楚：世界坐标同步和本地预测。每个VR用户每秒钟会产生至少30次头显位置更新，如果全量广播，15个人每秒就是450条消息，即使每条只有几十字节也是不小的开销。我们做了两层优化：一是位置高频（20Hz）、旋转中频（10Hz）分开传输；二是收端做插值平滑，这个在Unity里用Animancer的平滑逻辑改一改就行，最终测试下来移动时人物动作还算自然。
2.3 渲染与全景方案：原生渲染 + 全景兜底
主场景的3D模型从建模软件（Blender/3ds Max）导出成GLB格式，Unity端直接加载。这里有个特别重要的优化点：模型的LOD（Level of Detail）。一套建筑模型动不动几十万面，在PC上跑没问题，但Quest 2的GPU要同时渲染两遍（双眼）就会出现掉帧。我们当时用了Unity的LOD Group组件，远处自动切低模，配合遮挡剔除（Occlusion Culling），最终把场景三角面控制在60万以内，Quest 2能做到72FPS不掉帧。
Web端我单独说下“videojs vr”这个热词。它是video.js的全景视频播放插件，通过分离视场（Field of View）来实现鼠标拖拽看全景。我们把它用在“参会者进入会场前等待界面”上——等待时播放一段360度公司环境视频，既降低Web端加载压力（全景视频比实时渲染便宜太多），又能营造沉浸感。这里有个小技巧：拼接全景视频时，如果相机没校准好，会出现“双头怪”现象（两个人头拼接不对称），这是全景拍摄最常犯的错，建议拍摄时用带全景拼接的专用相机，别自己手工拼。
“vr眼镜电影片源”这个搜索热词其实也和我们有关联——很多全景内容制作团队把VR影片放在一体机本地播放，但虚拟会议如果也要放影片，不能直接用这个方式，得走流媒体。我们是这么处理的：视频按DASH协议切成4秒一段，客户端预加载下一段，确保播放流畅。这个方案后来用在虚拟展厅的讲解大屏上，效果很不错。
3. 核心功能拆解与设计细节
3.1 虚拟形象与全身IK
虚拟形象是VR会议里最影响沉浸感的部分。我们做了两套：完整肢体版和半身版。完整肢体版需要用户有头显和双手柄，通过头显6DoF数据和手柄位置反推手肘、膝盖的位置，这就是Final IK的FullBody IK功能。半身版只在Web端用，头部用头像贴图，身体用默认的胶囊体加动画，大家不会太在意。
实现完整肢体IK时我们踩了一个大坑：如果只追踪头部和双手，那么“用户转身”和“用户侧移”无法区分。比如你站在原地向右转90度，头显位置没变但朝向变了；如果原地向右走两步，头显位置变了但朝向可能没变。Final IK提供了一个配套的VRIK组件，要求把Input Sources设成“Pico/Quest的手柄追踪”，它会根据连续帧推算用户的躯干朝向，但实际效果有限。
后来谷歌开源了一版基于UDP的全身动捕实现思路——把头部位置、手部位置、以及头显朝向下一次移动到服务端，服务端用一系列平滑算法推算出兴趣点，但我们团队测试后觉得工程复杂度太高，最后改成“局部刚性约束”：固定脚部位置（用户原地站立），用头部+手臂的位置解算髋部朝向，精度不高但足够自然。动画师朋友看完后建议我们加一个“手部重力下垂”过渡，整个人的肢体感立刻上升了一个档次。
3.2 3D模型协同标注与白板
这是我们认为VR会议区别于传统会议的核心功能之一。
模型标注的实现方式：用户用射线指向模型某点，按住扳机键，系统创建一个锚点（3D空间位置 + 模型ID + 法线方向），锚点上挂一个手写板UI，用户通过虚拟键盘输入文字，或用激光笔在上面画圈。所有标注通过WebRTC DataChannel实时同步给房间内其他人。同步的数据结构很简单：{modelId, point, normal, userName, content, color, timestamp}。但这里有个“大坑”：模型空间坐标和世界坐标的转换。如果标注锚点保存成世界坐标，模型被拖拽旋转后锚点就悬空了；需要保存成模型本地坐标，每次渲染时用模型的世界矩阵反算回世界坐标。这个点调试的时候花了一整个下午，后来才发现是这里出了问题。
白板则有两种模式。一种是平面白板，挂在一个虚拟的三脚架上，支持多人同时画线。另一种是“空间白板”：在模型旁边直接浮现一块透明面板，用激光笔直接在上面画，笔迹以3D线框的形式存在空间里。第一种用Unity自带的LineRenderer就够，但多人同时画时要注意并发控制，我们采用“最后写入先生效”的乐观锁，冲突概率很低。
3.3 空间音频与会话管理
空间音频用的Unity自带的AudioSource+SpatialBlend=1，配合Oculus Audio SDK和Pico Audio SDK做过调优，最后的听感比单纯衰减好很多：你能听出声音来源方向，戴耳机时背后有人在说话，下意识会想转头（这个真的很灵）。实现上很直接：每个远程用户的语音流，在本地创建一个AudioSource，把它摆在世界坐标中对应虚拟形象的位置，再把WebRTC收到的音频数据流喂给它。服务器挑战在于SFU模式下音频带宽：15人同时说话，每人64kbps Opus编码，总带宽也就1Mbps左右，完全可控。
会话管理我们做了几个状态：等待中、进行中、暂停中、已结束。加了一个小设计：主持人可以把参会者“静音”，但不是硬切，而是降低对方音量，类似现实里“低声耳语”。这个“软静音”功能试过的人都很喜欢，比传统会议的一刀切静音要舒服。
3.4 全景视频与全景环境切换
回到“vr全景系统源码”这个词。我们在系统里实现了一套简单的全景图/全景视频加载器：基于Equirectangular（等距柱状投影）全景图加载到Skybox，全景视频则用Unity VideoPlayer渲染到Skybox的材质球上。两者都支持运行时动态切换，会议中期可以一键把周围环境从“会议室”切换成“户外沙滩”，实测沉浸感瞬间拉满。不过这个切换有个注意点：服务器往各客户端同步切换指令时，网络差的话会出现你切了但队友没切的情况，记得加一个版本号和校验。
4. 实操过程与关键环节实现
4.1 开发环境与工具链准备
硬件清单：
- 开发机：i7-12700 + RTX 3080 + 32GB RAM，跑Unity Editor和Quest Link调试
- 头显：Meta Quest 2 × 2，Pico Neo 3 × 1（用于兼容性测试）
- 服务器：阿里云轻量应用服务器，4核8G，跑Janus和信令服务
软件清单：
- Unity 2021.3.16f1 LTS + XR Plugin Management + XR Interaction Toolkit 2.3
- Final IK（用于全身骨骼解算）
- Photon Voice 2（用于WebRTC语音的Unity客户端）——后期换成Janus自研SFU
- Node.js + ws库（信令服务）
- Janus Gateway 1.1.1（媒体服务）
建议装一个Oculus XR SDK和Pico XR SDK并存，通过XR_PLUGIN_MANAGER激活开关切换，这样一台开发机能同时调试两个平台。
4.2 最小可运行Demo：从零到能开会
这里给完全没接触过XR开发的同学一个可复制的路径：
第一步，Unity里装好XR Plugin Management，激活OpenXR后端，选择“Oculus”和“Pico”平台支持。然后导入XR Interaction Toolkit的Starter Assets，按官方文档把XRI Default Input Actions绑定到Input Action Manager上。跑起来确认头显能看到默认场景，手柄能传送、能抓取物体。
第二步，依次放入三个核心Prefab：XR Origin（VR相机与手柄）、VR Conference Room（会议室场景）、VoiceManager（语音通信挂载点）。会议室场景我用的是网上下载的低模会议室模型，但为了节约性能删了所有动态灯光，只用Lightmap。
第三步，写最简单的网络同步。我推荐先用Mirror（Unity网络库）做位置同步，因为配置简单。先只同步head和hand节点的位置和旋转，运行两个客户端验证移动是否能看见对方。这个阶段别碰完整的身体IK，先做个“太空头盔+两只手套”的极简形象即可（会动的漂浮手套反而很有喜感）。
第四步，接入语音。先用Mirror自带的NetworkRoomPlayer做验证，语音选Photon Voice 2的Demo，Room里能听到对方说话后，再考虑换成Janus。
第五步，加白板和模型加载。白板直接用网络线渲染——用Unity的LineRenderer画点，广播点列表。模型加载用gltfast插件加载GLB文件，然后在场景里实例化。做到这一步，你的“最小可用VR会议系统”已经能跑了。从零到能开会，快的一个周末，慢的一周。
4.3 信令服务的核心代码设计
信令服务用Node.js实现，核心是房间状态维护。贴一段关键的伪代码：
// 信令服务核心：管理房间和用户状态 const rooms = new Map(); function handleJoin(userId, roomId) { if (!rooms.has(roomId)) { rooms.set(roomId, { users: new Map(), hostId: userId, createdAt: Date.now() }); } const room = rooms.get(roomId); room.users.set(userId, { userId, joinTime: Date.now(), hasVR: true // 标记是否VR用户 }); broadcast(room, { type: 'user-joined', userId, roomSize: room.users.size }); } function handlePose(userId, roomId, pose) { const room = rooms.get(roomId); if (!room) return; // 位置高频同步，目标20Hz，因此收到后直接转发不排队 broadcastExcept(room, userId, { type: 'pose', userId, pos: pose.pos, rot: pose.rot }); }这个信令服务处理Story了所有“非媒体类”消息。为了让同步不至于被消息风暴打垮，我们设置了每用户50ms的发送窗口，位置数据只在窗口满时发送，而其他事件（如标注创建）优先级更高，能立即推送。
4.4 Unity端位置同步的核心代码设计
Unity端接收远程用户的位置更新，核心是在Update()里做插值：
public class RemoteUserSmoother : MonoBehaviour { private Vector3 targetPos; private Quaternion targetRot; private float smoothTime = 0.1f; public void OnReceivePose(Vector3 pos, Quaternion rot) { targetPos = pos; targetRot = rot; } void Update() { // 注意：不能直接赋值，需要平滑过渡 transform.position = Vector3.Lerp( transform.position, targetPos, Time.deltaTime / smoothTime ); transform.rotation = Quaternion.Slerp( transform.rotation, targetRot, Time.deltaTime / smoothTime ); } }这个0.1s的smoothTime是多次调试出来的平衡值：太小会抖动，太大会滞后明显。但注意一个特殊情况：如果两个客户端时钟没同步，Lerp会出现“漂移+回跳”。一个初级修正方案是：服务端统一推送服务器时间戳，客户端用本地时间差做补偿。细节不展开了，记住一句：网络同步永远假设网络是不可信的。
4.5 模型加载与标注的Unity集成
模型加载用gltfast，负责把GLB模型加载进Unity场景。加载后需要调用MeshCollider重新生成碰撞体，否则射线没法命中模型表面，标注点就采不准。这个碰撞体的优化有讲究：如果模型面数太高，MeshCollider会拖慢每帧物理计算。我们做法是生成一个简化的凸包碰撞体（用UnityEngine.AI.NavMesh做体素化然后生成凸包），这样射线检测既有精度又不伤性能。
标注数据同步参考如下结构：
public struct AnnotationData { public string id; public string modelId; public Vector3 localPoint; // 模型本地坐标 public Vector3 normal; public string authorName; public string content; public Color color; }服务端收到标注创建消息后，向其他客户端广播，其他客户端根据本地模型引用，用localPoint + world矩阵算出世界坐标，再实例化一个标注UI。要确保所有客户端对同一模型的变换状态理解一致，否则标注会错位。这个用“房间内模型状态统一由主持人控制”来解决，避免多人同时拖拽模型导致错乱。
4.6 全景视频播放：videojs-vr 的落地实践
Web端全景视频播放，我们真的用上了videojs-vr。最简用法如下：
<!DOCTYPE html> <html> <head> <link href="https://vjs.zencdn.net/7.19.2/video-js.css" rel="stylesheet" /> <script src="https://vjs.zencdn.net/7.19.2/video.min.js"></script> <script src="https://cdn.jsdelivr.net/npm/videojs-vr@1.9.0/dist/videojs-vr.min.js"></script> </head> <body> <video id="myVideo" class="video-js vjs-fluid" playsinline crossorigin="anonymous"> <source src="https://example.com/conference-room.mp4" type="video/mp4" /> </video> <script> const player = videojs('myVideo', { controls: true, muted: true, plugins: { vr: { projection: '360', // 或 '360_LR' 表示左右双眼 motionControls: true } } }); </script> </body> </html>配合VR眼镜时，motionControls设为true后，用户转动头部画面会跟着转。但这个方案只适用于沉浸式全景视频播放，不能做实时虚拟形象交互——所以它在我们系统里的定位是等待场景、会议开场预告、会后回顾回放。真正“会开会”的还是Unity端实时渲染。
5. 常见问题与排查技巧实录
5.1 Quest 2 连不上 PC 的 Link 调试
最常见问题：USB线插上后Oculus PC端识别不出设备。检查顺序：
- 确认USB线支持数据通信（好多线只能充电）
- 在Oculus App里开启“未知来源”
- 重启Oculus客户端和能头显，顺序必须是先启PC端再插线
- 打开设备管理器查看有没有“Quest 2”设备，有感叹号就重装驱动
如果还不行，检查Windows的USB电源管理：进设备管理器，找到USB Root Hub，属性里把“允许计算机关闭此设备以节约电源”取消勾选。这条能解决大多数间歇性断连。
5.2 渲染掉帧怎么查
典型症状：会议中途画面开始一卡一卡。检查顺序建议：
- 打开Unity Profiler，看CPU耗时，重点看主线程和渲染线程。VR项目的CPU瓶颈常在“物理计算”和“骨骼动画”，把模型碰撞体改成简化凸包后掉帧缓解很明显
- 看Draw Call。一个场景上百个物件如果没合批，Draw Call轻松上千。用GPU Instancing和Static Batching能显著降低
- 看内存占用。Quest 2只有6GB RAM，如果加载了太多大纹理，系统会强杀进程。跑
adb logcat | grep -i "lowmemory"能确认
5.3 全景视频播放撕裂
preview播放时，如果全景画面边缘有撕裂或发灰，大概率是材质没设成“Unlit”或没关“Fog”。Unity Skybox材质的Shader如果带光照计算，会出现亮度不均匀。解决：新建一个材质，Shader选Skybox/Panoramic，贴图纹理类型设为Default，并且把场景Fog关掉。
5.4 多平台手柄按键不一致
Quest的A键和Pico的A键位置一样，但Valve Index的抓取键位置不同。如果代码里直接绑定“抓取”到“手柄扳机”，在Index上会变成“捏合”。解决：用Input Action的绑定映射，在Edit > Project Settings > Input System里给每个设备单独指定行为。千万别用键盘映射来调试VR按键，你在PC上按空格能交互，不代表VR里按手柄能交互。
5.5 语音延迟与回声
长期调试语音最困扰的是回声。排除法优先级：
- 先确认是不是硬件问题——把耳机戴上，看是否还有回声（扬声器外放必然有回声）
- 查WebRTC里的回声消除（AEC）是否开启。Janus网关转发时会把AEC关掉来降低延迟，但客户端本地必须开启AEC
- 检查AudioSource的SpatialBlend是1.0，如果设成0.5，声音会和立体声背景混在一起，形成“空间感错乱”
VR语音和普通会议语音一个核心差别：这里没有“谁在投影仪前说话”的概念，声音追踪的是虚拟形象的位置，如果这个人突然传送走了，音频源如果还留在原地就会出现“幽灵说话”。我们需要在每次传送后立即置位音频源的坐标。
6. 避坑指南与我的个人体会
再说三个这个项目里我认为最值得分享的坑。
第一个，不要一上来就做复杂的动捕表情。当时美术同事强烈建议加入眼动追踪和口型同步，试了一周后彻底放弃——硬件支持不稳定，不同头显的追踪精度差异太大。最后妥协成“头显上沿闪烁光晕提示说话状态”，效果反而自然。先做“能用的”，再做“炫酷的”，这条路在XR领域尤其正确。
第二个，WebRTC的SFU部署比想象中麻烦。Janus配置的坑特别多，尤其证书、端口、NAT穿透。我们当时在阿里云上配了自签名证书，结果Chrome和Quest内置浏览器都不认，wasm客户端连接直接失败。最后换成Let‘s Encrypt证书才解决。如果你完全不想被这些琐事折磨，直接买商用服务（声网、腾讯实时音视频都支持SFU）能省一半时间，不过要在国内合规环境下测试好。
第三个，多人同时拖拽一个模型，一定会乱。不管网络优化得多好，总会有一个人拖拽时另一个人的画面发生瞬移。后来我们设计成：模型默认只有主持人能拖拽，其他参会者只能“临时借用”——借用的瞬间模型所有权转移，其他人只能观察不能操作。这个权限控制让会议纪律好了很多。
最后分享一个和“vr眼镜电影片源”有关的小发现。我们用全景视频做“虚拟展厅”时，最初素材来自全景相机拍摄，但会议室场景没什么人愿意反复看。后来测试方案时直接把一些开源的全景电影片段放进播放器，发现大家瞬间安静下来，沉浸感爆表。这也说明一个问题：VR会议的“内容吸引力”往往比技术本身更重要。技术只是给你一个“在场”的基础框架，真正让人愿意留在虚拟空间里的，是里面的内容和人与人之间的互动感。
如果以后继续做这个方向，我会把“远程手势协作”做细，比如A用户的手精确碰到B用户的手时产生触觉反馈（通过手柄震动模拟）。这次版本里只做了手部碰撞的高亮反馈，但已经能感受到空间协作的潜力了。建议想入坑VR会议开发的，先别纠结宏大的元宇宙叙事，把“三个人在房间里对着一个模型讨论”这件小事做到极致，就有足够多的应用场景等着你。
