Oculus Rift Support

Shared this library on reddit here: http://www.reddit.com/r/oculus/comments/2gc18b/jmonkeyengine_a_free_3d_crossplatform_engine_has/

@rickard said: It sounds like the problem I faced when testing your first OVR supported build. I can't think of any direct reason for the behavior, but if I come up with something, I'll let you know :)

I might have it solved, but I’ve run into another odd problem. I did a bunch of things to optimize my game, 4089, which work perfectly without the Rift. However, when I use the Rift & a mix of batched spatials (using GeometryBatchFactory.optimize) and non-batched spatials, rendering completely freezes up. A thread dump shows the rendering thread gets hung up on glGetProgram->nglGetProgramiv, which doesn’t make much sense to me. I’m wondering if it is some weird bug in the Oculus SDK I’m invoking somehow… I was going to wait until the a newer Linux SDK comes out to debug further.

Hi

Just wanted to say thank you for working on the rift support.

-Tommi

We got our DK2 at work last week. Want to have it working with jmonkeyengine. I have tried to skim the thread but it is getting long and I did not get a clear picture of the current status. So:

  1. Have anyone got a DK2 working with jmonkeyengine using this integration?

  2. If so, does it work correctly? (correct lens distortion using mesh and shader, correct position tracking, etc)

  3. Is the lag as good as the best demos. I have noticed some (possibly unity) demos have a shuttering effect when rotating.

  4. How much work it is to get the a hello world box working? (including fixing builds, making things compile, etc)

Slightly off topic questions:

a) Is it possible in the future to create a “directly to rift” support? Where it renders directly to the rift without having to clone screens.

b) Anyone know of a “simple” LWJGL example that is integrated with DK2?

@tom said: We got our DK2 at work last week. Want to have it working with jmonkeyengine. I have tried to skim the thread but it is getting long and I did not get a clear picture of the current status. So:
  1. Have anyone got a DK2 working with jmonkeyengine using this integration?

  2. If so, does it work correctly? (correct lens distortion using mesh and shader, correct position tracking, etc)

  3. Is the lag as good as the best demos. I have noticed some (possibly unity) demos have a shuttering effect when rotating.

  4. How much work it is to get the a hello world box working? (including fixing builds, making things compile, etc)

Slightly off topic questions:

a) Is it possible in the future to create a “directly to rift” support? Where it renders directly to the rift without having to clone screens.

b) Anyone know of a “simple” LWJGL example that is integrated with DK2?

  1. Yes. I have a DK2 & this library works very good.

  2. Yes, it works correctly. It uses SDK-side distortion, so it works just as good as Unity or Unreal Engine 4. Positional tracking is spot-on, too.

  3. I experience no lag or stuttering, as long as you are hitting 75+ FPS.

  4. Java is inherently relatively easy to build. All of the native libraries are already included in JOVR, so you don’t need to “fix builds and make things compile”, at least at that level. You should be able to get TestOVRApplication.java running just by importing the project & adding the needed libraries.

Read here:

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

a) We want “direct to rift” support, but it is pretty broken in the Oculus SDK at the moment. I don’t think anything OpenGL related works in that mode yet.

b) I don’t, other than this library, of course.

… perhaps @rickard will want to update the first post here, and the Google code page to simply say things like “Supported Devices: DK1/DK2, Positional Tracking: YES, SDK version: 0.4.2” etc.

@tom said: a) Is it possible in the future to create a "directly to rift" support? Where it renders directly to the rift without having to clone screens.

Hopefully Oculus will come up with a proper SDK based solution soon. In the meantime I’ve produced an example (C++) application which creates a Direct3D window and attaches that to the Oculus SDK, and then uses the nVidia Direct3D/OpenGL interoperability extensions to allow OpenGL to render to a Direct3D texture. Using this mechanism I’ve been able to get OpenGL rendered content working in Direct HMD mode. I may be able to produce a custom build of the SDK that does this automatically, but I’m not sure if it’s worth the effort since I don’t know how far Oculus is from fixing the problem. If I do implement it, I’ll also produce a JOVR build that includes the functionality (though only on Windows of course).

@tom said: b) Anyone know of a "simple" LWJGL example that is integrated with DK2?

I’ve created a simple example for the Java bindings for my book. There is a base class which handles pretty much all of the interaction with the SDK. From this you can derive a class which perform the actual rendering. There’s an example of such a derived class here.

@phr00t said: 1) Yes. I have a DK2 & this library works very good.
  1. Yes, it works correctly. It uses SDK-side distortion, so it works just as good as Unity or Unreal Engine 4. Positional tracking is spot-on, too.

  2. I experience no lag or stuttering, as long as you are hitting 75+ FPS.

  3. Java is inherently relatively easy to build. All of the native libraries are already included in JOVR, so you don’t need to “fix builds and make things compile”, at least at that level. You should be able to get TestOVRApplication.java running just by importing the project & adding the needed libraries.

Read here:

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

a) We want “direct to rift” support, but it is pretty broken in the Oculus SDK at the moment. I don’t think anything OpenGL related works in that mode yet.

b) I don’t, other than this library, of course.

Thank you! I can confirm that it works on the DK2, it looked good and it was easy to follow the how to on the wiki. Good work!

