Early access to the WebXR Device API in Chrome Canary

Hey, are you a web developer that wants to play with bleeding-edge browser VR APIs and influence their development? If so read on!

The WebXR Device API is the next iteration of WebVR, and the API that we intend to release in stable browsers at some point and support going forward. It’s still a work in progress, but the first (mostly) working implementation is now available in Chrome Canary for Android and Windows behind a flag, and so it’s the perfect time for motivated developers to start playing with the API and giving the Immersive Web Community Group feedback!

New experimental WebVR builds for Android

It's an exciting time for WebVR on mobile right now! Today the Chrome team announced that WebVR is available as an Origin Trial in the Chrome 56 Beta for Android. Oculus has also recently launched their Carmel browser preview, and Samsung is continuing to improve their implementation. On the desktop side Mozilla is continuing to make great progress, and the spec is making huge strides as all of the interested parties (like Microsoft, whose input has been invaluable!) identify the rough points and flesh out the edge cases. The future of VR on the web looks bright!

And because we're so excited about that future, a few of us on the Chrome VR team wanted to give developers a peek at what's coming for WebVR performance beyond the Chrome 56 release. Browser release schedules being what they are we weren't able to get all of the optimizations for WebVR into Chrome 56 that we wanted and still hit the release date. We've already got some exciting proof-of-concepts for significant performance enhancements that we intend to make part of future builds though! So in the tradition of the experimental desktop builds that have bootstrapped the WebVR desktop development community we're making an experimental Android Chromium build available today on https://webvr.info/get-chrome (Look for ChromePublic-webvr-native-WIP-201*****.apk)

This build carries with it all the caveats of the previous experimental Chrome builds for Android. It's not intended for normal browsing, it's definitely a bit unstable, it doesn't have various patent-encumbered media decoders baked in, and it comes with exactly zero support. What it DOES have is our latest and greatest rendering pipeline research that we've found to yield pretty impressive performance wins.

I should take a moment and call out my colleague on the Chrome VR team Klaus Weidner for his excellent work in this area. I may have the public reputation for being the WebVR guy, but Klaus is responsible for a great deal of the WebVR rendering optimization on Android. He gave a great lightning talk about the work he's being doing at the W3C VR workshop this October, which you should check out if you're interested in that kind of thing!

There's some known issues outlined in the Release Notes you should know about, the primary one being that this is currently only for Daydream Ready devices (though a Daydream View is not required.) But if you're a WebVR developer with the right hardware take a peek and give us some feedback!

