Oculus Rift Support

@phr00t said: Interesting, ha! OK, so cameras being resized the "current" way, not the "old" way, right? Maybe we should put in a check for height (e.g. size.h) too, just in case?

Do things look “as expected” in the Rift (if you’ve tested it there yet)?

Right. Yes, we need a check for height as well. It’s the “new” way, just checking the values once they’re retrieved.

I think everything looks ordinary inside the rift.

@rickard said: Right. Yes, we need a check for height as well. It's the "new" way, just checking the values once they're retrieved.

I think everything looks ordinary inside the rift.

OK, good. How about the other bugs you mentioned with orientation and “pixel swapping”?

@rickard said: Issues: There is a significant disturbing effect when moving the HMD. I can't explain it well, but it's almost as if the resolution is low and the pixel swapping is very pronounced. When moving it slowly, though, or just being still and watching the cubes move, it's not a problem. I don't know if this is the 'juddering' jherico is referring to. Some orientation issues, but these are minor in comparison.

I just thought of something that might be causing this – I checked-in a revision that tries to enable prediction based on frame rate awhile back:

https://code.google.com/p/jmonkeyengine-oculus-rift/source/detail?r=104

I was hoping this would reduce any perceived lag, since it previously wasn’t using any future prediction. However, it might be causing some oddities (if you are still seeing any oddities, anyway).

@phr00t said: I just thought of something that might be causing this -- I checked-in a revision that tries to enable prediction based on frame rate awhile back:

https://code.google.com/p/jmonkeyengine-oculus-rift/source/detail?r=104

I was hoping this would reduce any perceived lag, since it previously wasn’t using any future prediction. However, it might be causing some oddities (if you are still seeing any oddities, anyway).

Ok, I’ll check it out. It seems they’ve changed some of the calls regarding that as well, so I’ll go over it now that I have a working display.

Orientation is fixed now, at least. It seems that, with every new SDK, we need to invert a new value in the Orientation quaternion. This time it was two.

1 Like
@rickard said: Orientation is fixed now, at least. It seems that, with every new SDK, we need to invert a new value in the Orientation quaternion. This time it was two.

Awesome. Anything left on the to-do list before you check things in?

@phr00t said: Awesome. Anything left on the to-do list before you check things in?

Yeah, well the ‘low framerate’ issue is still there. I’ve left a note to jherico to see if it is the same that he perceives. None of the prediction stuff seemed to do any difference. I might still check it in though.

@rickard said: Yeah, well the 'low framerate' issue is still there. I've left a note to jherico to see if it is the same that he perceives. None of the prediction stuff seemed to do any difference. I might still check it in though.

Yeah, I’d like to see the work you’ve done. The “low framerate” might be a common juddering problem inherent in the SDK. What does the FPS counter report for a frame rate?

I’ve checked in my changes - the project.properties file. I notice ours are personalized, so I suggest you just replace the jovr lib in yours.
There’s a beginning for frameTiming in OculusRift. My idea is that the update thread will send beginFrameTiming, then each of the getter methods will include it when reading the sensors. I’m not 100% sure on its usage yet, so there is nothing calling the methods.

@rickard said: I've checked in my changes - the project.properties file. I notice ours are personalized, so I suggest you just replace the jovr lib in yours. There's a beginning for frameTiming in OculusRift. My idea is that the update thread will send beginFrameTiming, then each of the getter methods will include it when reading the sensors. I'm not 100% sure on its usage yet, so there is nothing calling the methods.

Thanks. I’ll have to give it a go with my DK2.

Just skimming the changes now… first thing: why is getOrientation using frameTiming.ScanoutMidpointSeconds, while the others like getPosition use Hmd.getTimeInSeconds() + predictValue? Probably because you were only testing orientation with your DK1? I presume the rest will have to be set to ScanoutMidpointSeconds too (if that is the right one to be using).

Also still should check size.h in prepareCameraResolution(…)

@phr00t said: Thanks. I'll have to give it a go with my DK2.

Just skimming the changes now… first thing: why is getOrientation using frameTiming.ScanoutMidpointSeconds, while the others like getPosition use Hmd.getTimeInSeconds() + predictValue? Probably because you were only testing orientation with your DK1? I presume the rest will have to be set to ScanoutMidpointSeconds too (if that is the right one to be using).

No, I was testing it to see if it would change the movement issue I was facing, but it didn’t. I was supposed to revert it back. I’m not sure frameTiming.ScanoutMidpointSeconds is the right way as I’ve seen both that and the old implementation in examples (and the dev guide has Hmd.getTimeInSeconds()).

Also still should check size.h in prepareCameraResolution(...)

Yes, I forgot about that.

@rickard said: No, I was testing it to see if it would change the movement issue I was facing, but it didn't. I was supposed to revert it back. I'm not sure frameTiming.ScanoutMidpointSeconds is the right way as I've seen both that and the old implementation in examples (and the dev guide has Hmd.getTimeInSeconds()).

If you don’t notice much change, I wonder if frameTiming.ScanoutMidpointSeconds would be the more accurate one. my “+ predictValue” is based off of half the tpf (time per frame), which is an approximation to when the frame will actually be displayed. Anyway, should use the same method of calculating the time of prediction in all functions for consistency.

Are you going to make those changes & check them in? Not sure I’ll be able to get to trying out the DK2 tonight with this but I’ll do my best…

OK, I checked this in:

https://code.google.com/p/jmonkeyengine-oculus-rift/source/detail?r=122

According to this:

https://developer.oculusvr.com/forums/viewtopic.php?f=20&t=12052

