从零搭建VR虚拟会议系统：技术选型、架构设计与避坑指南

去年团队内部要做远程协同评审试过腾讯会议、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 ToolkitXRI和社区维护的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端直接加载。这里有个特别重要的优化点模型的LODLevel 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自带的AudioSourceSpatialBlend1配合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 × 2Pico Neo 3 × 1用于兼容性测试服务器阿里云轻量应用服务器4核8G跑Janus和信令服务软件清单Unity 2021.3.16f1 LTS XR Plugin Management XR Interaction Toolkit 2.3Final IK用于全身骨骼解算Photon Voice 2用于WebRTC语音的Unity客户端——后期换成Janus自研SFUNode.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上。跑起来确认头显能看到默认场景手柄能传送、能抓取物体。第二步依次放入三个核心PrefabXR OriginVR相机与手柄、VR Conference Room会议室场景、VoiceManager语音通信挂载点。会议室场景我用的是网上下载的低模会议室模型但为了节约性能删了所有动态灯光只用Lightmap。第三步写最简单的网络同步。我推荐先用MirrorUnity网络库做位置同步因为配置简单。先只同步head和hand节点的位置和旋转运行两个客户端验证移动是否能看见对方。这个阶段别碰完整的身体IK先做个“太空头盔两只手套”的极简形象即可会动的漂浮手套反而很有喜感。第四步接入语音。先用Mirror自带的NetworkRoomPlayer做验证语音选Photon Voice 2的DemoRoom里能听到对方说话后再考虑换成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 hrefhttps://vjs.zencdn.net/7.19.2/video-js.css relstylesheet / script srchttps://vjs.zencdn.net/7.19.2/video.min.js/script script srchttps://cdn.jsdelivr.net/npm/videojs-vr1.9.0/dist/videojs-vr.min.js/script /head body video idmyVideo classvideo-js vjs-fluid playsinline crossoriginanonymous source srchttps://example.com/conference-room.mp4 typevideo/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会议开发的先别纠结宏大的元宇宙叙事把“三个人在房间里对着一个模型讨论”这件小事做到极致就有足够多的应用场景等着你。