Slashdot Mirror


Virtual Reality Tech and Openness

An anonymous reader writes: An article written by Kyle Orland looks at how the nascent virtual reality industry will handle openness — in terms of standards, platforms, source code, and development. "Whether any single VR platform is 'open' or not, though, may be moot if developers have to juggle countless slightly different development standards for countless slightly different VR platforms. In a way, making a PC game that only works on the Oculus Rift is as ridiculous as making a PC game that only works on Dell monitors." Right now, the major players in VR tech are using different approaches. Oculus is distributing a closed-license SDK. Valve is setting up a more open platform that lets multiple manufacturers build devices for it. The downside is that it doesn't seem to work as well, particular with Oculus hardware. Oculus founder Palmer Luckey says standards are going to take time and cooperation. Of course, that tune may change when devices start hitting the market.

25 comments

  1. Missing the point again... by houstonbofh · · Score: 3, Insightful

    They want to lock down standards and own the market. But the market will go to the standard with the most support, and open standards have a way of doing that better. That is how the PC won, even if IBM didn't. I am betting Google or Steam may end up the dominant player.

    1. Re:Missing the point again... by janoc · · Score: 1

      It is more likely that none of them will be dominant, because when you have 2-3 players that refuse to talk to each other to even establish common APIs to handle the basic tasks like tracking or renderer integration, many game studios will just say "Meh, screw it". And they will remain sitting on the fence instead of pouring money into a niche product that requires very significant technological and content investment. And with little reasonable content beyond bite-sized demos nobody will buy the HMDs neither. That's the real issue.

      And yeah, of course, the rush to claim possible walled gardens so that they can play Apple and extract toll from both developers and users - Valve with Steam, Oculus with their Market or what it that thing called, Samsung has its own, Sony for sure is preparing its own for their PS4 platform, Google with Google Play, etc.

      Without at least some sort of standardization and simplifying the integration of the HMDs into graphic engines this is a nonstarter and could bury the technology before it even had a change to take off. The direction e.g. Oculus is going in is pretty terrible - every release of their SDK is more closed than the previous one, more invasive and complicated integration-vise. Guess why only is it that only Unity and Unreal have somewhat usable Rift integration - and good luck making things actually work with Unreal. It feels very much like unfinished alpha with tons of problems and issues, despite Oculus engineers actually working on it.

      I have told John Carmack that they have blown a huge chance to establish a defacto API standard for interfacing to these HMDs with their SDK. And that was before it was announced that they are abandoning the non-Windows versions and taking the code completely proprietary.

    2. Re:Missing the point again... by Anonymous Coward · · Score: 0

      How, exactly, is a non-stereoscopic HMD any different from any other display in terms of video interface? A standard DisplayPort interface should be just fine (overkill, actually) to drive the video output to the HMD. Perhaps something like Thunderbolt is better suited to it overall, since it integrates DP into a two-way protocol. That would allow the sensors to report back as input devices over the same bus as the video feed.

      As for making it stereoscopic, that's not rocket surgery either. The HMD, if properly designed, has a physical eye-spacing measurement. This could be used to calculate a pixel offset for stereoscopic imaging. Your full framebuffer would be the width of each eye's screen plus the offset, based on that eye-spacing adjustment, possibly with the addition of a software adjustable "comfort factor", plus a slight margin to keep things from getting too close to tolerance limits and giving the user headaches. This would be fed to each eye's display separately, as a "virtual desktop" (which has nothing to do with desktops and everything to do with a clipping rectangle). From there on out, it's all hardware build quality.

      This really isn't that hard. So at most, it requires some underlying changes to how operating systems and their compositing engines handle video internally. (And it likely doesn't even require that.) And then it might also require a new HID class driver for the specialized sensor input. Then it requires these things to be piggy-backed across a single data bus, one which already exists and is in fairly widespread use. It sounds like a small pile of already-solved problems to me.

      How and why this requires a shit-ton of special SDK's, I don't know. I think they're just overcomplicating it because they can.

    3. Re:Missing the point again... by Anonymous Coward · · Score: 0

      Please use more acronyms.

    4. Re:Missing the point again... by Anonymous Coward · · Score: 0

      See also Glide vs OpenGL.

    5. Re:Missing the point again... by hitchhacker · · Score: 2

      You completely left out the difficult parts of the Oculus SDK like corrections for lens distortion and chromatic aberration. Their SDK also does a ton of work when your app can't meet the 75 fps vsync target of the hmd and starts doing its "time warp" frame interpolation based on current head orientation. There's a hell of a lot more they are planning before the final release next year with things like layers for distant objects which shouldn't need to be rendered twice and their custom spatial input controllers.

      There's OSVR.. though it appears that they are doing the lens correction via shaders and I don't think they have a driver for the Oculus head tracking yet. I build against the Oculus SDK 0.4.4 on Linux because that's the _only_ thing available to me right now. If only I had the luxury of choice.

    6. Re:Missing the point again... by GuB-42 · · Score: 1

      See also Glide vs OpenGL.

      Good analogy.

      At the time Glide was still relevant, OpenGL was designed for expensive workstations and supported plenty of features like geometric transforms and lighting. Game oriented GPUs couldn't do this in hardware and software emulation was painfully slow. As for Direct3D, it was a massive PITA for developers and wasn't that efficient either.
      This is the reason why 3Dfx made Glide. It was a thin layer that is sufficient for the developer to use all the hardware features without hassle but nothing more. For instance there was absolutely no geometric computations. As a result it was very efficient. Its popularity declined as CPUs and GPUs became powerful enough to fully support OpenGL. The original NVIDIA GeForce, which could do geometry in hardware, was the killing blow.

      How it applies to VR ? VR demands low latency. And abstraction layers, which often form the basis of open standards, tend increase latency. That's why manufacturers turn to proprietary APIs that are strongly tied to their hardware, like 3Dfx with Glide. Maybe, when we have something that works really well, they will think about standards.

  2. X3D ?? by davemurphy · · Score: 1

    there are a number of well established Web3D/VR standards.
    The two that come to mind are X3D (successor to VRML) and WebGL:
    www.web3d.org and www.khronos.org/webgl/

    rgds Dave

    1. Re:X3D ?? by Anonymous Coward · · Score: 1

      Shh, it sounds like you're ignoring the claim that this is a new industry and things are really just about to take off, just wait for it! Any day now! Really! Soon!

    2. Re:X3D ?? by janoc · · Score: 1

      None of which actually addresses any of the needs these companies have.

      Even COBOL is standardized - and that is about as relevant as X3D or WebGL to supporting a Rift-like HMD or some sort of interaction device that isn't a keyboard/mouse.

  3. History by Anonymous Coward · · Score: 0

    OK, look at the companies competing, look at their history.

    They love inventing their own closed standards that no one else can access.

    1. Re:History by Anonymous Coward · · Score: 0

      This will be the reason they will fail though. Open standards will prevail

  4. Aaaaaand, the wheel will be invented.....AGAIN! by Anonymous Coward · · Score: 0

    This industry, perhaps even humanity as a whole, has no collective memory whatsoever.

    So, what will happen is that everybody will do these embrace-extend-extinguish tactics that Microsoft used in the early days. The market will be flooded with essentially proprietary, "closed source" systems and SDK licenses, and only the big boys get to play.

    Then, lo and behold, somebody will discover standards that already exist (thank you, user davemurphy), and there will be a mass epiphany (ala latter day Microsoft) a proletariat "maker", "Indy" movement will spring up and begin to flourish, the companies will suddenly notice all the money they left on the table, and they will make a big ballyhoo about playing nice with standards and open sourcing everything, ...blah blah blah.

    If we already know how this ends, can't we just start from there already and save everybody YEARS of work? PLEASE??? Oh wait, that wouldn't allow enough time for a select handful of individuals, who were in the right place at the right time to become multi-gazillionaires. Puh, what was I thinking.

  5. "Open" standards aren't necessarily truly open. by Anonymous Coward · · Score: 0

    We don't have to look far to see how what are called "open standards" actually aren't open at all.

    Let's start with modern Web standards. They're paraded around as some of the most "open" of the open standards. Yet realistically, unless you're directly affiliated with one of Google, Mozilla, Microsoft, Apple, and maybe Opera, you won't really be able to have any meaningful impact on the standard of these directions.

    That's not "open" to me!

    It's similar when it comes to Linux init systems. Systemd is now the standard init system on the major Linux distros. Even though it is open source software, it's still not the kind of standard that its users can have much say over. The vendor decides how it's going to work, what it's going to do, and everyone else who uses it has no choice but to submit to it.

    I'd only consider a standard open if it was possible to contribute to it like it is possible to contribute to Rust. It has almost 1100 contributors! That is openness! Average users can really make a difference when they contribute to Rust.

    1. Re:"Open" standards aren't necessarily truly open. by plover · · Score: 1

      ...unless you're directly affiliated with one of Google, Mozilla, Microsoft, Apple, and maybe Opera, you won't really be able to have any meaningful impact on the standard of these directions.

      That's not "open" to me!

      Of course they're open to you, in proportion to the value of your contributions. Let's say you invented something brilliant, like the <blink> tag. If you can't convince someone on the Chrome team it's a good idea, and you can't get Mozilla to adopt it, you can try asking at Microsoft. If they don't bite, perhaps Apple will. And if none of them think your idea is worth supporting, you can contact members of the standards committee directly (their names are public.) You can even attend a meeting of the standards committee and submit a proposal. But why should they spend a lot of time listening to you, if your idea isn't worth anything to the other players in the market? They're already busy codifying the changes actually implemented by Google, Mozilla, Apple, and Microsoft.

      --
      John
    2. Re:"Open" standards aren't necessarily truly open. by Anonymous Coward · · Score: 0

      You sure used a lot of words just to say, "You're right, they aren't actually open standards."

  6. History... by Anonymous Coward · · Score: 0

    In the early days of the PC market, you actually did tend to write for a specific monitor. More precisely, you had a standard for the hardware interconncetions.
    You had MDA, CGA, then EGA, then VGA. Parallel to that you had the Hercules graphics. After that you began seeing many SVGA adapters and the standards began to become more important. In the meantime, not all monitors could connect to the same device. The MDA, CGA, EGA, and Hercules all had the same kind of connector, but not every monitor could support all of the modes. The VGA and SVGA had different connectors. You often found that WordPerfect, Lotus 1-2-3, and CAD programs would include drivers for the graphics cards explicitly because DOS did not handle graphics.

    Now we are in the early days of VR. I expect something similar to happen in which a "killer app" for VR will have drivers written for it by the graphics companies selling the VR technology. As the field matures, it will standardize on particular resolutions, color depths, refresh rates, etc. When standardization comes, you still might have different platforms, though (you could hook your Dell monitor to a cable box or an X Box and both will display, but the content and how it got there may be different).

  7. Re: "Open" standards aren't necessarily truly open by Anonymous Coward · · Score: 0

    Fuck systemd

  8. Re: "Open" standards aren't necessarily truly open by Anonymous Coward · · Score: 0

    Dump Linux bc of systemd forced march

  9. REALLY??? by Anonymous Coward · · Score: 0

    No mention of OSVR.

  10. Standards? We got a million of 'em! by fustakrakich · · Score: 1

    Price. That is the standard. Most people won't look beyond it, and will gladly accept inferior tech.

    --
    “He’s not deformed, he’s just drunk!”
    1. Re:Standards? We got a million of 'em! by Anonymous Coward · · Score: 0

      Developers will choose open standards. Same way no one likes physx

  11. Obligatory XKCD by Anonymous Coward · · Score: 0
  12. It's as ridiculous as... by Anonymous Coward · · Score: 0

    In a way, making a PC game that only works on the Oculus Rift is as ridiculous as making ax Xbox game that only works on Xboxes.

  13. Open is bad for big money. by Anonymous Coward · · Score: 0

    This is no different than the PS4 and XBONE. Both run a crap os on similar crap hardware, where the generation before that had 2 completely different sets of metal and language. Developers still had to port games. Now, while the 2 consoles are still slightly different from eachother, they are close enough that platform exclusives are far less likely.

    Why can't there be 3 or more VR sets to choose from? Sure some devs will like working with vr set X over vr set Y, just like some developers like working with Nintendo and some would rather fall off a cliff. That's competition for you, baby.