OpenXR – Cross-Platform, Portable, Virtual Reality | Hacker News Reader

OpenXR – Cross-Platform, Portable, Virtual Reality

khronos.org

184 pointsgnarbarian42 comments

Open articleView on HN

Glad to see Oculus and Valve both on the list of supporters. This is definitely something that was needed.

just a little mad that Kronos' classic naming scheme 'OpenVR' was already taken.

Though if AR features are added to the spec later "OpenXR" will seem less weird.

One of the ways I suggest people think about AR and VR is that -

One of the only significant differences is whether or not the skybox is filled in.

Broadly the technical requirements of the object tracking, 3d visuals and user interactions will be very very similar.

I suspect you'll end up writing applications with basically the same stack once we get there.

Useful applications across both VR and AR are more likely to be holographic in the sense that they are free standing in 3d space and designed to inhabit whatever 3d space WITH other applications.

The current VR "draw the whole world and totally control the ui" is this fields DOS era.

The desire for simplicity implicit in your statement is admirable. Unfortunately it is so simplistic that it ends up getting it wrong, especially if you don't specify which technology emulates which.

For example if you were to say: "To get idealized VR, take idealized AR and make the display opaque." that is a completely different technical claim than "To get to idealized AR, take idealized VR and make it see through." The reason being, the maximum limits of VR are lower than (or rather different from depending on your view) the maximum limits of AR.

Valve offered to donate the name OpenVR if it was needed, but it was decided that since the API will have uses outside of VR (i.e. AR and IR) the more generic name was more appropriate.

What is IR that doesn't mean infrared?

Typo, meant MR, or mixed reality.

Any idea how that is different than AR? Or know any articles talking about the two.

It's an intentional branding effort undertaken by Magic Leap to associate 6DOF HMD AR with the term MR instead of AR - and thus associate only themselves with the term like "Kleenex." Typical propaganda effort. Apparently it worked because Wired picked up the term and others like Robert Scoble did as well. FWIW they failed previously by trying it with "Cinematic Reality," but nobody bit.

The theory is that the term Augmented Reality has too much associated baggage accumulated over the years from implementations that don't do realistic 6DOF.

So they are trying to say - approximately - that anything that doesn't have depth is AR and anything that does is MR.

Graeme Devine made this distinction by throwing shade at the iterations of mobile AR from previous generations that didn't have SLAM or any kind of tracking in a recent talk [1].

In reality MR was defined by Paul Milgram in 1994, and does well to describe the spectrum that encompasses Augmented Reality, Augmented Virtuality and Virtual Reality.

[1]https://www.vrandfun.com/magic-leap-provides-updates-dice-su...

"IR" - for "input reality" - might be a sensible alternative term for this. VR and AR seem to focus on the display aspects, while the likes of Magic Leap are useful in the input aspects (which have their own sets of problems).

You are likely confusing Magic Leap with Leap Motion, which is specifically a tool to aid in Augmented Virtuality.

You're probably right. Whoops.

Ah, as I expected.

The only reference I've been able to find refers to IR as Immersive Reality.

https://www.youtube.com/watch?v=3UQK_ksU3kc http://www.horizonirs.com/vr-ar-ir-mr-vw-hmd-hud-whaaaat-2/

Sony as well was refreshing to see.

Yeah I think that'll make developers lives easier since games developed for the PS can be easily ported to other platforms.

I don't see microsoft anywhere, although I think they'll have to come around since everyone else is participating.

Wouldn't be surprised if Microsoft are working on a VR layer for DirectX 13 to use on Windows and Xbox. Just like Vulkan/DirectX 12.

I wonder why they couldn't do the same thing for Vulkan.

Something that might make you happy is that Khronos already understood that Vulkan alone won't cut it, so they are launching the "3D Portability Initiative".

https://www.khronos.org/3dportability

Lets see if anything will come out of this.

It sounds like a solution to a wrong problem. Why can't Vulkan / SPIR-V themselves be used for that purpose? Building another level of abstraction on top would just complicate things, and for the sole reason of appeasing lock-in jerks. I.e. while it might work, it's a pretty bad solution, engineering wise.