My only problem had nothing to do with jmonkeyengine, but was about how to get it running on the correct screen. I’m having problems with cloning as there are issues with portrait/landscape and the correct resolution don’t show up. Had to extend the desktop and then there were the issue of starting something on a screen you can’t see.

@phr00t said: ... perhaps rickard will want to update the first post here, and the Google code page to simply say things like "Supported Devices: DK1/DK2, Positional Tracking: YES, SDK version: 0.4.2" etc.

Update wiki.

Btw, you complained about the chromatic abberation in 0.4.1. It was supposed to get better in 0.4.2. Can you tell if it’s improved?

@rickard said: Update wiki.

Btw, you complained about the chromatic abberation in 0.4.1. It was supposed to get better in 0.4.2. Can you tell if it’s improved?

OK, thanks.

I’ve run the TestOVRApplication a few times, and gotten to at least the menu in my 4089 game since the 0.4.2 update. I haven’t been specifically looking for chromatic abberations, but thinking back, I believe it has been improved.

@tom said: Thank you! I can confirm that it works on the DK2, it looked good and it was easy to follow the how to on the wiki. Good work!

My only problem had nothing to do with jmonkeyengine, but was about how to get it running on the correct screen. I’m having problems with cloning as there are issues with portrait/landscape and the correct resolution don’t show up. Had to extend the desktop and then there were the issue of starting something on a screen you can’t see.

Getting Rift applications to start on the correct screen, at the right size and orientation is a problem with all “extended mode” Rift applications. What I do, is set my Rift as the primary screen, and my monitor as a secondary screen. I then move the folder window to my secondary monitor screen to launch the applications. Remember you can use Alt+Windows+Left/Right to move windows from one screen to the other.

Getting some oddities from the shadows. Doesn’t look like the right viewport gets the same edge effects as the left viewport in my game. I also see random artifacts on geometry that pops in and out with movement. You can see a small artifact on the right view, in the background on the floor:

I want the shadows to look as they do in the left:

Here is my shadow init code:

[java] dl = new DirectionalLight();
dl.setDirection(new Vector3f(0.001f, -1f, 0.0f));

    shadows = new OculusDirectionalLightShadowRenderer(Main.MyApp.getAssetManager(), 2048, 1);
    shadows.setLight(dl);
    shadows.setEdgeFilteringMode(EdgeFilteringMode.PCFPOISSON);
    shadows.setEdgesThickness(8);
    shadows.setEnabledStabilization(true);
    shadowFade = 0.5f;
    shadows.setShadowIntensity(0.5f);
    shadows.setShadowZFadeLength(64);
    shadows.setShadowZExtend(64f);

    usingShadows = true;
    viewPort.getProcessors().add(0, shadows);

[/java]

(please disregard the resolution! rift isn’t actually hooked up)

Seems weird.
I guess you’re setting up 2 viewports right?
Or is it the same viewport?

We also received our DK2 this week and got it working. Keep up the good work!

Unusually quiet in the thread. We must have reached some kind of stable state :slight_smile:
DK2 is due on Friday. Really excited to see how it behaves, especially when I’ve been using the DK1 more in the last couple of weeks.
@phr00t I know you wondered about custom FOV some time ago. I don’t know if you solved it yourself, but I checked in a way of doing so some time back. It’s not the most elegant way but it does the trick.

I also noticed the DOF filter has a similar issue where one of the eyes is out of focus.

I’ve been making some pretty recent commits. Got another one in the works – trying to fix the flickering when you Alt+Tab out of a Rift application. Got 4089 up on Oculus Share!

https://share.oculusvr.com/app/4089-ghost-within

1 Like

I have a question regarding the API: Is it possible to simply disable the Oculus Rift mode and have the game displayed as just a normal game, or can this be only configured via inheritance of the Main class?

I haven’t tried this myself, but i think it should be possible despite the class inheritance.
First of all, detach the OVRAppState.
I don’t think that currently disables the OculusFilters, so that would have to be removed from the FilterProcessor on the viewport.
The cam frustrum would have to be changed as well.

This should all go into some neat methods, but for now there’s some manual changes needed.

If a Rift is not detected, the application will behave and display normally - no code changes needed.

JOVR was just updated to 0.4.3. Includes Linux support but apparently has terrible vignette. I plan on getting it into this library tomorrow with a new option to disable vignette.

OK, I checked in initial 0.4.3 support:

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

Unfortunately, all I see is black on my linux machine. I’m not sure if this is just because I’m on Linux & its support is currently “experimental”. @rickard, can you test this out on Windows? I might be able to get to it later tonight… I also poked @jherico here:

https://developer.oculusvr.com/forums/viewtopic.php?p=212588#p212588

1 Like
@phr00t said: OK, I checked in initial 0.4.3 support:

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

Unfortunately, all I see is black on my linux machine. I’m not sure if this is just because I’m on Linux & its support is currently “experimental”. @rickard, can you test this out on Windows? I might be able to get to it later tonight… I also poked @jherico here:

OK | Oculus

Works fine on Win 7 at least. Direct mode is of course not working yet, though. Maybe it’s time to revisit it (although testing it garbles all the text on the launch window)