Firefly: Untethered Multi-user VR for Commodity Mobile Devices
这篇发在系统领域USENIX ATC 2020的文章，通过预渲染和存储用户在空间里所有可能位置、所有可能角度上看到的图像，交互时根据VR设备实时的位姿将对应帧传输到VR客户端，最终可支持15个VR客户端以60FPS速度并发。不得不感叹，跨领域的文章，真的视角很独特，VR的渲染一直都是根据实时位姿实时刷新，从未想过可以事先存下来。
概念科普
在介绍这篇文章之前，介绍一些基本概念，为了将本文的方法和其他方法区分。
普通视频
我们日常看的电影电视，显示在二维屏幕上。拍摄的时候什么视角，播放就什么视角，无法控制视角。
立体视频Stereoscopic
一般所说的3D视频。一般包含红蓝3D或者偏振3D.电影院的3D电影主要是偏振3D，针对人的左右两眼送出略微不同的视频，制造视差，带来一些立体感。目前常规视频格式mp4等以普遍之前上下排列和左右排列的3D视频。
立体视频仍然无法控制视角。
360度全景视频
基本的VR视频，三个自由度3DOF旋转（yaw, pitch, roll），即人的位置不动，头可以360度旋转，无法走近或走远看。
Volumetric视频 (和这篇Paper没啥关系)
在360度全景视频基础上再增加三个自由度，6DOF,除了旋转外，还增加了位移动向量，可以走近走远。生产Volumetric视频 一般包含了基于网格和基于点云的两大类方法。下面三幅图分别给出了获取Volumetric视频的相机摆放、文件存储以及实时播放的过程。
主体流程
区分前景和背景
区分背景和前景，前景指的是其他VR用户的Avarar或者实时变化的Control Panel。背景指的是比较固定不变，但非常复杂的场景。
预渲染
对于背景，进行预渲染。对VR活动的空间范围进行离散化，生成一个个grid。对每一个grid上，均多次渲染拼接，以及压缩成一个360度视频。
实验中，数据大小如下：
• Map size: 30 X 30 m
• Grid size: 5cm
• Size: 137GB vs. 99GB
一个场景上百GB，这个数据量还是相当大的，而且这样存储其实空间上也有很多冗余，作者以一句现代存储便宜不是什么问题带过。。。感觉还是有一些优化空间的。
存储
对于grid上每一个位置（5cm间隔），都存储一个360视频的帧，文章里定义为Mega Frame，Mega Frame包含相匹配的颜色和深度buffer，存储深度为了和前景有正确的深度关系。为了访存时的效率，对于360度视频的某一帧，又做了分块处理，分成四列的原因主要是25个测试者VR交互时基本都是水平移动，很少上下打量，因此切成列效率更高。Mega
Frame又做了LOD，为后面AQC(Adaptive Quality Control)提供可能。这些Mega Frame按照位置和Tile ID存入数据库。
VR移动预测和Frame访存
VR Client根据用户实时的位姿，访存对应质量的Mega Frame，解压缩和进行图像显示。
作为系统类的文章，这里写了很多移动预测和AQC。我没有细看，大致是通过机器学习的方法预测下一步VR位姿，提前加载到VR端的存储里，VR的存储分为硬盘-内存-显存三级，分别存储未解压的Tile文件，未解压的Tile文件，解压的Tile文件。
系统架构
整体系统架构如下图。值得说明的是这里的L1~L3 Cache不是真正的Cache，L3 Cache是VR client的硬盘，L2是VR Client的内存，L1是VR Client的显存Frame Buffer。
实验
硬件
VR Client是简易的手机配Cardboard的形式，手机是几款三星从2017到2019发布的Android 9手机。Server是一个桌面PC，配置如下：octa-core CPU @ 3.6GHz, 16 GB memory, 1TB disk, and Ubuntu 16.04，server无需渲染，只需要存储预渲染的结果，因此都不需要有GPU.
性能
延迟
总结
这篇文章默认背景是固定的，不能有动态变化，例如动态灯光等等，这里有比较大的局限性，同时一个场景的存储百G级别也是比较大的。感觉对于多人体验的展会场景（场景单一，多人操作系统对硬件维护成本小），以及建筑、风光TOUR这类的情况，有一定的适用性。