[EDIT: I also wanted to clarify the Origin Trial thing, since it appears to be a point of confusion. Origin Trials are for sites that want to make a feature available to all of their visitors by default. It's intended for use on pages like the ones linked below that are public facing and don't want to make users flip obscure flags to see the VR content.

If you're just doing development or testing of WebVR pages, though, you do NOT need an Origin Trial token! You can access the exact same features by turning on the "WebVR" and "Gamepad Extensions" flags in about:flags. (The Origin Trial covers both features).]

A couple of pages I recommend trying out with the new build

• https://webvr.info/samples (of course)
• https://www.clicktorelease.com/code/cruciform/vr/
• https://threejs.org/examples/?q=webvr
• https://media.tojicode.com/q3bsp/ (If you've got the stomach for it the touchpad on the Daydream controller will let you run around the level w/ click to jump!)

Happy WebVR-ing!

Update on WebVR spec, Chrome, and HTTPS

(This post was originally sent to the public-webvr mailing list, which you should totally follow if you're interested in the latest and greatest WebVR news!)

Hello WebVR community!

The Chrome team has been a little quiet on the WebVR front recently, and I apologize for that and thank you for your patience. We’ve been heads down and working hard to deliver the best experience we can for developers as soon as we can. Several things have happened recently that will affect what we’re delivering and how. As such, we wanted to give developers an update.

Oculus Rift and HTC Vive review

By virtue of the WebVR work I've been doing I've been lucky enough to have a fair amount of access to VR hardware, and at this point feel like I've got a pretty good handle on where each of the newly released devices stand in relation to one another. Since it seems to be a popular topic lately I figured I'd give a brief overview of my thoughts on the Vive and Rift.

Moving towards WebVR 1.0

Consumer VR is at our doorsteps, and it’s sparking the imagination of developers and content creators everywhere. As such it’s no surprise that interest in WebVR is booming. Publications like the LA Times have used WebVR to explore the landscape of Mars, and a doctor was able to save the life of a little girl by taking advantage of Sketchfab’s VR features. The creativity and the passion of the WebVR community has been incredible!

Those of us who have been defining and implementing the API feel a responsibility to make sure that it keeps pace with the current state of VR hardware and software. That’s not always easy with the breakneck speed with which the field has been evolving, and as we look at the API as it exists today there’s some significant disconnects from the realities of modern VR.

A quick refresher about how we arrived at the point that we're at now: When WebVR was first conceived by Vlad Vukicevic (April 2014) Oculus had just barely announced the DK2 and the only VR headset most people could get was the DK1. The Vive, 6DoF controllers, Hololens, and GearVR were still behind closed doors at this point. Cardboard had only just been announced when we first started making builds available. The APIs used to interact with the hardware that was available looked very different than it does today. That’s why in my initial blog post about the API I said “Keep in mind that these interfaces absolutely, without question, WILL change”.

We’re taking that sentiment to heart, and in the interest of keeping WebVR relevant and (hopefully) a bit more future proof we’re proposing some major, backwards-compatibility-breaking changes. You can see the new proposed spec here, but I wanted to cover some of the changes in a bit more detail and go into the rational behind them.

Bringing VR to Chrome

[Update: WebVR has evolved quite a bit since this post! Read about the latest changes.]

The Good Stuff

Let's get all the links out of the way upfront, because that's what you're really here for, right?

WebVR-enabled Nightly Chromium Builds
Go here for builds

Source
Chromium WebVR experimental branch

Demos (Should work with Chrome and Firefox's WebVR implementation)
Quake 3 level renderer (Source) - Click the "VR" button in the lower right
WebVR test page (Source) - Simple test apps

Related Links
blink-dev "Intent to Implement WebVR" thread
Vladimir Vukićević blog post about Mozilla's WebVR implementation
web-vr-discuss mailing list - If you have feedback about WebVR in general, this is the place for it
Chrome WebVR bug tracker - If you have issues with Chrome's WebVR implementation, log them here.

WebVR: What it is and what it isn't.

To start out, I'm going to highly recommend that you go read Vlad's blog post about Mozilla's WebVR plans first. Chrome's current implementation is very close to Firefox's, so it doesn't make sense to re-state what's already been written. (I'll discuss the differences in implementations in a moment.)

Crowdsourcing Unreal Tournament

I spent an awful lot of time from my middle school years forward learning everything I could about the mechanics of making video games. The goal being, of course, to make my own. And not some silly small asteroids game or anything like that. No! I wanted to build Shooters and Platformers and RPGs. The epic kind! With lots of story and cut scenes and hours of gameplay in massive open worlds! (Ah, the joys of blissfully and unknowingly throwing oneself at impossible tasks.)

As you might imagine, I failed spectacularly at this effort. Luckily for me I never quite viewed it as a failure. It was just a matter of not yet knowing enough about subject X or software Y or technique Z. So my quixotic quest actually propelled me to learn a tremendous amount about programming and graphics development and all manner of related subjects, a fact which I am enormously grateful for today as it has directly led to my current employment. And even today I still have a tendency to chase after projects that are too big for me to reasonably handle in the free time I have available. But that's okay, because this is one of those cases where shooting for the moon really can land you among the stars, and it gives me a wonderful excuse to try all manner of fun, crazy things that would never come up in the course of my day-to-day job but still prove useful anyway.

Given this background, I couldn't help but feel the tiniest bit sad that Epic didn't announce their latest engine pricing or their new crowdsourced path for the next Unreal Tournament about 15 years earlier. Teenage me would have been all over that! I spent a decent amount of time hacking with the Quake 3 SDK and other similar code bases, mostly in an effort to learn more about how they worked and how "real" programmers did things. The idea that I could have access to the full source of a modern game engine for a few dollars a month would have been a dream come true! And beyond that, the fact that I could have not only watched but participated in, from day 1, the development of a AAA game would have probably killed me with giddiness. That was exactly what I wished I could have back in the day: A perfect little portal through which I could view the professionals at work creating something real, large, and "cool". I think I would have poured many weeks of my life into following the project and trying to contribute in any way I possible. (I shudder to think of 15 year-old me's code actually ending up anywhere public though. I was better than a lot of people gave me credit for at that point but I wasn't nearly as good as I thought I was.)