If anything, Vulkan needs simpler APIs abstraction, something higher level that uses common logic for stuff like memory management and etc. That's actually useful. And not spending time on this. But well, Khronos can do whatever they want of course.

And we'll need to wait and see if the above lock-in jerks will decide to participate this time.

It will be refreshing if they actually ship it. Vulkan slides circa 2015 showed Sony participating in that too, and they never ended up implementing it.

Page 13: https://www.khronos.org/assets/uploads/developers/library/ov...

Agreed. Given the current infancy of VR and the fears of incompatibility amongst consumers, it's nice to see the major players set up some stability for the VR space.

Here's a pretty cool interview with Valve's Joe Ludwig on openXR you can to listen to

http://voicesofvr.com/509-valves-joe-ludwig-on-khronos-group...

Very good, but that's just APIs. Now we also need an open runtime implementation for those APIs that will work with common hardware.

We don't even have the APIs yet. Knowing Valve's approach with VR, they are probably going to aggressively pursue OpenXR support.

So far for example SteamVR is tied to Steam. So I'm more interested in open VR runtime, though of course a common and standard API is very good to have as well.

I've never really done anything with VR, but can someone explain why VR seems to so desperately needs a standard/API ?

I've done a bit of OpenGL, and that I can understand needing standardization b/c you're talking to really complicated non-standard hardware and the graphics pipeline is pretty involved. But with VR... aren't you ultimately just outputting 2 warped video streams? I understand you have to talk to the hardware a little bit (to get eye and wand/controller positions) and u need to know lens parameters, but it seems like a very thin wrapper around the graphics API.

Am I missing something?

The video display is probably the very simplest part of the Virtual Reality experience. While it's directly responsible for a large part of the experience, it's not actually what needs to be standardized.

Everything else, from the various ways to perform head and motion tracking, to the myriad of input devices and controllers, varies wildly. Coming up with a standard cross-section of these features that most platforms support seems like an excellent idea to me.

Maybe also audio (binaural), haptic feedback and eyetracking (foveated rendering) could be included.

> a standard cross-section

I don't envy the people doing this, in terms of controllers:

* There's Leap Motion Orion. Plausibly, there is some future tech involving body tracking.

* Valve doesn't know what the final form of the controller is[1], the current controllers are merely one of the better iterations.

* What we don't know.

There seems to be a need for multiple cross-sections. With the current state of flux in the field, I'm expecting controller to be highly vendor-extended.

[1]: https://youtu.be/kMpQWSqQFK0?t=1m9s

are head and motion tracking not inputs to determining the eye position/orientation? Are they things the develop should ever have to interact with directly?

for controllers you will need the position/orientation information as well - but that's not much for an API to do.

Again, I feel like I'm missing something

Name is quite similar to ILM's OpenEXR image format.

I was thinking why they didn't just go with OpenVR, but looks like valve already used that name.

https://github.com/ValveSoftware/openvr

So I don't code, but I have an Electrical Engineering background and a passionate interest in Technology and VR. How can I get involved with this?

Learn the basics of coding - CodeAcademy JavaScript to Unity (major VR support there) I'd recommend.

Why go with an inferior language when you could use C# or C++ instead?

Like JS is well and good for web things but no reason to shove things where they don't belong.

Just note, Unityscript is not Javascript.

"How can I get involved with this?"

I think you need to first specify your intent. Just jumping in because the technology seems cool leaves you short of value adding goals. Where do you want to be if/when VR actually is commoditized mainstream? From point of view of creating things I think there are three categories here

a. creating VR content (content or programs)

b. creating VR hardware and drivers

c. creating VR middleware (game engines, etc)

This seems like a very good thing and has support from the right people (which quite frankly surprises me a bit). The problem/solution graphics are pretty clear and a great way to visualize why this is a good idea. Bookmarked :)

I hope it helps to speed up competition. We all expect VR as the next big revolution but the thing is going too slow..

It's 'X' for EXTREEEEEEME Reality!

Reply on news.ycombinator.com