JOVR 0.4.2.0: Java/Maven bindings for 0.4.2 (Updated 09-05)

I've been working on getting JME_Oculus to work with JOVR 0.4.1.0, but I've hit a bit of a wall.

When I call hmd.endFrame(poses, eyeTextures); I get an invalid memory location error.

Uncaught exception thrown in Thread[LWJGL Renderer Thread,5,main]
Error: Invalid memory access

java.lang.Error: Invalid memory access
	at com.sun.jna.Native.invokeVoid(Native Method)
	at com.sun.jna.Function.invoke(Function.java:367)
	at com.sun.jna.Function.invoke(Function.java:315)
	at com.sun.jna.Library$Handler.invoke(Library.java:212)
	at com.sun.proxy.$Proxy0.ovrHmd_EndFrame(Unknown Source)
	at com.oculusvr.capi.Hmd.endFrame(Hmd.java:175)
	at oculusvr.post.OculusFilter.postFilter(OculusFilter.java:97)
	at com.jme3.post.FilterPostProcessor.renderFilterChain(FilterPostProcessor.java:294)
	at com.jme3.post.FilterPostProcessor.postFrame(FilterPostProcessor.java:307)
	at com.jme3.renderer.RenderManager.renderViewPort(RenderManager.java:1006)
	at com.jme3.renderer.RenderManager.render(RenderManager.java:1055)
	at com.jme3.app.SimpleApplication.update(SimpleApplication.java:252)
	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:230)
	at java.lang.Thread.run(Thread.java:744)

I've made sure I'm passing valid values to the function (string values posted below). Anyone else seeing this?
I'm going to try to get the examples on https://github.com/jherico/jocular-examples/ working before I go to bed to see if it really is possibly something up in the lib.

poses = (com.oculusvr.capi.Posef[]) #2826(length=2)

poses[0] = Posef(allocated@0x5b17e60 (28 bytes) (shared from auto-allocated@0x5b17e60 (56 bytes))) {
  OvrQuaternionf Orientation@0=OvrQuaternionf(allocated@0x5b1c920 (16 bytes) (shared from auto-allocated@0x5b1c920 (28 bytes))) {
    float x@0=0.0
    float y@4=0.0
    float z@8=0.0
    float w@c=1.0
  }
  OvrVector3f Position@10=OvrVector3f(allocated@0x5b1c930 (12 bytes) (shared from auto-allocated@0x5b1c920 (28 bytes))) {
    float x@0=0.0
    float y@4=0.0
    float z@8=0.0
  }
}

poses[1] = Posef(allocated@0x5b17e7c (28 bytes) (shared from allocated@0x5b17e7c (28 bytes) (shared from allocated@0x5b17e60 (28 bytes) (shared from auto-allocated@0x5b17e60 (56 bytes))))) {
  OvrQuaternionf Orientation@0=OvrQuaternionf(allocated@0x5b1c8c0 (16 bytes) (shared from auto-allocated@0x5b1c8c0 (28 bytes))) {
    float x@0=0.0
    float y@4=0.0
    float z@8=0.0
    float w@c=1.0
  }
  OvrVector3f Position@10=OvrVector3f(allocated@0x5b1c8d0 (12 bytes) (shared from auto-allocated@0x5b1c8c0 (28 bytes))) {
    float x@0=0.0
    float y@4=0.0
    float z@8=0.0
  }
}

eyeTextures = (com.oculusvr.capi.Texture[]) #2834(length=2)

