Dev update #30

In this blog post you can read about our recent developments in area of NOLO VR integration. We also talk about 1.3 which enabled everyone to integrate 3rd party trackers and included some SteamVR driver improvements.

We also try to explain problems that caused sound streaming (now scheduled to be released in beta channel on July 4th) and other updates to be delayed.

---

NOLO performance and wireless mode

There are two ways NOLO VR can work with VRidge. Currently only one is avaialble.

1. PC-based.

NOLO VR tracker is connected to the PC USB. It communicates with NOLO VR driver and runtime software. The NOLO VR software then communicates with RiftCat or SteamVR directly to provide absolute tracking data of headset and controllers.

2. Android-based.

NOLO VR tracker is connected to the Android USB OTG. In this scenario Android device is the host and it can communicate with tracker hardware to get tracking data of head marker and controllers.

Currently only #1 is implemented which is a bit limiting. The biggest downside is that you need to be cable-connected to your PC. We also don't control the software part of the process, we rely on NOLO VR software to tell us everything and we directly forward all the data into VR runtime. This is also limiting in terms of latency optimization because we don't communicate with the hardware directly. We also can't optimize CPU usage. We basically can't do anything other than listening to tracking data provided by NOLO VR runtime. Is has an ability to fully control rotational and positional tracking of HMD and controllers.

With #2 option we will be able to ask hardware directly for its sensor data and process it on our own. It should be lower latency and (depending on their hardware) very light on Android CPU usage. We haven't started working on it but we want to explore this scenario to find "the best" NOLO VR experience with RiftCat. This has a one downside though. The tracker will be connected to Android, making it fully wireless solution, but you lose ability to USB tether the stream connection.

We might try to re-implement #1 with a more direct approach (where our software queries their hardware directly instead of leaving all the comms to NOLO). It has a potential to be better in terms of latency and resource usage but wireless mode comes first.

Version 1.3 known issues

First days of 1.3 indicated that everything was going well. Shortly after we've started getting reports that some phones can't stream at all. It turns out that Galaxy S5 Mini, Samsung Galaxy Grand Prime, BLU Advance 5.0 (and some other phones using Mali 400 MP4 GPU) don't interpret video stream properly.

Those are not mainstream phones anymore but we had to start investigating the problem anyway because we don't want to leave people behind with each update. We still haven't pinpointed the problem and we'll probably defer the further debugging to 2.0. Version 2.0 will include many changes that include altered stream configs so we don't want to spend much time on this problem now because this will delay 2.0 which may fix it anyway. Version 1.0 of Android app is still compatible with latest desktop client (stable channel) so if your phone is affected - you may download and install it manually to keep using VRidge.

We also found that with 1.3 we broke our Android crash reporting & analytics. We use Google Play Services and its linked services to gather crash reports and related usage data. We rely on these reports to find out if changes we make work properly on all devices. With 1.3 we made crash reports mostly useless because of faulty configs. We tried to fix it and we now released 1.3.3 with Firebase reporting (also a Google service) that should be more reliable for crash tracking.

Virtual driver mode

As a minor change in 1.3 we changed our default SteamVR driver to use virtual display mode. It should have made the experience a bit more smoother. According to user feedback it indeed works better in this mode so we made it the new default. Your RiftCat config automatically switched to virtual display driver in 1.3 update. During the development we found another reason to add gamma slider so we'll most likely include gamma slider in 2.0 update. This will help users with screens that have less than ideal whiteness balance.

Beta & Stable

All of our updates are in stable channel now. This will give us more freedom in testing sound streaming, moonlight mode (and other 2.0 changes). If we break something in beta channel, users will still be able to revert to stable which contains everything we released so far.

VRidge API changes

We are making some changes to VRidge API for next API release.
Serialization will use Protocol Buffers. Reasons for this change are discussed here.
Remote API connections will work. Currently they are bugged (see here for a workaround).

Development status

We recently heard few opinions that we publish so many facebook posts without an actual updates on our side. Social media, support and development is handled by different people. If we stopped the social media activity it wouldn't change anything in terms of development. All the social media posts are our attempt to reach out to a wider audience. Maybe it results in an extra vridge license purchase a day, maybe it doesn't. We are not sure because measuring marketing is hard and we're still learning how to do those things without a huge budget. Coding (and this dev blog) is done by developers, social media is handled by other people. You can easily spot the difference in writing style.

Nonetheless, we still don't release as many updates as we would like to. We often get distracted from our main tasks by things that we cannot control. We rely on many components that often change outside of our control. Each Windows, SteamVr, GPU driver, Android OS (the list goes on) update we study the changes to make sure we will be ready once the update reaches user PCs. We are usually always ready to adapt to new changes but sometimes we need to drop everything and work on some emergency patches.

It's not always bad things that come from outside source. Sometimes a new game comes out that many user really want to try. We then try to make sure it's gonna work nicely not only with premium $600+ headsets but with our little tool too. We sometimes e-mail the developers to ask about their game, learn how its VR mode is implemented. Our goal is to not put any extra workload on the game developers (because they have their own goals - they gotta create the games we all love :). That's why it takes time to sometimes find creative ways to trick the game that "render please, we're totally Vive!".

Anyway, the problem with those things is that each time we drop current tasks to handle the "external event" (good or bad), it delays our plans a bit. Hours add up to days, days add up to weeks. It's also mentally distracting because we sometimes need to work on several totally different things in the same day. You don't need to be a developer to know the feeling that comes when you need to drop whatever you are currently doing to handle some outside interruption. It sometimes takes time time to get into creative zone again, to focus again after spending few hours on something totally unrelated to your original task.

We decided that we should try working with extra devs. We still don't know how well it will work out. We can't afford to transfer a senior developer with 20 years of experience @ Samsung or any other "big" company. They will be new to the system it's gonna take some time to teach them VRidge codebase and the ideas behind it. Nonetheless it's an investment that we want to try because VR is still rapidly changing and the more keyboards we can man, the more updates we'll be able to push. We already started getting our new friends familiar with VR, showing how VR experiences are made and what makes them work the best. We'll have more news in this area soon.

2.0 version will include Moonlight mode, HDMI output and will generally be more stable than currently released version. We'll keep updating you on its progress once we get back to work on it. As we promised earlier - "2.0" version name is only indicative of major codebase rework, you won't need to buy anything else - it will be a free update.

We're far from excited to write a blog post without any actual downloadable feature update but we hope that you can bear with us a little bit longer. Sound streaming is already merged into the main codebase and should be out it less than 2 weeks. After it's published, one developer comes back to 2.0 rework full-time and the other one focuses on wireless NOLO + some extra API changes to accommodate other controller types that are going to work with VRidge.