Thursday, February 9, 2017

Dev update #27

This post is text only without downloadable updates available in Riftcat client. We want to update you on our current work and talk about the future.


Sideload VR replacement

January ended with very unfortunate news. Sideload VR - a great source for Gear VR prototype apps - announced that it's closing down. You can see Sideload's author reasoning in the announcement post here.

We needed a replacement. First we thought that we will have to write our own repackaging service but fortunately such alternative to Sideload VR already exists. From now on you will be able to find Gear VR version on ConstructVR.

Desktop client links will be updated with next downloadable update.


Slightly over a week ago NOLO VR launched their Kickstarter campaign. We tried the hardware, we have units at our office and we can surely say that it's not a vaporware. It works just as advertised. There is no fake camera work or pre-rendered animations.

We are in touch with NOLO VR team and we are currently working to prepare a software side on our end so their hardware can work out of the box with VRidge. We tried Leap Motion, PSMoveService and other experimental drivers but NOLO VR was definitely the easiest and most reliable of them.

Their goal is to provide end user experience of nearly Vive-level tracking. It uses the same underlying technology (Lighthouse) so the tracking is very precise indeed.

Our goal is to provide a software support where you simply plug their hardware in and it just works. We don't want to make you install multiple layers of FreeTrack/FreePie like software relays. Simply plug it in, start VRidge and enjoy the next level of streamed VR.

VRidge API

While we are implementing NOLO VR support we decided to expand this into another component of VRidge. You can already do a lot with FreeTrack and OpenVR drivers so one could argue that we don't need another standard.

XKCD: Standards
But if you actually tried to use FreeTrack, custom OpenVR drivers and VRidge all together - you might have noticed several problems - black screens, different coordinate systems mixing up, etc. We are now working on providing a unified interface to keep everything loaded as one driver in one 3D space. Here are some key features that will be available with VRidge API.
  • Writing positional or positional and rotational data to override VRidge tracking. Similar to FreeTrack but with an ability to switch modes in real time without restarting VRidge. 
  • Reading and writing all VRidge tracking data before it's used to render a frame. You could use external sensor data and combine them with VRidge provided mobile sensor data to combine both data streams into a more precise measurement. It works in real time with ~0.1 ms response time.
  • Reading data and providing an offset. You could use external sensors to compare its data with phone measurements and provide an offset that corrects drift.
  • Writing OpenVR controller 3D position and button presses with an ability to choose the origin point of 3D tracking.
  • A way to do all of the above remotely. Wireless controllers won't need any desktop relays as long as they have some sort of wifi connectivity. It enables quite creative ideas of using mobile phones as motion controllers, similar to Daydream controller emulation.

The API is currently using ZeroMQ as a protocol. This is industry tested standard used by (according to their website) AT&T, Cisco, EA, Los Alamos Labs, NASA, Weta Digital, Zynga, Spotify, Samsung Electronics, Microsoft, CERN, among others. It allows developers to connect to VRidge API in any programming language easily. It doesn't matter if you use Python, Java, C#, C++, Objective-C or any other supported language (full list here).

We plan to provide samples with sources in Java (Android) and C# (WPF). We want to create a direct connector between VRidge and PSMoveService too because it's very popular and can serve as another example.

Audio and network protocol changes

Audio streaming is done but we decided to refactor networking a bit. Until now we used raw UDP datagrams with frame data but while we were adding audio stream we decided that it's time to upgrade to rUDP. It should reduce artifacting on 2.4 GHz networks. There's no reason to reinvent the wheel so we decided to use ENET. The same library that is used by Moonlight + Gamestream. We hope that retransmission will allow us to smooth out the experience further

Survey results and our next steps

According to our survey 80% of you noticed an improvement when it comes to smoothness in 1.2 update. This is a very good news and it motivates us to optimize further now that we can see that users actually notice not only features but the behind-the-scenes data flow optimizations too.
Here are some more facts:

  • One out of the three people use Gear VR.
  • Majority of people found that HEVC improves the exprience.
  • The most common video cards are GTX 970, 1070 and 1080. Only 20% of respondents used AMD cards.
  • Only 15% of users use WiFi 2.4 Ghz. WiFi 5 GHz and USB tethering are equally popular.