eyeTextures[0] = Texture(allocated@0x5b185d0 (92 bytes) (shared from auto-allocated@0x5b185d0 (184 bytes))) {
  TextureHeader Header@0=TextureHeader(native@0x0) (28 bytes) {
    int API@0=1
    OvrSizei TextureSize@4=OvrSizei$ByValue(auto-allocated@0x5b1c730 (8 bytes)) {
      int w@0=49e
      int h@4=5b5
    }
    OvrRecti RenderViewport@c=OvrRecti(native@0x0) (16 bytes) {
      OvrVector2i Pos@0=OvrVector2i(auto-allocated@0x5b1c750 (8 bytes)) {
        int x@0=0
        int y@4=0
      }
      OvrSizei Size@8=OvrSizei$ByValue(auto-allocated@0x5b1c730 (8 bytes)) {
        int w@0=49e
        int h@4=5b5
      }
    }
  }
  int TextureId@1c=0
  int Padding[15]@20=[I@6d2efbbd
}

eyeTextures[1] = Texture(allocated@0x5b1862c (92 bytes) (shared from allocated@0x5b1862c (92 bytes) (shared from allocated@0x5b1862c (92 bytes) (shared from allocated@0x5b185d0 (92 bytes) (shared from auto-allocated@0x5b185d0 (184 bytes)))))) {
  TextureHeader Header@0=TextureHeader(allocated@0x5b1862c (28 bytes) (shared from allocated@0x5b1862c (92 bytes) (shared from allocated@0x5b1862c (92 bytes) (shared from allocated@0x5b1862c (92 bytes) (shared from allocated@0x5b185d0 (92 bytes) (shared from auto-allocated@0x5b185d0 (184 bytes))))))) {
    int API@0=0
    OvrSizei TextureSize@4=OvrSizei$ByValue(auto-allocated@0x5b1ccd0 (8 bytes)) {
      int w@0=49e
      int h@4=5b5
    }
    OvrRecti RenderViewport@c=OvrRecti(allocated@0x5b18638 (16 bytes) (shared from allocated@0x5b1862c (28 bytes) (shared from allocated@0x5b1862c (92 bytes) (shared from allocated@0x5b1862c (92 bytes) (shared from allocated@0x5b1862c (92 bytes) (shared from allocated@0x5b185d0 (92 bytes) (shared from auto-allocated@0x5b185d0 (184 bytes)))))))) {
      OvrVector2i Pos@0=OvrVector2i(auto-allocated@0x5b1ccf0 (8 bytes)) {
        int x@0=0
        int y@4=0
      }
      OvrSizei Size@8=OvrSizei$ByValue(auto-allocated@0x5b1ccd0 (8 bytes)) {
        int w@0=49e
        int h@4=5b5
      }
    }
  }
  int TextureId@1c=0
  int Padding[15]@20=[I@4491489f
}

Sorry you're having trouble. It's entirely possible the issue is in the library. One thing I've discovered is that the OVR_BUILD_DEBUG preprocessor flag appears to be enabled even in the release build of my DLL and any assertions that are triggered in the code show up as an exception in Java, which is less than ideal. I'm working on a point release to resolve this.

Both your eyeTextures appear to not have a texture ID in them:

  int TextureId@1c=0

Additionally, the second eyeTexture seems to not have the API value set to OpenGL:

    int API@0=0

I encountered this in my own application, but I wasn't sure what was causing it. The Texture objects are supposed to initialize their API to OpenGL, since presumably no one working in Java is going to be using anything else.

EDIT
Actually I think I understand the API issue. Because the new SDK version takes a texture array (whereas the old one took one texture per call to endEyeRender(), the textures now have to be declared like this:

  private final Texture eyeTextures[] =
      (Texture[])new Texture().toArray(2);

It looks like this is allocating the memory for the second one, but not initializing the values in the same way as a normally constructed Java object. Because of this you have to explicitly set the API value now, as shown below:
END EDIT



Try explicitly setting the API member to OpenGL:

      Texture texture = eyeTextures[eye];
      TextureHeader header = texture.Header;
      header.API = ovrRenderAPI_OpenGL;

Also, try setting a breakpoint directly before hmd.endFrame() and inspecting the objects to ensure the TextureId is set correctly.

Yeh, my sleep deprived brain must be missing something...

You are correct that the texture ID's are not getting Set.

I've been using this for the texture constructor:

private static final Texture eyeTextures[] = (Texture[])new Texture().toArray(2);

However, the problem appears to be the behavior of JME materials. The example worked fine so its just going to take more digging into the JMW codebase (I haven't looked at JME in about 3 years, so the rust us really showing)

I'm trying to get the following demo working with JOVR, OSK 10.8.5, DK2 and SDK-041

https://github.com/elect86/JavaOculusRoomTiny/tree/master/src/roomTinySimplified

I been in discussion with the JOGL forum and suspect it might be an issue with OSX setup that it can't find the native libraries. Is JOVR already supporting the new SDK and OSX, or is it in progress still?

FYI this is the error I'm seeing:

java -cp dist/OculusRoomTiny.jar:lib/jogl-all.jar:lib/Jglm.jar:lib/javaUnofficialOpenglSDK.jar:lib/jovr-0.4.1.2-SNAPSHOT.jar:lib/jna-3.0.9.jar:lib/gluegen-rt.jar:gluegen-rt-natives-macosx-universal.jar:jogl-all-natives-macosx-universal.jar -Djava.library.path=lib roomTinySimplified.core.OculusRoomTiny
setupOculus()
Exception in thread "main" java.lang.UnsatisfiedLinkError: Unable to load library 'OVR_C': dlopen(libOVR_C.dylib, 1): image not found

I'm just trying to get a simple JOGL demo running with latest SDK and DK2 :)

"whitehexagon" wrote:

java -cp dist/OculusRoomTiny.jar:lib/jogl-all.jar:lib/Jglm.jar:lib/javaUnofficialOpenglSDK.jar:lib/jovr-0.4.1.2-SNAPSHOT.jar:lib/jna-3.0.9.jar:lib/gluegen-rt.jar:gluegen-rt-natives-macosx-universal.jar:jogl-all-natives-macosx-universal.jar -Djava.library.path=lib roomTinySimplified.core.OculusRoomTiny
setupOculus()
Exception in thread "main" java.lang.UnsatisfiedLinkError: Unable to load library 'OVR_C': dlopen(libOVR_C.dylib, 1): image not found

I'm just trying to get a simple JOGL demo running with latest SDK and DK2 :)

The JOVR binary is built for with OSX. The binary is actually embedded inside the JOVR jar. It's supposed to be automatically extracted by the JNA library, however this functionality depends on JNA version 4.x. You're using JNA 3.x. You can try updating the JNA version you're using, or alternatively you can unzip the JOVR archive, grab the dylib file and put it somewhere Java will find it (you may need to set java.library.path system property).

Thanks, another step closer, but now I get:

java -cp dist/OculusRoomTiny.jar:lib/jogl-all.jar:lib/Jglm.jar:lib/javaUnofficialOpenglSDK.jar:lib/jna-4.1.0.jar:lib/jovr-0.4.1.2-SNAPSHOT.jar:lib/gluegen-rt.jar:gluegen-rt-natives-macosx-universal.jar:jogl-all-natives-macosx-universal.jar -Djava.library.path=lib roomTinySimplified.core.OculusRoomTiny
setupOculus()
dyld: lazy symbol binding failed: Symbol not found: ___sincosf_stret

From a bit of research it seems like JOVR may have been built only for 10.9? I'm on 10.8.5.

http://stackoverflow.com/questions/19015780/sincos-stret-undefined-symbol-when-linking

"whitehexagon" wrote:
From a bit of research it seems like JOVR may have been built only for 10.9? I'm on 10.8.5.

http://stackoverflow.com/questions/19015780/sincos-stret-undefined-symbol-when-linking

It looks that way. I didn't intentionally add any code to specify the minimum OSX version, but I'm guessing that my build system just targets the current version it's running.

So I've downloaded the OculusSDK project from github, installed cmake, generated make files, ran make and I've managed to generate a 2MB file: libOculusVR.a Phew! please have patience with me because most of that is unfamiliar territory for me.
So what step am I missing that I generated a static library vs the dynamic library libOVR_C.dylib that I required?

Hi jherico, thanks so much for your excellent work. I'm trying to get this working with Processing, which is JOGL under the hood. I've made some pretty good progress so far. I have both viewports showing the safety warning, so I know that the SDK has my textures. What I am missing is the distortion. I am drawing each of my textures to the screen manually, which it seems is the wrong approach.

Looking at your RiftApp code and the code in your Glamour project, I can't seem to identify what is actually drawing the FrameBuffers to the Display. I think this is the missing key.

I have no experience with lwjogl and only a vague understanding of OpenGL itself, which is why I'm using Processing in the first place. I'll get more in depth one day but for now I just want to code some simple prototypes.

Once I'm done, I'll put it up on github. My goal is to be able to git clone, gradlew idea or gradlew eclipse and you're ready to start coding.

"whitehexagon" wrote:
So I've downloaded the OculusSDK project from github, installed cmake, generated make files, ran make and I've managed to generate a 2MB file: libOculusVR.a Phew! please have patience with me because most of that is unfamiliar territory for me.
So what step am I missing that I generated a static library vs the dynamic library libOVR_C.dylib that I required?

Both the libOculusVR.a and libOVR_C.dylib files should be generated if you've run CMake against the file at the root of the project. They should both be in <build_dir>/output.

Make sure you're building from the 0.4.x branch.