I’m sure you all saw the news, but Vavle has their own VR headset coming:
Considering the companies behind this project (HTC & Valve), this is likely to be a huge competitor with Oculus. The Vive also claims to come with wireless controllers & the rest of their specs sound very good. Anyway, I want this library to work with both the Oculus Rift & the Vive, without the developer needing to make any changes (other than checking for and using wireless controllers that may not exist for the Rift). Not entirely sure what this will entail… I don’t think there is a Vive SDK available yet… hopefully @jherico will integrate it into LibOVR, that’d be ideal. Thoughts, @rickard?
LibOVR is specifically a wrapper around the Oculus API. Unless Vive is
planning on doing something like creating a binary compatible system where
code written for the Oculus SDK will automatically work with the Vive, I
don’t think LibOVR is the place for compatibility.
I’m actually curious to see if Vive provides an API above and beyond the
Steam VR API. I’m presuming they will since they’d want to allow people to
create apps and experiences without being required to release through
Steam. Once there is an SDK I will look at creating a Java wrapper around
it.
Ideally I’d like to create something more like Steam VR, a higher level API
for interacting with VR headsets that can talk to arbitrary hardware via a
plug-in layer.
Thank you for the update! Ultimately, I (and I’m sure other developers) don’t want to pick which VR headset to develop for, so having a library that handles both (and possibly more) via a plugin method is ideal. I’ll keep a close eye on this & let me know if I can do something to help.
Come this holiday season, I want to buy the best VR headset & develop for it, without leaving the “other guys” out.
There will have to be some plugin architecture. However, there is tons of overlap (e.g. view rotation, position, eye separation) so I don’t think there needs to be much differentiation outside of the library, ideally.
Creating a HMD-agnostic library was something I had in mind too and started with in the jme-android lib. I realized when doing the Google Cardboard integration that the different manufacturers most likely will have their own libraries that need to be integrated.
Creating a common architecture on top of that might be very difficult.
Now, I think that perhaps each integration will have to be independent (and maybe different plugins too) but that jme can check which HMD’s are supported, sort of like SystemDelegates are checked today.
Like nehon says, without seeing their libs it will be difficult to do anything.
(Razer is also releasing an HMD this summer, which is claimed to be more ‘open’).
Well…at some point they’ll have to talk to each other anyway. Nobody likes to make a game for a specific device, when there are alternatives on the market. They know it, and that can hurt their business, So i’m pretty sure some common abstraction layer will emerge somehow.
IMHO, it will be harder than the gamepad/joystick support. IIRC today, jme (and other game engine) doesn’t have an every gamepad support. You need to tweak mapping per product/vendor/os.
I also think this is a bigger thing, more comparable with the emergence of consumer GPU’s in the 90s.
Eventually there will be consolidation, but currently (almost) everyone is developing their own solution.
I spoke with @jherico offline, and he is starting work at a new company that is getting into VR. He hopes to be able to share a Java library that can wrap both HMDs together. Then, we can use that library in jME3 & redesign the current Oculus Rift library to fit. Ultimately, I hope to just rename all the “Rift” classes to generic “HMD” classes & have things like getOrientation() pick which native library & hardware to read from.
When a Vive SDK becomes available, I’ll take a look at it myself too.
Made the first commit abstracting out the Oculus Rift in preparation of the Vive:
TestVRApplication is the only remaining test, which tests everything we support (GUI, filters, input, skybox etc.). Pain maintaining many other test applications.
The documentation for it is behind the “Valve Confidential” login, which luckily I can get to because I am a Steam publisher. Odd that the source would be open, but documentation confidential. Anyway, I believe we have some of the pieces to get started on real Vive integration.
Yeah, I agree. This is why I said OpenVR is probably what we need to work with, not SteamVR. I asked in the official developer group (that Valve employees monitor) where OpenVR is & when we can get access to it. I’m sure @jherico is also awaiting word.
OK, got word from Valve: OpenVR hasn’t been released yet (which is what I was expecting to hear). It will be released as soon as the development kits for Vive get released, but there is no dates yet for that. So, we wait.
