Oculus Rift Support

Actually, Direct HMD mode now works (mirroring jherico’s implementation).
I think there is still some tweaking needed regarding resolution, but it works!

1 Like

Great work!

Interesting conversation over on the Oculus here:

https://developer.oculusvr.com/forums/viewtopic.php?p=212612#p212612

…getEyePose is deprecated?

Also,

https://developer.oculusvr.com/forums/viewtopic.php?p=213090#p213090

… looks like jherico is trying to make some changes to improve compatibility. We’ll have to monitor these changes and get them into our Rift library when they become a bit more stable.

@phr00t said: ...getEyePose is deprecated?

Ah, I’ll look into this.

@phr00t said: ... looks like jherico is trying to make some changes to improve compatibility. We'll have to monitor these changes and get them into our Rift library when they become a bit more stable.

I agree.

@phr00t said: ...getEyePose is deprecated?

Changed the implementation.

I also moved the call from postFrame to preFrame and the beginFram state to avoid one additional (supposedly?) native call.
I originally placed them during postFrame to be as close to the actual usage of the offsets as possible. I notice no problem with moving it, however. There’s a slight possibility I’m not imagining an improvement in doing so.

1 Like
@rickard said: Changed the implementation.

I also moved the call from postFrame to preFrame and the beginFram state to avoid one additional (supposedly?) native call.
I originally placed them during postFrame to be as close to the actual usage of the offsets as possible. I notice no problem with moving it, however. There’s a slight possibility I’m not imagining an improvement in doing so.

That was quick! However, doesn’t look like OculusRift.getRenderInit() got checked in? Can’t be found on my end…

@phr00t said: That was quick! However, doesn't look like OculusRift.getRenderInit() got checked in? Can't be found on my end...
@phr00t said: That was quick! However, doesn't look like OculusRift.getRenderInit() got checked in? Can't be found on my end...

Apparently there were some other changes to OculusFilter that were not checked in. I removed the reference for now as there were other untested things in OculusRift that i started some time back. Time to revisit low-persistence again!

I just noticed getPosef is used in OculusRift as well.
Processing…

@phr00t
Do you think it would be totally out of line to get the pose in OculusRift from the OculusFilter? I think this would be the simplest solution for now and it would lessen the calls to the SDK. I don’t know if it would cause a timing issue, though, considering the camera update will occur milliseconds before the rendering. I don’t really notice anything.
Doing it any other way would require some architectural changes that I don’t have time to do now. The other alternative is to keep getEyePosef in OculusRift.

Also, I’ve been testing low persistence on and off and can’t see any other difference than that low persistence on makes the screen slightly darker.

I think we should err on the side of low latency… I don’t think calls to the SDK are a bottleneck & it may give us more updated information, quicker. I haven’t looked at the required architectural changes, what are they? I might be able to get to them… is the alternative to keep getEyePosef in OculusRift just as easy?

@phr00t said: I think we should err on the side of low latency... I don't think calls to the SDK are a bottleneck & it may give us more updated information, quicker. I haven't looked at the required architectural changes, what are they? I might be able to get to them... is the alternative to keep getEyePosef in OculusRift just as easy?

I did a quick test and it may not be so difficult.
Basically the frameIndex and eyePoses etc should be moved out of the filter and beginFrame should be called during the update phase. This so that we can have the same reference throughout the application. We talked about some changes being needed when 0.4.x was introduced.
I think I can manage it.

Btw, have you tried using the player height (or eye height for that matter) from the config service? It seems to return 0.0 when getting it from OvrLibrary. Is there something we have to do to be able to use it?

I haven’t tried using the player height… I probably won’t for 4089, since I set the player to the highest point possible without clipping into the ceiling when jumping. However, I’m sure it has many useful uses elsewhere, just haven’t played with it myself or know how to get proper data from it. :confused:

I’ve committed my changes.
Not entirely satisfied with the implementation, but I think it will work for now.
Somehow I get the feeling we should use getInstantOrientation / Position for the StereoCameraControl. I’ve however had no luck using the method as there seems to be a bit of sliding when doing so. Most likely there’s some work needed on prediction? I’ve tried using beginFrameTiming and endFrameTiming but I haven’t read the docs for it yet.

I also added the option to reset the HMD (F9) and toggling low-persistence (F10) through OVRApplication

Oh, and there are some resolution issues with OpenGL:
https://developer.oculusvr.com/forums/viewtopic.php?f=20&t=16133

I noticed this as well now.

Hey guys,

First of all you are all doing a great job with this project!

I am a little bit fuzzled at the moment. I was trying to get my oculus rift to work with the game I created with JMonkey on Ubuntu. Unfortunately I am getting the following error:
Exception in thread “main” java.lang.UnsatisfiedLinkError: Unable to load library ‘OVR_C’: Native library (linux-x86-64/libOVR_C.so) not found in resource path

It looks like the oculus rift support doesn’t work on Ubuntu just yet (because there is no official linux SDK by Oculus). I expected this to happen, however I wanted to be sure. I was confused beecause on the different threads on the the web, you can find some posts about linux support for the Oculus Rift DK2. For example on the site of the game 4089 (which looks to be a great game btw) phr00t says that it runs on both linux, windows as mac, so this would indiciate he has managed to get the oculus working with linux.
So my question is to make this clear, did I just screwed things up when adding the 4 jars to my project or is there at the moment indeed no support for ubuntu/linux?

thx :slight_smile:

Ubuntu support is non-existent atm ,I believe. What you have there, I think, is experimental. Naturally , i’m guessing. None of it works for me.

Oculus SDK 0.4.3 & LibOVR 0.4.3 does include Linux native libraries. However, all we’ve been able to get is a black screen on Linux because of other issues. You shouldn’t get exceptions, though. Make sure you are adding LobOVR 0.4.3 & the latest Oculus Rift library and it should run without exceptions, but you probably won’t see anything.

Hmmm I added the latest libs (I had allready jna-4.1.0 and guava-17.0 and now added jovr-0.4.3.0 and de lates JMonkeyOculusRift) but I m still getting the same error:
Exception in thread "main" java.lang.UnsatisfiedLinkError: Unable to load library 'OVR_C': Native library (linux-x86-64/libOVR_C.so) not found in resource path

In the mean time I also installed everything on windows. I have no problem with the libs there, however I am experiencing another problem: The moment I start my OR DK2 and start TestOVRApplication I get a fatal error:

# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000000000000, pid=3060, tid=2656
#
# JRE version: Java(TM) SE Runtime Environment (7.0_51-b13) (build 1.7.0_51-b13)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.51-b03 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C  0x0000000000000000

Dit someone experience something like this when using the DK2?

I did just submit an update to my github repository that fixes a capability problem that caused crashes on Rift starts:

I wouldn’t use the main jME3 branch with this Oculus Rift library, it might not work. Using my library is pretty easy – just use the libraries in dist/ and lib/ above instead of the ones provided by jME3.

Not sure what was done, but all my issue were fixed with your last update.

Hi

@rickard said: Thread for discussion about Oculus Rift integration in jMonkeyEngine. Based on jOVR.
Please rather use the word "jocular" to designate this API in order to avoid any confusion with JOGL build-in VR support. Sorry for the disturbance. Best regards.