Friday, September 9, 2016

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.

Friday, April 8, 2016

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.

Monday, February 29, 2016

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.

Wednesday, July 2, 2014

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

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.)

Sunday, May 11, 2014

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.)

Saturday, March 29, 2014

Oculus, Facebook, and the dreaded "Ecosystem"

It's taken me several days to get over my knee-jerk, emotional, Vader-esque "NOOOOO!!!" response regarding Facebook's purchase of Oculus. I wrote up a "Please cancel my DK2 pr-order" email immediately after hearing the news, but resisted hitting the send button because I knew that anything I did at that point would be out of spite and not because I truly no longer believed in the product. Now that I've had some time to think on the matter, though, I feel like I can actually enumerate my concerns pretty clearly.

Friday, February 21, 2014

Xbox One controller in Chrome on OSX

I've been working lately on better Gamepad API support in Chrome (call it my "20% project"). It's been a fun change of pace from WebGL, primarily because it's much more straightforward code. In the process of learning the ropes, I decided to try something a little crazy: I noticed that our code path for supporting the 360 controller on OSX didn't rely on any drivers, but instead used IOKit to parse the data packets manually. (Check out that code here.) So I figured, hey! Why not try the same thing with the Xbox One controller, ignoring the fact that it's currently supported on exactly zero non-console platforms.

Somewhat unexpectedly, it really wasn't too hard!