OpenVR Available, Convert?

@rickard & @jherico

Looks like the OpenVR API is now available & claims to do exactly what we want: unify VR development. It appears we should just drop the current Oculus SDK integration and implement OpenVR. That way, we get Vive & Rift support without us having to worry it. Has native support for Linux too.

License is pretty empty with no limitations or gotchas other than including the license when distributing. What do you guys think? It might be possible to just run this through some automated JNA thing to create a Java APIā€¦ not sure how @jherico has been doing it (or if he is already planning on doing this with his new company & making it available for us).

2 Likes

It is BSD license ā€¦ excellent.
Probably you will need to use JNI, since this is a C++ interface and not a C interface.

Looks like we have some tools that might help us avoid JNI:

https://code.google.com/p/jnaerator/

https://code.google.com/p/bridj/

I wouldnā€™t want to duplicate work with @jherico, though. Iā€™d like to hear what his plans are first. Never used the tools above, so Iā€™m expected heā€™d be able to do this more quickly & correctly than I. However, Iā€™ll pick it up if needed.

Gahā€¦ Thereā€™s no source code. Its just a library file.

Not so open after all, I guess.

That shouldnā€™t hamper our integration, though, correct?

from my experience, javacpp is easier to use and more powerfull (with C++) than bridj or jnaerator.

Probably notā€¦ It doesnā€™t say what platforms it supports though. Do you need to have LibOVR in order to use OpenVR? Its not mentioned.

OpenVR doesnā€™t appear to support timewarp, so content using it and running
on a DK2 will appear to have higher latency than the same content running
directly against the Oculus SDK.

Supposedly there is a C API available, but right now itā€™s only ā€˜sort ofā€™ C,
since it includes headers that use namespaces.

All right. Letā€™s see what we can do.
I did some reading a while back, and it seems JNA is quite a lot slower than JNI (although far more convenient). One test showed 30-40 times slower. Considering the performance dependent application of VR, is this a concern?
I think more info about the lib will be unraveled soon as people start working with it. Is there a forum somewhere?

Edit: Iā€™d also like to mention that I have never felt that performance was ever an issue with jovr.

From looking at the example, it seems like the integration on jmeā€™s side will be simpler than that of the oculus lib. However, it looks like itā€™s only using client side distortion?

It only supports Valveā€™s HTC Vive right now, no other headset. Also you need to download SteamVR for the OpenVR library to do anything.

Do you have a source on this? The README makes it sound like it is meant to work with ā€œallā€ VR hardware & not be Vive-specific.

Not supporting Timewarp is a drawback, but Iā€™m not sure it should be considered a dealbreaker. Ultimately, we want an easy library to integrate & maintain that will support multiple VR headsets. @rickard believes OpenVR will be easier to integrate, which is a big plus. Yes, I think it only does client-side distortion. Curious to see what the experience is compared to the native Oculus SDKā€¦ I suspect it will only get better as the library matures, though.

All press announcements about this just mention that it supports HTC Vive.

Maybe, at some future point in time, it will support other headsets, but obviously it doesnā€™t right now.

Someone asked, ā€œIs Oculus Rift support in the works or planned?ā€ and Valve replied, ā€œSteamVR supports the Rift.ā€ Iā€™m asking for some clarification:

The overview states ā€œThe OpenVR API provides a game with a way to interact with Virtual Reality displays without relying on a specific hardware vendorā€™s SDK.ā€ Their goal must be to support the Rift (and potentially others), even if it isnā€™t reached yet. I have the same goal with the jMonkeyEngine library, so I think we should follow their footsteps.

So many options for converting C++ libraries into a Java APIā€¦ not sure which to choose. I donā€™t have any experience doing it (but Iā€™m sure I could figure it out). @david_bernard_31, do you have any interest in converting it over since you have experience? @jherico is relatively busy with his new position, which mainly develops in C++, so Iā€™m not sure how much more he will be able to contribute to this (although I hope he does!).

EDIT post: http://steamcommunity.com/app/250820/discussions/0/613956964588541283/

ā€¦ and there it is, confirmation that OpenVR supports the Rift from Valve:

ā€œYes, both SteamVR and OpenVR support the Rift.ā€

I supports the DK2 just fine, just like the SteamVR API. You can run the sample app included in the release using the DK2.

Valve wants people to be able to develop content right now whether they have a Vive in hand or not.

Iā€™ve started working on a Java binding here: https://github.com/jherico/JOpenVR

I havenā€™t gotten as far as writing a test app to verify it works though.

3 Likes

Woohoo! Awesome! Keep us updated. When you get a little test app, @rickard and I can use it to start integrating it into jMonkeyEngine.

Giving it a quick look over, looks like the JOpenVR @jherico has is a JNAerator output:

https://github.com/jherico/JOpenVR/blob/master/src/main/java/com/valvesoftware/vr/OpenVR.java

Looks like the library location & platform is hardcoded. Good first step, but not very far into it yet. I wonder if we should be using BridJ:

https://code.google.com/p/bridj/wiki/FAQ#JNA

For example, it is BSD licensed, claims better performance & better JNAerator support.