Last but definitely not least - the most important question of all of them. We are creating this software for you and your feedback is the most important factor in our decision making.

You can see raw data above. This is how we see it.

  1. You want a better controller support. We think that VRidge controller API described earlier will be a step in the right direction.
  2. Second most popular option is Fake VR. It was discussed earlier and we already did some work in this area. We plan to resume working on it after controller API, sound streaming and protocol changes are out.
  3. Third is jitter reduction. We hope that improved networking protocol will reduce it further but we still have timewarp on our task board.
  4. Reducing latency. This is a tricky one but time warp has a potential to reduce perceivable latency greatly.

Other answers (10%) contain many sound streaming requests which is already nearly complete.

We now want to finish controller API (#1), sound streaming and networking changes. After we're done with it, most likely one developer will focus on Fake VR (#2) and the other one will start prototyping a time warp (#3 and #4). As an additional step to improve on option #3 and #4 we want to add Moonlight compatible mode eventually.

We recently discussed Moonlight mode on reddit. We want to try time warp first because of reasons described in the discussion but Moonlight & Gamestream are always in our minds as a great example how to stream things perfectly.

We hope that this answers your feedback. Of course all of this can change because we can't predict the future but we hope that no major obstacles appear and we can actually deliver features you want the most.

Thursday, January 12, 2017

Dev update #26

This update took us much longer than expected but we finally believe that we made an improvement that is noticeable and worth giving a shot if you experienced terrible stuttering on your Galaxy S6-7 and some other phones.

We also bring some long term bug fixes like 30 and 60 FPS staying at the actually 30/60FPS, some Redmi Note and Zenfone fixes and several SteamVR improvements. There's an experimental version of HEVC too.

This update is released as version 1.2 (both mobile and desktop) through beta channels. Go to Riftcat desktop settings > Updates and get beta version there if you want to try it out.

Gear VR edition will be updated early next week if no major bugs are reported. We don't have beta channel on Sideload VR so we want to test it for few days on regular Android devices because it's much easier to rollback to stable version with Google Play.


Jitter / stutter improvements

TL;DR: It should be better now, more improvements will come in the future.

This took us a while. The problem first appeared when we released Gear VR edition in September. Some users were reporting various levels of stuttering and frame skips. We wanted to fix it quickly but after we investigated the problem it turned out that the underlying cause was really complex.

We first suspected frames being out of order but after high framerate recording it turned out that it wasn't true. We then investigated frames lost on the network but after adding some extra metrics we found that it wasn't packet loss. All frames were arriving on the phones yet the overall feel was very jittery.

We then started adding metrics and timings for every part of the virtual HMD pipeline. There are multiple places where VRidge needs to wait for something (game, steamvr, encoder, network transfer, decoder, Android vsync, etc.). If any of these components lags for even few miliseconds - it throws the whole thing out of sync.

We found that most of the microstutters came from network and Android decoder. Network micro lags are reasonable because that's how networks work. Android decoder optimization is a tougher nut to crack. It's performance is dependant on installed hardware and there are hundreds of chipset variants. The most annoying thing about is its inconsistence when it comes to decode times. For everything to be fluid, everything needs to take roughly the same amount of time every frame. Decoding time was varying greatly from few miliseconds to 12ms (with random spikes as high as 40). This kind of randomness is very bad for fluid playback.

Usually it's countered by buffering but it's not an option when we are trying to achieve VR-bearable levels of latency. We can't buffer even a second ahead to counter random spikes of interference.

Previously our FPS was stuck at almost 58 FPS. Some people suggested to turn it up to 60 and see if it fixes the stuttering. It didn't because the problem wasn't amount of frames per second. Generally to achieve fluid motion you need both high FPS and proper synchronization and intervals between them. An average of 60 FPS isn't good if sometimes the frames comes in burst of 2-3 at the same time with 30-40ms breaks after.

We decided to rework most of the timing and synchronization that was controlling capture, encoding and decoding. New frame rate is using better methods that combine multiple methods of timing and synchronization into one loop that is now much more accurate. Previously we had an average of 58.582 FPS in our capture and encoding module. Now it's running at 60.073 FPS with proper and stable intervals. This alone should lower deviation from 60 FPS from 2.5% to 0.1%.

Then we decided to rework Android decoding & rendering. Previously if no new decoded frame was ready at the beginning of the render cycle it would skip a frame. We now wait as much as possible for decoder to finish its work before giving up on the frame. You can control it by going to settings and changing frame timing:

  • Prefer low latency (new default) will try to keep the latency minimum but still wait as much as possible for decoder to finish its work.
  • Balanced will wait and buffer up to 1 frame if inconsistent decoding is detected.
  • Prefer smoothness will buffer up to 2 frames.

There are 2 legacy timing modes that are generally inferior to Prefer low latency but we are leaving them because there are 500+ different phone models running VRidge (according to Play Store data) and new modes might not work for someone.

We might make this even more configurable but please give us feedback if you feel the difference between those new timing modes and old ones.

With new timing we also improved 30 FPS mode for low end devices. Previously it would render the game at 60 (58.5 actually) FPS and skip every other frame during encoding. Now 30 FPS mode will slow the game down to 30 FPS. This saves up some CPU and GPU load and allows game to run in a smoother fashion instead of rendering the frames that were being dropped anyway.

This problem was happening across all devices but it was mostly noticeable on Gear VR edition and Google Pixel which use low persistence displays. It didn't look too bad on regular screens because it was hidden by micro blurs and smudges which are common among the regual 60 Hz displays.

This is not the end of our work to counter the stuttering. There are still frame skips and some of them are not avoidable. We cannot control a game that might drop a frame, we can't force network to give 100% of its resource to VRidge and we cannot make background Android apps drop all of its work and give 100% of device power to VRidge. Vive counters this with async reprojection. Oculus has great async timewarp and spacewarp. These technologies increase smoothness greatly and this is something we eventually want to do too. It's not an easy task and it's especially harder because we have to account for variable network latency but this is our goal. It won't come this month or the next one but our goal is perfect smoothness and we want to comes as close to it as possible.

Previous version
New version:

It might be hard to notice on the recording (you can click samples above and slow it down with gfycat speed controls to emphasize frame skips) but you should be able to feel the difference in VR.

VRidge for Gear VR needs an update for those improvements to take effect (sometime early next week).

Google VR SDK update to 1.1

We updated VR backend on Android to the most recent version. It enables some new features but it has some changes you might not like. Google decided to force its UI to be always on so we cannot dim the buttons and middle-screen divider anymore. On the bright side it's a bit dimmer now and it shouldn't be visible through lenses anyway.

New 1.1 SDK brings some new features too. Daydream-ready devices should take adventage of new async reprojection. It's not accounting for network latency but it should lower the perceivable latency by a small amount. Every little bit helps so we are leaving this enabled by default but you might turn it off in app settings by toggling display stabilization on/off. For non-daydream devices this option enables old "shaky" stabilization which works in a different way but it also may lower the perceivable latency too.

Daydream phones will also enter into low persistence VR mode with VRidge increasing smoothness greatly.

Daydream view and controller support is still not available because it requires much more work. We received our Daydream View only few days ago so we didn't have much time to integrate new features. Stay tuned for more Daydream news in the future.

SteamVR improvements

Sometimes we get e-mails about certain SteamVR games not working with VRidge. We always investigate those reports and try to bring compatibility to most titles available on the market. Some people reported Serious Sam VR having terrible framerate which was result of a interaction between the game itself and SteamVR which was happening on 3rd party HMD drivers. We reported those issues to SteamVR and Serious Sam VR devs and the problem was resolved shortly in SteamVR beta and now is also fixed in SteamVR live channel. This also solves Unity 5.5 FPS issues with VRidge. Again, we cannot be grateful enough to SteamVR devs taking all reports and suggestions from both game and HMD developers seriously and solving them very quickly.

Sometimes it's up to us to fix our bugs and add missing features to bring better compatibility. This update brings virtual presence sensor which should prevent some games from pausing thinking that HMD was taken off. We also add opt-in virtual positional sensor. Some games were simply refusing to work without some sort of positional tracking so you can now enter Riftcat desktop settings and turn "SteamVR Fake Sensor" on.

We also updated our HMD driver to the neweset OpenVR standards and fixed one minor memory leak which could end up increasing RAM usage over few hours to gigabytes.

If one of the games below wasn't working for you with VRidge, you can try again today with new beta version: Serious Sam VR, Edge of Nowhere, Herobound and Pinball FX 2 VR.

High Efficiency Video Coding

We're also adding HEVC as an opt-in feature. It's still highly unstable on certain devices so it's not enabled by default. It's currently avaialble only for Media Foundation encoder and GeForce 960 or newer GPUs. It also requires relatively new phone. It works alright on our Galaxy S6 (Exynos chipset).

It doesn't work correctly on our Pixel XL. When the phone receives HEVC frames it simply crashes the phone completely causing a full device reboot. It seems that there's a bug in the hardware codec because no software should be able to cause a hard crash like that. We wlll investigate this further and report it to as a bug if it's not fixable on our side and no workarounds can be developed.

VRidge for Gear VR needs an update for HEVC to work so wait until next week if you want to try it.

Redmi Note 2 and Asus Zenfone 2 fixes

We found a bug that was crashing decoder on Redmi Note 2. It should no longer crash with stream fixes enabled. We also applied workaround for Zenfone 2 suggested by Moonlight dev (thanks!). Intel chipsets should now work correctly on both Android 5.0 and 6.0 without 3s lag.

Minor changes

  • Disabled stream adjustments for Google Nexus 5 and Samsung Galaxy S5. It was sometimes crashing the app.
  • Display stabilization is now toggleable in mobile options. It's a matter of preference so you can now turn it on or off. It's on by default (it was always on before).
  • Changed IPD & Scale adjustment settings icon. New Google VR UI icons cannot be disabled so we had to use something else.
  • Increased maximum IPD by 50%.

What's next?

We are still working on sound streaming and we want to get back to "Fake VR" so you can stream regular games into your Android phone. We suspended work on both to bring improvements described above but we will now be able to come back to new features.

We also have a version that works on some Android 4.x  devices. We asked you to e-mail us if you want to test this version and we have a group of people willing to test it before making it avaialble for everyone. If you sent us an e-mail about it - sorry for not getting back to you earlier. Android 4.x was delayed by this update unfortunately. We will reply to you with a testable version link as soon as we are done making this update "stable enough".

We want to make above changes stable first so please give us your feedback and send bug reports. We have several of the most popular phones among our users and we test all changes on them but it's impossible to predict behaviors on all phones on the market. You can send e-mails to or send us a message or comment through any of the social media channels (Facebook/Twitter/reddit). We always read everything and while it may take some time to respond to everyone - we are not ignoring any of the comments.


Post edit history:
13 Jan 00:00 UTC - Added clarifications about VRidge for Gear VR requiring an update for HEVC and jitter improvements to work.

Thursday, November 24, 2016

Dev update #25

This is quick update to let you know what we're working on. Desktop app will let you know that auto-update is ready soon (version 1.1.3).

Stable update for desktop app (v. 1.1.3)

We're pushing desktop beta updates to stable branch. Everyone will be able to take advantage of software encoder on low end PCs. This is last resort option because this will put heavy load on CPU. You should only use it if you don't have any compatible hardware (recent GPU or Intel Core CPU).

This update also includes some stability tweaks, UI changes, newsletter opt-in and Gear VR edition download button.

Motion controller black screen

Several people reported that black screen no longer happens in Steam VR beta when you use multiple drivers (e.g. VRidge and PSMoveService). Check it out and send log files* if it still blacks out for you.

*vrserver.txt located in Steam/logs (by default: C:\Program Files (x86)\Steam\logs).

Work in progress: sound streaming

The sound streaming work is done on the Windows and networking side. We just need to finish up Android decoding and playback. It's still on track to be released as an update sometime in December.

Work in progress: android improvements - jitter, Android 4.x, HEVC

During our jitter research we decided that it's worth a shot to try synchronous video decoder instead of asynchronous (which is recommended by Google). This will allow for VRidge to work on Android 4.x devices.

Most of the older phones that weren't upgraded to Android 5.0+ aren't great VR devices but there are some phones that have 720p+ display there were simply forgotten by carriers and were left with Android 4.x OS. If you have decent Android 4.x based phone with 720p (or better) display and you want to try VRidge on it - e-mail us at with "Android 4 testing" as subject line. We'll contact you when we have something worth testing.

Creating synchronous decoder as an option forced us to do some refactoring of our decoding & rendering flow. This will make it easier to implement HEVC/H265 coding which is ~40% more efficient than H264 that we use now. This means 40% better quality at the same bitrate. We hope that we don't run into major roadblocks on the PC side. We'll start with NVIDIA GPUs first for HEVC.

We are also in process of getting Daydream & Pixel to explore new VR possibilities on Google's new flagship device but it's too early to talk about the details.

Thursday, November 3, 2016

Dev update #24

Regrouping and reorganizing

You may have noticed that our development slowed down lately so we want to explain why it happened.

VRidge userbase grew a lot during this year. When we first shown our prototype proof of concept in March we expected some people to be interested in beta testing but we didn't expect thousands.
We always love chatting about development, receiving feedback, solving user problems. Our devs were always directly responding to e-mails. This includes feedback, suggestions, bug reports, pc upgrade advice, general VR chat. It was taking more and more of our devtime.

Now VRidge's userbase is approaching 100 000 and the old ways that used to work had to be changed. Even if we hear back only from a small subset, let's say a 3% of our userbase - that's 3 thousand people.

That's why our devs will no longer be the frontline of our support system because it simply takes too much time discussing every single case individually. Our support system will of course continue to work but we'll try to write a general FAQ items on each type of issue so people can fix most of the problems on their own. We'll have a dedicated person handling support tickets that will be communicating with our devs on a regular basis.

Dev note:  We love solving problems directly but this way we'll be able to fix underlying problems faster instead of developing duct-tape workarounds for each invididual case. :) We'll also continue to hang around reddit. We didn't post too much lately but we read every single discussion.

If you contacted us lately and haven't received a response for a few days, don't worry - we'll try to cach up with everyone soon.

We're also reassigning our dev time. Until now we focused 100% on fixing problems instead of adding new features but there's a good percentage of our users running VRidge without any major problems. That's why we'll have 1 developer assigned to fixing problems and optimizing experience (including "the jitter", read more in the last paragraph of this post) while the other developer will work on adding new features.

Sound streaming

If you have decent ac router and non-crowded 5 GHz band you can usually stream wirelessly with quality, lag and reliability comparable to USB cable. Many people asked us for sound streaming for fully untethered experience. Being able to sit down on your couch without a bunch of wires limiting your movement sounds very nice. You will be able to turn it on/off because there's no need to stream another data channel and eat up extra bandwidth if you want to use PC headphones anyway. We want to deliver this feature in December.

PS Move / controller black screen

We tried to fix it on our side. We exchanged our data and test results with PSMoveService contributors but it seems that the problem is not linked to VRidge itself but to the way SteamVR handles multiple drivers. It also happened with Oculus DK2 with PSMoveService (without VRidge) or with Leap Motion + VRidge (without PSMS). PSMoveService on its own works fine. VRidge does work on its own as well. But it seems that when two drivers are interacting with SteamVR together they may randomly "collide" when they try to send messages at the same time. It's a speculation because it's hard to know what exactly is happening because SteamVR runtime isn't open source. You can read full discussion here. We'll definitely let you know if we have more news on this topic.


It's a bit long so there's a short version at the bottom. Scroll down if you want to skip this wall of text.

We tested, we measured, we analyzed rendering with high FPS cameras, we spent many, many hours trying to exclude all possible factors of this problem with various phones and display types. We know that in fact 60 (58 actually but this doesn't change anything) frames are reaching the phone (assuming good connection conditions) but something's not quite right - it feels jittery.

Nearly all (90%) of jitter reports come from S6 & S7 (Exynos chipsets) but there were few Snapdragons reports too. It's hard to tell if those Snapdragons experience the same underlying problem as Exynos devices. Samsung devices also use different type of screen than other mobile phones (AMOLED).

We knew that it's visible the most in Gear VR version but it also happens in Cardboard version on S6 & S7 too. After extensive testing we found that other phones also experience not exactly silky-smooth rendering during head movements but it's not quite as noticeable. It may manifest itself in bluriness instead of jitter.

Human perception is a tricky subject and some people don't see a difference between 30/60/144 FPS. People can play games with lowend GPUs at 20 FPS while some others consider the experience ruined if it drops below 60 FPS. The worst thing about it is that it's hard to objectively judge how smooth our small changes affect the experience. We do some changes, we test them again and compare, we show it to different people but when we try to describe how smooth it feels on a scale of 1-10 we get very random results. We literally have to stare at the distance through the window for a while to "reset" our eyes to see differences between our test versions. That's why it takes so long to achieve the perfect streaming.

We tried to use numeric metrics like FPS or frame latency but even we use high FPS camera to record the screen it's hard to catch everything because human eyes don't see the same way camera does. We don't have a brain refresh rate or eye capture rate. We see motion and we know when it's fluid and when it's not. We can get used to non-perfect rates but some some people may get a headache after a while and that's not something we think is acceptable. We know that even regular VR HMDs can trigger headaches and motion sickness in some people so the problem is not 100% solvable but VRidge has a lot of room for improvement.

Since all of our tools and metrics failed to give our definitive, measurable answer that can be used to compare different versions of VRidge we decided that we need more metrics, tools, numbers, graphs, timings, all kinds of data. We wanted to fix it quickly, to find the the wrong line of code, the mistimed part of the pipeline but it seems that there's no magical, easy way of "fixing" it.

With one of our developers assigned to new features and one free to dig deep into the VRidge internals, we think this approach will be the better way of handling the jitter problem. It takes more time but this we can do it the right way instead of the quick way, which doesn't always work. Will it work? We very much hope so.

You can think of VRidge as a street between two points - your phone and the PC. The problem is that there's a bunch of intersections - sensor reading & fusion, sending sensor data, SteamVR/Oculus driver interaction, game capture, encoding, sending, transmission error concealment, receiving, reconstructing, decoding, rendering. A small traffic jam at any of those intersection can stall the whole flow. Cities have cameras to monitor traffic flow and to optimize urban planning. We need similar tools monitoring flow at each part of the pipeline.

We found one thing that can possibly reduce jitter a little bit in non-GearVR Android version. This will be probably pushed to beta Android channel next week. It's the first step of fixing the problem but definitely not the last one.

TL;DR; We didn't find a quick solution for old problem so we took the long way to diagnose them more thoroughly. Some of you are quite happy with current version. so we're splitting devtime 50:50 with 1 dev assigned to new features and 1 to optimize and fix old problems.

Friday, October 7, 2016

Dev update #23 - After the storm

What happened 

On October 4th an update was released to SteamVR. It included changes in direct display driver component which is utilized by VRidge. The changes weren't documented/reflected in OpenVR interface. We've seen those changes in SteamVR's beta channel and after it started flickering there (few weeks ago) we posted the issue to SteamVR forums. An unfortunate series of events caused this changes to go into live SteamVR channel anyway. 

The result was preeeeetty bad. Everyone experienced flickering in random intervals making VRidge totally unusable with SteamVR. Less than 1 hour after the changes went live we contacted SteamVR team through more channels to ask for help.

The SteamVR team was very responsive but it takes some time to update the live system. We were amazed that they pushed the update with a fix into their live stable channel on such short notice (everything was fixed in less than 24 hours). Some companies attempt to wall themselves off from 3rd party support and modding but Valve is doing the complete opposite with this kind of open attitude. We always recommended OpenVR/SteamVR for aspiring VR developers when they asked us how to start VR gamedev and we will continue to do so. It's nice that some companies care about VR's future overall. 

What we learned

It's hard to have a system working 100% of the time when it relies on multiple 3rd party components (SteamVR, GPU drivers, Windows version, OS components, router config & rules, Android OS flavors, phone chipsets, Direct3D, etc). It is difficult, but there are still ways to mitigate the critical situations like this.

We will add some sort of emergency alert to the desktop client so we can notify about the possible compatibility issues. Sometimes all you need is to update some 3rd party components (like video driver) and everything starts working again. We can write this kind of important updates on our blog/facebook/twitter but over 90% of our users stay in client without checking the social media. A simple way to push a message to the client from our servers with a link to a detailed article can do wonders. Many other companies already have something like this ( or LoL launchers come to my mind). 

We will also follow SteamVR's beta updates more closely now. If there's a chance of this kind of stuff happening again we'll start preparing alternative fallback ways. There is a way to capture SteamVR game surface with a slightly increased latency that could have worked even after the Oct 4th changes. Degraded performance while we are working to fix it "the right way" is better than app not working at all.

What we were doing in September

We've been working on behind-the-scenes modules and refactoring some code. This is in preparation for future Android 4.x version and iOS. This also allows to see clearer performance picture which is very helpful to locate Android performance problems (Samsung jitter mostly).

We were updating part of the platform so we can add more servers. Currently all our online service are running on single machine which works well enough but it sometimes need maintenance/updates or simply just fails due to some unforeseen event. Having one more gives us some more breathing space. 

What's next

It's been a while without a feature update. There are a few unsolved problems that we are prioritizing now - Samsung jitter issue and motion controller black screen. Planned features are fake VR (playing regular flat games in VR), sound streaming and iOS version. We want to squeeze in an updated video encoder (H265/HEVC, double the performance of current one) somewhere in the meantime.

We know that some of you really want to know when we'll add those but giving ETAs often causes devs to go out of our way to meet the deadlines instead of doing things "the right way". This can work short time but over a longer period it leads to spaghetti code and long terms bugs that are hard to fix. All we can say is that our current short term priority is Samsung jitter & motion controller black screen and we really hope to see progress on these in October.

Wednesday, October 5, 2016

[Resolved] SteamVR broken after Oct 4 SteamVR update

Problem is fixed

Many thanks to SteamVR devs who were very helpful and responsive during past 24 hours.

All you need to do is to update your SteamVR to the latest beta. Right click SteamVR in Steam library -> Properties -> Beta -> Select "SteamVR beta" in the dropdown box.

The fix is live in stable SteamVR update channel! Let your SteamVR install any pending updates and you're good to go. You might need to restart Steam to get latest updates.

After latest SteamVR update an important component stopped working in SteamVR. New SteamVR version is using undocumented closed code which broke VRidge.

We are surprised that they pushed the beta runtime into live channel without updating their documentation first even after multiple developers* reported the problem to Valve as compatbility breaking.

It's hard to fix a problem without proper documentation or at least an explanation what changed inside the black box. We'll continue to search for a quick workaround. We'll also try to reach out to SteamVR team through more channels than we already did.

It's middle of the night here and I don't have all the information yet.  This post will be updated with more news as soon as we know more.


Past updates:

Update @T+30mins:
We received response. SteamVR beta update with a fix should be available this afternoon or tomorrow (Seattle time). Switch to SteamVR's beta channel to make sure update is installed as soon as it's available.

Update @T+60mins:
SteamVR beta update is deployed. We are investigating remaining compatibility problems.

Update @T+80mins:
The problem still occurs but the characteristics changed. We are trying to find out why the new version still has this issue.

Update @T+120mins:
Many thanks to Valve for quick updates. They are investigating update changes further.

Update @T+12 hrs:
We're eagerly awaiting Seattle office hours to hear back from Valve. In the meantime we're trying to develop an alternative capture method that doesn't rely on direct mode driver compatibility.

Update @T+18 hrs (Oct 5 - 10:00 AM PDT, 1:00 PM EDT, 19:00 CEST):
The problem has been escalated further by SteamVR devs. We are thinking about creating temporary SteamVR driver rewrite but we're still estimating the scope of work needed to do so. We updated our main site with a site-wide notification about this problem.

Update @T+20 hrs (Oct 5 - 12:00 PM PDT, 3:00 PM EDT, 21:00 CEST):
An update has been released to SteamVR's beta channel. After updating SteamVR the issue should be resolved. Both Riftcat beta and stable channels seem to work correctly. We're running some more tests to make sure everything else works fine.

Update @T+22 hrs (Oct 5 - 2:00 PM PDT, 5:00 PM EDT, 23:00 CEST):
The fix is live in stable SteamVR update channel! Let your SteamVR install any pending updates and you're good to go. You might need to restart Steam to get latest updates.

Friday, September 9, 2016

Dev update #22 - Gear VR first release

Update: If you experience jittery streaming on your Samsung device, see this topic:


Gear VR edition is out! You can now download and install it and use full power of your Gear VR sensors. Scroll down for instructions and known issues.

VRidge for Gear VR

Yesterday evening our submission was approved at SideloadVR. Even without a blog post or Facebook/Twitter update some of you found the app minutes after it became available. It had several hundred downloads after few hours. It's amazing how fast you guys are!

It's the first version and some bugs are present but we'll keep bugfixing everything as soon as we can. The first bugfixing update (version 2) should be available shortly after this post is published. 


You need SideloadVR which repackages VRidge .apk file for every user individually. It's needed because you can't easily install 3rd party Gear VR apps from outside of Oculus Store.

Remember that you need to turn Gear VR service back on (with CB enabler or any other app you used to disable it) if you disabled it to use your Gear VR as cardboard viewer. If you don't do it, no Gear VR apps will launch (tapping icon will not open anything).

Short version:
  1. Install SideloadVR and run one-time configuration.
  2. Install VRidge for Gear VR
  3. Start VRidge for Gear VR from your app drawer and pair it on the desktop side.

Detailed instructions:
  1. Install SideloadVR on your Samsung device
  2. Follow in-app introduction to complete one-time setup
  3. Go to Browse Marker in left drawer menu.
  4. Find VRidge for Gear VR by RiftCat Sp. z o. o. and install it by clicking top right button.
  5. You will see Android app installation popup. Some Samsung devices may treat unknown apps as unsafe and you might need to confirm it multiple times that you want to install the app.
  6. Launch the VRidge for Gear VR app in your Android app launcher.
  7. Pair it with desktop app (same as the regular app - full instructions here)

Known issues

Entries marked with * should be fixed with version 2 released today.

*Double vision / lack of stereoscopy

Few people reported double vision because images are aligned incorrectly. Some of you noticed that the picture is not stereoscopic. You're right, the first version has left eye duplicated twice on the left and right side. This should be fixed by today's update. We were playing around with stereoscopic/monoscopic views and somehow we pushed the wrong version into release channel. Sorry!

*App treated as unsafe by Samsung

Some Samsung Android OS versions were showing big red warning that app is unsafe and you shouldn't install it. We removed some permissions and the warnings should be gone. The permissions were there because Cardboard SDK needed them.

*Green/garbled stream 

Some of you reported that they can't see anything because view is all messed up. This happens on beta version of VRidge Cardboard app too and can be fixed by disabling automatic stream fixes in mobile settings. We're disabling this by default for Gear VR edition since Samsung devices handle stream without any problems anyway and don't need those fixes - "if it ain't broke, don't fix it". Hopefully disabling those fixes won't cause any problems. We might need to add per-device user switch if it does.

Latency / delay

Some of you reported unusually high latency. Delay will be obviously bigger vs regular Gear VR apps because we need to stream frames from the PC but it should be still in comfortable range. If you experience large delays please e-mail us at and include your Samsung model number and Android OS version. You can it in Settings -> About phone screen.

We will keep tuning the prediction values to reduce the latency. We might need to find the right balance between jitter and floatiness/lag. If you find the current experience comfortable, shoot us an e-mail and describe how it feels. If you give us enough feedbacks we might introduce some default presets + extra sliders so people can fine-tune the tracking.