WebVR and Chrome: a brief overview.

In this article we will discuss what a Virtual Reality (VR)-capable browser actually brings with it. Many users expect this to mean starting their browser (almost browser support today 3D configurators on WebGL-basis, setting up their head-mounted display and immediately immersing themselves in a complete VR browsing experience. But of course this is not the case and it will take a long time until these experiences will be possible.

Adding WebVR does not make the browser a complete virtual reality experience. Instead, it provides an API that allows developers to create VR content in the context of a website. Imagine that. You browse Amazon and find a jacket, a TV or a bike or whatever interests you. If Amazon`s developers used the WebVR API, you could add a button labeled “View in VR” that allows you to view the object in 3D on a 1:1 scale using a VR headset. In the case of a garment, for example, you could walk around the product, lean in and search the seams as if it were actually sitting in front of you. You can also imagine similar experiences with teaching tools, data visualization, mapping etc. WebVR gives developers the tools they need to do this.

And of course there will also be games. This is so self-evident that it`s not even worth mentioning.

What`s the status quo?

Chrome has been allowing VR to be displayed for several years now. This means that WebVR features are only added to Chrome itself when the API is mature and there are enough developers and users interested. It is not possible to make a clear prognosis as to whether VR will make a breakthrough this time or whether there will be a flop again. Of course it makes no sense to add new features to Chrome if only a tiny fraction of the enthusiasts will be able to use them. In addition, there are very few VR devices that are open to developers at this point, so it`s still very clear what functionality will be possible at the end of the day. If we commit ourselves too early to an API, we risk excluding devices that don`t match the assumptions of a very small sample set.

However, if we wait until VR becomes ubiquitous before we make it a real part of the platform, we will be very much behind. Maintaining an experimental open code area of the browser for VR development gives us the opportunity to work out the kinksin the API implementation without disrupting the core code base.

Currently many examples support the Oculus Rift and we will also look at the support for Cardboards SDK. All VR solutions with an Open Source SDK can be considered. We should also mention that this is a by-product for us. So we won`t integrate every new VR gadget immediately.

We will update our content for WebVR on a regular basis to ensure that you stay up to date with future Chrome development.

The L-word.

At this point, we must also go into the latency period in more detail. The first and last thing anyone mentions when talking about VR development. In order to achieve the mystical “presence” we are aiming for, a latency time of more than 20 ms should not be exceeded. The problem is that browsers are not exactly known for their low latency. But what about the Chrome-Browser?

It takes a total of 63ms from  headset movement to LCD change. As a reference on the same machine, another example gives us a sample of 48ms. That`s actually not as bad as it seems at first glance. This means that the example takes 3 pictures on a 60Hz display so that their head movement affects the picture on the screen. So Chrome takes 4 pictures. A difference of one frame compared to a native app is definitely not surmountable. Of course, both are still far away from 20ms, but this time target is considered a future goal.

So how can we reduce the latency time in the browser? This is much more complicated question than it seems and there are a lot of people in the Chrome team working on this problem in different ways. There may be some abbreviations that need VR content for progress. Chrome has a pretty extensive rendering pipeline designed to render traditional web content as smoothly as possible. This includes a lot of layout, rastering and compositing with little benefit if their content is a single, fullscreen WebGL context. Therefore, in this particular case, there may be some advantages to short-circuiting the compositing process. We haven`t had the chance to really try it yet, but it is an example of the types of optimizations that can be done to achieve this elusive “presence”.

Differences in implementation.

Chrome`s experimental implementation of WebVR is very similar to Mozilla`s prototype, but there are currently some small differences due to the parallel nature of the ongoing development. It is quite possible to develop web applications that work with both and I expect the differences to be eliminated as the developers give us a better idea of what is important and what is not.

(Remember, these interfaces will change. This is just a description of the source versions.)

First, since it is Blinks policy not to add any prepended APIs anymore, none of the function starts with WebKit, blink or something like that. To access them, you need to start Chrome with the enable-vr flag instead.

GetVRDevices in Chrome returns a return instead of accepting a callback. This is the case for the following reasons:

• Many new Web APIs tend to use Promise for asynchronous behavior.
• Promises have explicit “success” and “failure” paths that fit the use case well.
• Promises are checked exactly once for success or failure, which causes confusion as to whether a callback can also be triggered permanently (e. g. when new devices are connected).

Writing a code that works with both browsers is trivial.

Chrome`s PositionSensorVRDevice is almost identical to Mozilla`s, but has a reset sensor function. Calling this function resets the HDM sensors to take the current direction of the user “forward” into account.

Chrome`s M`HMDVRDevice has a few attributes missing from Mozilla and a pair missing from Mozilla`s code. Chrome has the displaySize and renderTargetSize vectors to display the resolution of the HMD display and the recommened render target size. The render target size is expected to be larger than the display size and is calculated so that the rendered output has a ratio of 1:1 pixels, with the display displayed at its most distorted point after the resulting image has gone through the process of distortion post-processing. It is worth nothing that the devicePixelRatio should not be considered when specifying the size of a canvas for VR rendering.

(Update: Chrome no longer supports displaySize because it has no effect on the rendering. RenderTargetSize has been changed to getRecommendedRenderTargetSize() to reflect the fact that its value changes when the field of view is changed.)

Chrome currently lacks finer control over Mozilla`s field of view. You can call getRecommendedFieldofView, but there is no getCurrentEyeFieldOfView. GetMaximumEyeFieldOfView or setFieldOfView. All renderings in Chrome currently assume that you are using the recommended FOV.

(Update: Chrome now supports setFieldOfView, getMaximumEyeFieldOfView and getCurrentEyeFieldOfView)

Finally, you can use Chrome to pass vrDistortion:false to webkitRequestFullscreen along with vrDisplay:hdm to prevent postprocessing from running to distortion. This is usefil for checking the render results, but can also be used if you want to implement your own distortion run. The API does not currently provide information about the desired distortion formula, but this is a “best guess” affair, possibly based on the HDM name. It is strongly recommended that you let the browser do the distortion for you.

(Update: Let`s better explain the fullscreen API. There are two features in Chrome that you can use for full screen mode: webkitRequestFullScene and webkitRequestFullScreen. The former is obsolete, while the latter complies with the W3C specification. I have only set up the compliant version to work with the VR API. If you use the other one, go to full screen mode, but don`t get the distortion effect. So in short, use the following code for the cross-browser VR fullscreen.)

We would also like to point out that Chrome supports the Oculus DK1 latency tester without the developer having to do anything about it.

Let`s stress once again that all these changes based on the needs of the developers are discarded.

Known issues.

First and foremost, when webkitRequestFullscreen is called, the canvas works in full screen mode but does not automatically display the content on the HDM. Either you have to move the window to the HDM display before switching to full screen mode or you use screen mirroring. Neither option is great, but hopefully this situation will only last for a short time. The goal is when you are working with a VR device in full screen mode, the content automatically goes to the HDM display and then returns to the main display when you press Escape.

And passing an HMD to the full-screen API only works with canvas elements that currently have a WebGL context. This limitation will probably remain for some time while we look at Mozilla`s work with 3D CSS content in VR. To put it bluntly, I have no idea how this will work from a UX perspective, and since Mozilla has more manpower focused on WebVR. I`m glad they can feel it first.

Also, the final output image after distortion is the same size as your render target, not the size of the HDM display. I think this goal could be achieved with chromatic aberration correction, but of course we can`t guarantee it. It is certainly nor optimal from a memory usage point of view and should be corrected in the near future.

How can you help?

If you are enthusiastic about this technology and want to help drive it forward, we think it`s great. Probably the best way to help this technology move forward is to create something great that uses WebVR. Whether it`s hacking support into an existing application or creating something completely new, the more use cases there are, the more compelling the API becomes.