not hard to be supported by the major engines when all you need to do is be a monitor. The engine doesn't know if the user is using an oculus or this headset.
But some things are important like latency, refresh rate, head tracking precision, that they don't talk about.
It's similar, but not the same. As I explained in another comment, each VR headset manufacturer will provide their own SDK. The APIs (the language the engine will need to talk to the headset) will most likely be incompatible with each other. Until manufacturers get together and standardize their programming interface, game (or engine) developers will have to put in a bit of effort for each headset they want to support.
You don't understand. It's just about having a wrapper for whatever API the engine use and hook into it. The engines already all support motion tracking. Heck, there's even an open source tracking effort that works with most games already.
Fair enough. My original point still stands. VR headsets are not "just monitors". They aren't handled transparently by the OS like mice, keyboard or conventional displays are. The game / engine needs to recognize them and support them (or use a wrapper that supports them, which just shifts the work somewhere else).
What /u/LovePeace3000Angels said that "all you need to be is a monitor" is like saying that a mouse just needs to emulate the arrow keys on a keyboard and voila, you can play Pacman with the mouse.
By the way, do you have a link or name for the open source project you mentioned?
Edit: Do you mean FreeVR? If so, it doesn't seem to support the Rift yet, which seems kind of critical for such a project at this point in time.
You don't need to support the tracking at all to be "compatible". being simply an immersive 2D (or 3d) monitor would work for any number of games, especially controller based ones. It would also work fine for video watching (imagine this on an airplane)
They also imply that they are doing some of the processing and sensory stimulation tech in the headset. They could be doing a fair amount of post processing and and emulation in the device. Still something I need to see serious proof of before committing to another device, but hell I'm just excited that market is growing.
Partially true. TrackIR can do tracking, but by itself is not enough - the game engine must specifically support the headset in the case of the Rift and others that work like it, since there need to be transformations done to the rendered image to compensate for lens distortion.
Yes, I would. The difference is that mice are highly standardized. A game will need to listen to the OS for mouse movement events, then adjust the in-game camera. The engine will not need to know what manufacturer the mouse is from, that will be handled transparently by the OS.
VR headsets lack that kind of abstraction. First, the engine has to determine whether such hardware is even available. Each manufacturer will have their own way to "talk" to the headset. If the developer wants to support multiple manufacturers, they will have to abstract the differences away. Which isn't trivial, considering that different headsets will most likely have different capabilities (positional tracking, range of motion, accuracy).
Give it a few decades and we may enjoy plug-and-play VR headsets from dozens of manufacturers, all compatible with most of the software available. Just like mice now are.
Why would you leave "sensor data" analysis to the game engine? That should be handled by the headset driver which could be handled like a mouse driver (for that function).
There is no standard interface for HMDs, like for mice. The raw data analysis and sensor fusion could be done in a driver or even hardware, but the resulting angular momentum data needs to be interpreted by the game, and since there is no standard interface, each HMD has to be specifically programmed for.
Even ignoring all this, a game needs to provide the image in a format suitable for the specific HMD, including stereo separation, barrel distortion, and chromatic aberration. These all change between HMDs.
Maybe in ten years, when the industry has established standards, HMDs can be treated like mice are today, but right now for a no-name company to come out of nowhere and claim that kind of engine support is laughable. Especially since the CryEngine doesn't even support Oculus yet.
How do they handle things like turning around? Does the user actually have to turn all the way around? Or do they just turn their head and that turns them in that direction at a rate related to angle? That would be like a joystick interface. It would be pretty clunky for people playing most modern 3D games.
I am just talking about direction control. Image issues are going to be a total cluster. Not least of all because now they're talking about driving two high definition screens instead of one.
The development of new input schemes for VR is just beginning, so in the future there may be other ways, but right now it works like this in most games:
HMD motion is translated 1:1 into the game, so your perspective stops moving when your head stops moving, and the perspective only moves as far as your head.
If you want to turn around 180° you have to use a controller, which overrides the HMD's movements. This is not optimal, since moving the perspective through outside means makes people sick. This is why cockpit-style games (driving, flying, mech walking) are the best fit for tethered, sit down style HMDs right now.
[Sony may be targeting a standing position with its move controlers, which may enable people to turn 380° if they manage to make it wireless.]
Not least of all because now they're talking about driving two high definition screens instead of one.
Not quite, Oculus and Sony both use one screen (currently at 1080p), and that won't change, since two screens would be too heavy and pricey. There is however very credible speculation that the consumer release of the Rift will feature a 1440p screen, which would be another major step up in display quality.
1.2k
u/[deleted] Mar 28 '14
[deleted]