WFang :
So if it adds 6 to 11 ms of additional latency, it ranges from 'nearly impossible' to 'impossible' to render at 90Hz? What am I missing?
The amount of time to transmit an image to a screen doesn't necessarily limit the frame rate. The computer doesn't have to wait for one frame to be completely drawn onto the screen of the headset before it can send the next one. In this case, for example, the system might spend several milliseconds compressing the current frame, a few more transmitting it, and then another few milliseconds uncompressing it on the headset's end. While the headset is uncompressing one frame, it could be receiving the next. One frame doesn't have to be completely out of the transmission pipeline before the next enters it. Of course, you'll still want to keep the latency as low as possible, since if there's too much delay it could make people nauseous, though presumably such a device could use onboard hardware to pan and scale the image after it's received it to better match the headset's current positional data.
Jeremy Cox :
Case in point, most people don't notice 30ms of lag in online gaming.
That's not exactly a good comparison, since games perform various lag-compensation techniques to hide latency. Your own movements and actions in an online game shouldn't show any additional delay at all, since the game doesn't bother checking with the server before updating those kinds of things on your end. Even for the movement of other players, well-designed netcode will use predictive techniques to estimate what their approximate position should be without having to check every frame, then adjust for any discrepancies as seamlessly as possible as their actual location data arrives. This tends to hide network latency pretty well most of the time, though sometimes those guesses can be slightly inaccurate, resulting in situations where it looks like you shot a player, for example, but they don't get hit, or where the hits from a player shooting you don't register until you're already behind cover. You might not directly see this latency, but that's largely because the game is doing its best to hide it.
Sixa isn’t stopping at local server-based VR experiences, either. Minchenko’s ultimate vision for wireless VR includes offering a PC-free solution for people who don’t have a VR-ready machine and don’t want to invest in one. Sixa plans to expand its cloud-based desktop computer service to offer VR gaming over Rivvr-equipped headsets. Theoretically, you wouldn’t even need a computer in the house--just a Wi-Fi connection and a Vive.
Now this I would be a bit skeptical of seeing pan out, at least any time within the next several years or more. In order for this to work, you would need really low latency to the render servers, since on-headset adjustments to the video feed can only go so far. The latency would really add up between not only the time it takes to transmit the video to your headset, but also for the headset to transmit its positional data to the server. The servers would likely need to be located near your town, and aside from in some urban centers, that would be difficult to accomplish. Existing game-streaming services introduce enough delay and compression artifacts to make even traditional games somewhat uncomfortable to play, and those issues would be greatly compounded in VR.
Facebook
Twitter
Instagram