GetEyePose should be used in the rendering loop (e.g. what we set our cameras to point at, I’m presuming). So, I changed getOrientation() to use this method instead. I made a new getInstantOrientation() that uses the "other’ method, since according to that same forum post, it could be used elsewhere. I wonder if this helps (or hurts) any juddering?

I also removed the references to frameTiming inside OculusRift, primarily because it wasn’t being updated at all (startFrameTiming and endFrameTiming wasn’t being used anywhere). I’m hoping GetEyePose will take care of this for us. For the getInstantOrientation() stuff, I use getFrameTiming from loadedHmd, which hopefully is being updated with the beginFrame and endFrame stuff happening in the filter (and also hopefully the timing that is used in GetEyePose).

I wasn’t able to test all of this out in my DK2 tonight… should tomorrow. If you get the chance to test out these changes on your DK1, let me know!

Hello,

Using the latest JARs from the SVN and the latest jME release (2014-06-12) together with my DK1 i’m unable to get any application running. Every time i try to start a simple demo app (containing nothing but a box) i get the following exception:

[java]
java.lang.NoSuchMethodError: com.jme3.renderer.ViewPort.getProcessors()Lcom/jme3/util/SafeArrayList;
at oculusvr.state.OVRAppState.setupFiltersAndViews(OVRAppState.java:163)
at oculusvr.state.OVRAppState.initialize(OVRAppState.java:125)
at com.jme3.app.state.AppStateManager.initializePending(AppStateManager.java:251)
at com.jme3.app.state.AppStateManager.update(AppStateManager.java:281)
at com.jme3.app.SimpleApplication.update(SimpleApplication.java:239)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:151)
at com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:185)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:228)
at java.lang.Thread.run(Unknown Source)
[/java]

Also the plugin apparently doesn’t recognize my Oculus (“Oculus Rift NOT found or initialized; virtual DK2 created.”) and i have to force Oculus support via configureOVRApp.

Do you have any idea what i’m doing wrong?

@Tjanfoed said: Hello,

Using the latest JARs from the SVN and the latest jME release (2014-06-12) together with my DK1 i’m unable to get any application running. Every time i try to start a simple demo app (containing nothing but a box) i get the following exception:

[java]
java.lang.NoSuchMethodError: com.jme3.renderer.ViewPort.getProcessors()Lcom/jme3/util/SafeArrayList;
at oculusvr.state.OVRAppState.setupFiltersAndViews(OVRAppState.java:163)
at oculusvr.state.OVRAppState.initialize(OVRAppState.java:125)
at com.jme3.app.state.AppStateManager.initializePending(AppStateManager.java:251)
at com.jme3.app.state.AppStateManager.update(AppStateManager.java:281)
at com.jme3.app.SimpleApplication.update(SimpleApplication.java:239)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:151)
at com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:185)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:228)
at java.lang.Thread.run(Unknown Source)
[/java]

Also the plugin apparently doesn’t recognize my Oculus (“Oculus Rift NOT found or initialized; virtual DK2 created.”) and i have to force Oculus support via configureOVRApp.

Do you have any idea what i’m doing wrong?

You mention you are using jMonkeyEngine from SVN… however, we are using the latest from the git repository here:

… try using that jMonkeyEngine build. The method is available as seen here:

@phr00t said:

… try using that jMonkeyEngine build

Thanksfor the fast reply, using the current version from Github does indeed fix the MethodNotFound problem.

Now the application starts but the Oculus support is somewhat broken. Here is a screenshot:

When moving the mouse around only the image for the left eye moves, the one for the right eye stays constant. Also the warning message doesn’t disappear when pressing a key

@Tjanfoed said: Thanksfor the fast reply, using the current version from Github does indeed fix the MethodNotFound problem.

Now the application starts but the Oculus support is somewhat broken. Here is a screenshot:

When moving the mouse around only the image for the left eye moves, the one for the right eye stays constant. Also the warning message doesn’t disappear when pressing a key

Have you tried tapping the side of your Rift to get rid of the warning message? I hear it is a common complaint with the warning not disappearing… might be a bug in the SDK.

Do you have a DK1 or DK2?

When moving the mouse, you might be only rotating the left camera. You should be binding the cameraControl to a spatial, then rotating the spatial when the mouse moves as described in the HowTo:

https://code.google.com/p/jmonkeyengine-oculus-rift/wiki/HowTo

What happens when you look around in the Rift?

@phr00t said: Have you tried tapping the side of your Rift to get rid of the warning message? I hear it is a common complaint with the warning not disappearing.. might be a bug in the SDK.

Do you have a DK1 or DK2?

When moving the mouse, you might be only rotating the left camera. You should be binding the cameraControl to a spatial, then rotating the spatial when the mouse moves as described in the HowTo:

https://code.google.com/p/jmonkeyengine-oculus-rift/wiki/HowTo

What happens when you look around in the Rift?

I have tried tapping it but that didn’t help. I have a DK1.

@Camera: Thanks, with your tip i managed to get it working :slight_smile: Is it possible to have the camera controlled by the Oculus’ gyroscope?

@Tjanfoed said: I have tried tapping it but that didn't help. I have a DK1.

@Camera: Thanks, with your tip i managed to get it working :slight_smile: Is it possible to have the camera controlled by the Oculus’ gyroscope?

Controlled by the gyroscope…? What do you mean & how do you want to use it?

@phr00t said: Controlled by the gyroscope..? What do you mean & how do you want to use it?

I mean just the usual way: Turn your head left–>The game camera is turned left etc