Last week on Twitter, I mentioned that I would be working on a virtual reality project for a team hackathon at work – the goal of the two day event was to just have fun, learn some new things, and take time to work on projects outside of our day-to-day jobs. Although the hackathon itself turned out to be small and few people actually participated, I got down and dirty with WebVR and got to try out some really interesting things that I had wanted to get proof-of-concepts for.
The original project idea that I had was a delightfully ambitious one, and I admittedly realized that I had bitten off more than I could chew about two hours in. The original idea, using Azure RemoteApp to push Oculus Rift applications to mobile phones via Microsoft Remote Desktop, was cool in theory but proved to be difficult:
- The overhead for publishing an app using Azure RemoteApp was probably a half day project in and of itself, and that’s with access to a really flipping good internet connection to download the Windows Server 2012 R2 .iso file that’s required. Given that the hackathon was only scheduled for 2 days, I decided early on not to take this route but it’s on the back of my mind for a larger project.
- Most desktop VR apps don’t quite play nicely with Azure yet, due to the lack of dedicated graphics and hardware support. There are some Oculus Rift apps that don’t check that there is an HMD plugged in, but because you’re accessing the virtual machine through an RDP client, the graphics streaming tends to not follow through all the way and you’re left with a blank screen.
Following the realization that desktop VR apps were likely going to be a no-go this time around, I decided to use the hackathon to teach myself a little bit about WebVR, which is a pretty new (or at least, new-to-me) API that Firefox Nightly and Chromium have begun supporting to render VR on the web. The new plan was to pull together a quick WebVR app, host it on Azure, and use the Remote Desktop app to access it from my phone.
At this point you’re probably wondering why there’d be a reason for this: after all, VR is natively supported on Android right now, and as I will go into more detail later, the quality tends to suffer through the remote experience – but I wanted to get a proof of concept here, because there are other platforms where VR isn’t supported yet natively (the Oculus SDK, for instance, doesn’t necessarily support Windows Phone out of the box) and browsers tend to have a lot of specific quirks that aren’t always standards-compliant. I’ll be perfectly honest: I just want to learn about WebVR, and I have a soft spot for my Windows Phone, so I wanted a solution that would work for it without having to be building for different platforms. I’ve never tried using Cordova, but the current VR ecosystem is new enough that I have to go through enough abstraction and didn’t want to try squishing that on top of it.
Once I decided to switch gears, I grabbed a couple new browsers and did a bit of digging into WebVR. Right now, there’s a pretty limited amount of information available for developing with the WebVR API, so I started off by following TyroVR’s tutorial and grabbing his Three.js web-vr-renderer from GitHub. It took a bit of tweaking to follow, since the demo project itself didn’t seem to be available that I could find, but after several hours of trial & error & bug-fixing, I was able to get my own version of the demo up and running! You can find it on GitHub here.
The demo itself was the first step – it was running fine in FF Nightly with my Oculus plugged in, but I didn’t want to have to spin up a web server myself so I headed over to my Azure portal and quickly created a site from my GitHub repository. Once that went live, I was free to move about between my Windows computers and my Mac to test it out in different configurations. This was the first time that I had set up my Windows PC for my DK 2, so I spent another hour or so tinkering with the settings to get the demo running on Windows since I had done the development itself on my MBP.
Production setup: Macbook Pro running Yosemite, Firefox Nightly (38.0a1 build), Oculus 0.4.4 runtime
Demo environment: Windows 8.1 Pro running in Bootcamp on Macbook Pro, Chromium browser, Oculus 0.4.4 runtime
For some reason that I don’t yet know, I wasn’t able to get the FF Nightly build to actually find the Oculus Rift on Windows (it worked on Mac), but the same function worked fine on Chromium so I suspect that this is something hidden in Firefox that I can’t quite fix, though I plan to keep trying. When I swapped over to Chromium on Windows, I was able to go to the website that I had on Azure and experience my trippy VR app (with camera tracking!) without a hitch. It was getting closer to what I had envisioned, but I still had one more test: would I be able to see the VR app if I was on my phone?
At the time of writing, there doesn’t seem to be WebVR support on the Chrome or FF Nightly mobile browsers, but I’ve heard it’s on it’s way to the FF Nightly mobile builds (which I am extremely excited about). I loaded up my Remote Desktop app and connected to my Windows PC, tossed my Nexus into the Homido HMD, and…
Out of all my attempts to render a VR application on a desktop and have it stream to my phone, this one was the way that showed the most promise. Wrapped up nicely in Chromium, the web VR app was definitely lagging and the RDP client UI was in the way of a fully immersive experience, but I was finally able to see, with my own two eyes, a VR “app” streaming over RDP. Sure, there may not be a ton of use cases for it yet, and the quality is a little behind, but this is just the early stages of virtual reality and I could not be more excited to see what comes next. I’ll be following the development of the WebVR API closely, and plan on continuing to develop the demo project that I have in more depth in the coming weeks.
*You’ll notice that this is Part 1 of my WebVR Experiments – Part 2, which will be an in-depth technical post about the development process I wrote about today, will be coming shortly!