[自译]给Web开发者的VR指南
作者着眼于WebVR的发展,通过介绍当前WebVR的现状,来帮助我们认识当下的技术环境;介绍了伴随发展的硬件,也一直是焦点存在的就是与手机结合的Mobile VR,作者在这里也是与PC一同进行了介绍;通过一些案例,来了解延迟,丢帧等状况对VR下体验的影响,并介绍了一些可能会被广泛使用的APIs,在渲染的技术优化上也增加了一些个人的理解;最后,作者也对web和VR的相互影响表达了自己的观点,并尝试引导读者去发现其它的实现道路。
本来只是想找些指南作为接触物认识,但是在阅读过程中遇到的线程处理和渲染的时候还真是头大...不过作者在对WebVR方面的积累还是十分深厚,能够从硬件、体验、实现方法去逐一阐述观点,并且能在最后引导探索WebGL以外的道路,真是厉害。
原文链接:A Guide To Virtual Reality For Web Developers
原文作者:Ada Rose Edwards
最近,VR在传统浏览器上的应用越来越多。在本文中,我们将通过WebVR API来查看浏览器和WebVR的发展现状。
VR和Web现状
Web社区之前已经尝试过了VR,现在的WebVR采用了一种新的技术,更适合现代的web。自从2011年WebGL发布以来,我们已经加速了3D载web上的应用。现在使用了WebGL的硬件可以提供新的webAPIs来实现VR。
这些APIs使WebVR的内容,可以通过头带设备3D显示。提供的头戴设备,也可以追踪和控制用户在虚拟世界中的信息。
WebVR于2014年,在Mozilla首次展示。在2016年,早期标准版适用于桌面端Chrome,Firefox,和Samsung的VRweb浏览器:Samsung Internet for Gear VR。
现在,几乎所有的头带设备都非常好的支持手机和桌面端标准。
WebVR的支持情况可以看这里
WebVR的标准是在公开衡量的,它代表了Mozilla,Google,Samsung,Microsoft,Apple之间的合作。
这意味着使用WebVR的网站可以制作一个身临其境的环境,并同时交付到所有的主要平台上实现,桌面或移动端。
web的处理能力可以让人们通过URL轻松地分享VR体验,在浏览器中查看,而无需复杂的应用商店,或是耗时下载到本地。
Samsung internet的VR额外Web APIs
这些API并不是WebVR API的一部分,但不使用WebGL,在传统网站来构建沉浸式体验是很有帮助的。
这些APIs正在为Samsung Internet for Gear VR研发。我们希望它们能够被其他浏览器接受并标准化。
全景视频
通过设置视频标签上的属性type=“dimension=360”,可以播放沉浸式全景视频(monoscopic&stereoscopic)的能力。这些在Samsung Internet 5.0上得到了加强,用户可以通过指尖来翻看。
可能的values:
dimension=3d-lr: side-by-side 3D video
dimension=3d-tb: top-to-bottom 3D video
dimension=360: 360-degree video
dimension=360-lr: side-by-side 3D 360-degree video
dimension=360-tb: top-to-bottom 3D 360-degree video
dimension=180: 180-degree video
dimension=180-lr: side-by-side 3D 180-degree video
dimension=180-tb: top-to-bottom 3D 180-degree video
改变天空
另一个Sansung Internet for Gear VR提供的API,是JavaScript API,可以将web的浏览器背景更换为开发者选择的背景。
你的传统2D网站仍然可以被看到,但是环境将会设置成与网站环境相匹配的。
window.SamsungChangeSky({ sphere: 'http://site.com/blue-sky.jpg' });
什么是WebVR?
WebVR是一组跨浏览器的JavaScript APIs,它提供了各种VR相关的用例,可以将用户置于WebGL生成的沉浸式环境中。
通过并行渲染3D图片,这些APIs可以处理所有面向用户的未失真3D图像。
我不会详细介绍这些标准,因为标准还在变化,大多数用户不需要直接与它们打交道,因为WebGL工具和库可以帮助你处理大多数的WebVR AP。
WebVR APIs现状
当前的API版本内部为1.1,2.0版本将会更改一些方法命名,并移除一些不使用的方法,还将会增加一些硬件支持,和在第一版中没有想到的额外功能。
可以在Mozilla Developer Network上阅读更多,也可以在GitHub上讨论。WebVR社区和W3C会在准备好之后,将它迁移到W3C工作上。
基本上,WebVR API提供以下内容:
头带设备允许用户在虚拟环境中自由查看。帧插值(frame interpolation)是内置的,就算你移到一个随机坐标系上,它都会是跟随头部。
会是像HTC Vive和Gear VR这样六自由度或三自由度的控制工作。它允许用户使用手与虚拟环境交互。
传给头戴设备的信息是如何渲染3D信息,例如视场,还有每只眼睛看到的画布渲染内容。
一种新的头戴设备特殊动画请求框架(headset-specific requestAnimationFrame),会同步在头戴设备上显示刷新率。
一种渲染方法,将呈现的帧以WebGL画布元素的形式提交给头戴设备。
VR循环图,头戴设备提供定位和旋转数据,开发者使用这些数据呈现用户角度的场景,然后将这些数据发送到头戴设备上,并坐标变换扭曲显示给用户。
构建WebVR的沉浸体验意味着什么?
令人惊讶的是,构建一个虚拟现实网站,和构建web app以及移动端站点有许多相似的问题。
现在web最大的问题之一就是网络性能,这很重要,因为:
用户的关注范围正在缩小,
网络越来越拥挤,
网站越来越大。
WebGL和WebVR网站也不例外,一不小心就会变得非常庞大。
VR内容会比传统内容更有优势,因为它新颖有趣,可以让用户多停留一会儿。即使这样,快速响应的3D体验依然很重要,用户没有耐心,而且会越来越没有耐心。
在你的网站将VR内容加载出来之前,它只是一个2D网站。
我的建议是,没必要把所有的东西都准备好了再展开,只需要加载到用户能够开始,然后动态加载并缓存其余部分。如果你阅读了Google的PRPL模式,那么这种行为应该会很熟悉。
即使是展示一个模糊的360环境和一些低保真的内容,让用户环顾四周,也可以为你争取到更多的时间,来载入更多的内容,并引入吸引人的体验。
显示一些基本的内容比失去用户有利得多,因为他们已经厌倦了等待进度条。
网络运行可能是CPU密集型,并阻塞主线程。这可能会给用户带来不好的体验。
预装一到两个密集的配置可以避免体验遭到破坏。然而你还是有很多东西需要去花长时间准备,那么你应该考虑一个更好的替代方案。
充分利用好service worker and the Cache API来让静态资产能够快速被访问,这是一个不错的方法。
渐进增强
VR最主要的两个平台是完全不同的:高端的台式电脑和先进的控制器;中高端智能手机,可能配备一个旋转追踪控制器,或者没有控制器。
一张HTC Vive的照片,有一个定位追踪控制器,Samsung Gear VR, Google Daydream 和 Google Cardboards都有出现
这给我们带来了两个挑战:
在不同性能的平台上保持一致的帧率,在多样的输入设备下,保持友好的体验。
Gear VR和Daydream的流行,Google Cardboard便宜的价格和良好的可用性,这会对手机的发展带来巨大的影响。
下面我来介绍一些典型的控制器设备,你不需要去支持它们,但是需要考虑到无控制器的场景,以及支持有控制器的选项,确保每个人都能有所体验。支持这些控制器的配置会很不错,但也显得不太实际。
一些库,例如A-Frame Extras的Universal Controls,充分利用这些可以帮助你做得更好。
兼容网络的控制器会提升沉浸体验,从左到右分别是:基于凝视追踪,传统的游戏手柄,旋转追踪控制器,定位旋转追踪控制器,完整的手势识别
非对称运行
随着web的增强,支持所有级别的硬件并不意味着你可以交付相同的体验。
再虚拟世界中,一个拥有双手追踪的体验会更吸引人,不应该受到没有控制器的用户一样的限制。
例如,一个VR应用,你可以在其中创作艺术作品,可以使用追踪控制器在高性能的机器上创作;在移动设备上,用户可以观看这些作品,但是不能编辑。
另一个例子是联网的多人VR游戏,玩家可以通过追踪控制器来玩游戏;而一个移动观众可以通过凝视的交互来选择不同的观看点。
测试你的开发内容
像现在的web设计一样,你需要先为移动端设计。当你在构建场景时,定期在中端手机上测试,没有控制器的情况下也能被大多数用户使用。
WebVR允许你同时面向两个平台。然而为两者提供相同的内容可能会导致移动设备陷入困境,或是台式机无法充分发挥潜力。
拥有很棒的外形没有问题。低保真的外观看起来会有些奇异,但是渲染起来很快。
为了提高图像质量,一个解决方案是在用户开始使用WebVR之前就提供图像质量选项。如果用户有高质量需要,就开始加载较大的渲染图像。
更困难但无缝的一种是,从最低的图像开始渲染,并监测设备的运行状况,就像requestIdleCallback。如果运行良好,就开始提高图像品质,如果出现了跳帧,那么就降低图像品质。
当你更新场景时,你可能会决定做一些事情:
下载并使用高分辨率的模型或纹理,使用更复杂的着色器。
从大量的用例来看,如果你能保证移动端也能保持良好的帧率,这确实能让用户获得更好的体验。
毕竟,一个伟大的场景要比视觉看起来真切许多。高度风格化的游戏,例如Team Fortress 2,现在看起来依然很棒,同时期的现实游戏也并没有显得陈旧。
一个伟大的场景,应该有精心设计的图像风格,大胆的色彩和鲜明的轮廓,这会在低功耗和低分辨率的设备上看起来也不错。
在VR环境中,大多数用户的势力都很差,因此减少文本或任何会导致用户紧张的内容。
Web给VR带来了什么?
web正在试图解决一些VR所面临的问题。
最大的问题就是,用户对一次性的体验付出很多权限,他们可能不想再用了。
在本地或桌面的VR中,你必须从应用商店下载,比如Gear VR的Oculus store,HTC Vive的Steam。
这些应用商店的模式很适合视频游戏,用户投入了一些钱后,会再一次的回来。但是对于购物,看电影,或尝试新的社交平台这样的一次性体验,商店就会变成门槛。
用户往往会因为他们的设备上存在的相似的应用,需要占用存储空间,使用大量的数据下载,而犹豫再三。特别是那些存储空间有限,网络状态也不太好的用户。
在web上,一旦用户离开页面,他们就不必担心这些内容,因为浏览器会清除这些。用户返回时,再将这些内容缓存到设备上。
当然,这样的存储负担就转移到了开发商身上,web产生的收益可能就会降低。
通过动态地提供VR内容资产,并且像web一样,可以从CDN提供智能缓存,HTTP缓存,设备上的service worker API缓存。
用户可以直接进入你的VR体验,不需要等待很久。
一个高度优化的WebVR网站应该再用户登录网站的第一秒内就呈现第一帧,没有冗长的下载和应用商店,这将大幅提高参与度。
每个体验都可以通过URL分享,在社交渠道商,通过邮件,甚至可以在电视上去分享,这样你的内容就因为较低的门槛而更容易传播开来。
充分利用快速网络
许多WebVR网站都有一个特点,在进入VR之前,用户可以在2D的显示器上观看和互动,这个视图通常会随着旋转手机,作为一个窗口出现在虚拟的空间里。
这个神奇的窗口是一个强大的模式。它给用户一个VR场景预览,而不需要头戴设备,这对没有头戴设备的人,或者在交通工具上,不想在公共场合佩戴的用户十分友好。
一旦用户有了兴趣,他们就会在你的网站上去留言,让他们能够获得更舒适的体验。
从高级界面到低级APIs,web给开发者们带来了先进的技术
你可能听说过很多webAPI在VR环境中使用更频繁:
WebSockets
这些数据将为本实时地作为二进制数据传输到服务器上,对于VR,它们可以被用来实时同步数百个用户,来共享体验,我最近制作了一款开源的演示,在一次会议上,我为超过150个人作出了演示。
WebRTC
为了扩展共享VR,我们还可以使用WebRTC维持二进制数据中视频和音频流的点对点连接。这可以让两个虚拟用户,在不通过中央服务器的情况下进行语音聊天和改变姿态。这可以一次连接6~8名用户。
WebAudio
WebAudio是最强大的API之一。浏览器包含了所有你需要的音频操作和分析。甚至可以通过pander node来在VR环境中提供3D音效。对于沉浸式的VR环境,WebAudio会很重要。
SpeechRecognition
新的浏览器包含了语音识别引擎,当一个键盘变得笨拙且苦难的时候,这对于发出指令和输入内容十分有用。Samsung提供了一个不错的例子(https://samsunginter.net/word-drop/)。
VR在长期内会对web产生什么影响?
VR已经对网络平台产生了影响;WebVR的跨平台API已经实现;还有W3C种创建一个WebVR工作组的讨论。
VR逐渐成为主流,随着AR和MR的设备开始进入消费者领域,web已经为新的平台做好了准备。
我们今天所知道的WebVR完全依赖于WebGL。对WebGL的优化,意味着浏览器的开发商不得不利用硬件优化来提高下一个版本的渲染速度,速度很重要,因为掉帧会产生很糟糕的影响,会引起用户的不适。
WebGL 2将会很快应用在稳定的浏览器。WebGL 2会让WebGL更接近OpenGL ES 3.0规范。更高的真实度和更快的渲染,会让VR有一种惊奇的视觉体验。
WebAudio可能需要更精准的3D音频转换,与头戴设备更好的传输功能,传递更高质量的3D音频。这会带来更好的沉浸体验。
在web上编写脚本可以显著地改善性能。一些JavaScript APIs可以用来提高web性能。
JavaScript本身可以进行优化和预编译。另一种选择是将其他语言编译为WebAssembly(WASM)。这可以提高整个系统的速度,提供一个更小的包,下载速度更快,更高效地解析和执行。如果使用得当和模块化。WASM可以用来作为WebVR体验的核心呈现引擎,我们仍然可以像今天这样使用JavaScriptj进行互动。
浏览器可以利用web worker来启用不阻塞主线程的计算。这样主线程就可以用于呈现。web worker对于操纵大量的数据,例如物理引擎,就很有用。通过这种方式将计算从主线程中分离出来,它们就不太可能会引发帧率下降。
不过,一些web workers发送数据的成本会加载主线程上。这部分可以通过转移对象来减轻。可转换的对象例如ArrayBuffers,允许你改变对象的所有者,但是如果中途出现了错误,处理起来可能非常容易出错。
一个名叫ShareArrayBuffer的新API将允许多个workers共享一个ArrayBuffer,这种情况下很有用。
现在渲染web页面的线程也被用来渲染WebGL场景。因此在主线程上运行的其他代码的副作用,例如垃圾收集或CPU绑定函数,都可能会导致丢帧。
OffscreenCanvas允许在web worker中执行渲染。这将有助于将非常重要和敏感的渲染循环从其它线程中分离出来。
另一个重要的渲染用例是预先录制的2D3D视频。这些可以在WebGL中用作纹理,但是缺乏对细粒度的控制。就像我们在JavaScript中有音频元素和AudioContext一样,我们需要添加一个videoContext来支持视频性能操作,以帮助在3D中播放360度视频。
VR与当前web冲突的一个地方就是文本的渲染。文本显示是web平台的核心功能,但是在WebGL中显示文本几乎是不可能的。
通过浏览器将呈现的DOM内容公开给WebGL,这将是很好的事情。更好地利用web对2D界面的能力,但也存在安全和隐私方面的风险!
另一条路径
基于WebGL的VR并不一定要成为VR的未来。在WebGL中,即使是最简单的WebVR应用,也似乎是短视的,从长远来看,这是很致命的。
web的部分优势在于HTML是一种声明性语言。浏览器可以根据平台来解释语言。你在手机上电脑上TV上看到的网站都是不同的。VR就是各种媒体体验的另一个平台。
通过声明,HTML和CSS,web上的VR可以自动处理渲染,平衡渲染速度和视觉效果。一台高端的电脑可以使用高级的着色器和细致的模型;低功耗的收集使用最简单的着色器和低保真模型,就像图片可以选择正确的分辨率一样,然后再根据设备进行裁剪。
HTML可以扩展到一些常见的VR用例中,例如360视频和3D图像,展示3D模型,将一个web页面的内容迁移到3D空间中。
Samsung已经开始将这些用例用在了web浏览器中,Samsung Internet for Gear VR。
它通过video元素内置了3D视频。显示一个并排的3D视频需要一个HTML标签:
<video controls src="360video.mp4" type="video/mp4; dimension=360-lr;">
折中的路
当然,这些并不互相排斥。web可以对简单的VR用例进行处理和优化,同时还可以通过WebGL构建沉浸式的VR提供优化。
Extensible Web是这样一种观点,web不必为易于使用而牺牲可扩展性,社区可以使用底层工具来扩展使用库的web平台。
VR似乎就是这种观点的一个例子,我们已经有了WebGL和WebVR API这样的底层工具。
A-Frame库提供了定制的HTML元素来构建WebGL的3D场景。A-Frame可以单独使用,或配合流行的框架例如React和Angular。
A-Frame允许有HTML经验的开发者去描绘3D场景,通过熟悉的JavaScript来控制它们。像jQuery,Angular和React可以被用于改变场景,但它们仍然是HTML。
结语
web有能力将VR带给世界,带给每一位用户,和每一位开发者。
VR在web上还处在早期的阶段,现在才刚刚建立起来,看看什么可行,什么不行。
web可以展示VR不仅仅是视频游戏。VRk可以用来强化我们在web上所做的一切,甚至可以沉浸在媒体中实现新的交互。
作为开发者,我们可以在web上开始构建VR体验。通过参与和反馈关于标准流程的反馈,我们可以让webVR成为一个更健壮的标准,为未来的开发者铺平道路。
即使你不认为VR已经成熟,AR和MR设备仍然与我们如今的构建相关。我们为VR沉浸式构建的接口模式,仍在向前。
我们一起构建明天的web。