WebGPU/glTF case study

Over the last year or so I've been working on Chrome's implementation of the new WebGPU API, a successor to WebGL based on more modern graphics API patterns. While working on the API I've also been busy building a lot of demos and other community resources with it, and one topic has been brought up by people I've talked to probably more than anything else: How do you keep the API state manageable when loading something like a glTF model?

So I wrote about it!

If you're interested in WebGPU, glTF, or simply graphics on the web, check it out!

Efficently rendering glTF models: A WebGPU case study 

WebXR Scene Optimization

I posted a walkthrough of some basic steps for optimizing scenes for WebXR/WebGL on GitHub. Take a look!

https://toji.github.io/webxr-scene-optimization/

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.