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.
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.
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".
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.
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.
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.
"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).
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.
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.
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.
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.
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.
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
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 :)
