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

Thanks jherico!

I'll work on getting this integrated with jMonkeyEngine as soon as a Linux release becomes available...

Great, I'm looking forward to trying out the OSX build with OpenGL. Do I understand as well that the device can still be treated as 'just another monitor' ie. the new driver based direct mode can be bypassed?

I see you used JNA. I had a go at JNI and got something working by using SWIG to generate the Java classes and C++ wrapper. 32 bit only so far and only OVR_CAPI.

https://github.com/danielajgrout/vrstuff

I also wrote a little debug UI to capture sensor data - just out of interest. It's under danielmg.vr.jovr.ui.JOVRDebug.

Sorry about calling my thing jovr it was the first thing that came to mind, before I'd seen your build.

http://i.imgur.com/Fuy5h76.png?1

The RiftDemo is using the SDK distortion, isnt it?

"elect" wrote:
The RiftDemo is using the SDK distortion, isnt it?

Yes

"jherico" wrote:

"elect" wrote:
The RiftDemo is using the SDK distortion, isnt it?

Yes

Do you have any feedback regarding the latency? Do you think that is worth to implement it in Client distortion mode?

Anyway, I am trying to do a little jogl example using your library, but I am having a lot of problems, I guess the main is that your example is based on lwjgl..

Do I need to rewrite some of your classes, such as FrameBuffer, to port them to Jogl, dont I?

"elect" wrote:
Anyway, I am trying to do a little jogl example using your library, but I am having a lot of problems, I guess the main is that your example is based on lwjgl..

Do I need to rewrite some of your classes, such as FrameBuffer, to port them to Jogl, dont I?

Yes, my GL classes won't work out of the box with JOGL. You don't have to use the classes though. You can use raw JOGL instead of wrappers.

"jherico" wrote:

"elect" wrote:
Anyway, I am trying to do a little jogl example using your library, but I am having a lot of problems, I guess the main is that your example is based on lwjgl..

Do I need to rewrite some of your classes, such as FrameBuffer, to port them to Jogl, dont I?

Yes, my GL classes won't work out of the box with JOGL. You don't have to use the classes though. You can use raw JOGL instead of wrappers.

Im getting

Exception in thread "main-AWTAnimator" 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.HmdDesc.endFrame(HmdDesc.java:159)
	at joglus.example.GlViewer.display(GlViewer.java:262)
	at jogamp.opengl.GLDrawableHelper.displayImpl(GLDrawableHelper.java:649)
	at jogamp.opengl.GLDrawableHelper.display(GLDrawableHelper.java:633)
	at jogamp.opengl.GLAutoDrawableBase$2.run(GLAutoDrawableBase.java:399)
	at jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:1103)
	at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:978)
	at com.jogamp.newt.opengl.GLWindow.display(GLWindow.java:610)
	at com.jogamp.opengl.util.AWTAnimatorImpl.display(AWTAnimatorImpl.java:75)
	at com.jogamp.opengl.util.AnimatorBase.display(AnimatorBase.java:416)
	at com.jogamp.opengl.util.Animator$MainLoop.run(Animator.java:188)

at the display() call, line 262

https://github.com/elect86/Joglus/blob/master/Joglolus/src/joglus/example/GlViewer.java

where I call

hmdDesc.endFrame(poses, eyeTextures);


Ps: matrixStack is temporary disable just to test if I can get at least the right clear color in the oculus..

Even just something like this returns the same exception

@Override
    public void display(GLAutoDrawable glad) {

        System.out.println("display");
        GL3 gl3 = glad.getGL().getGL3();

        Quat quat = new Quat(
                hmdDesc.getEyePose(hmdDesc.EyeRenderOrder[0]).Orientation.x, 
                hmdDesc.getEyePose(hmdDesc.EyeRenderOrder[0]).Orientation.y, 
                hmdDesc.getEyePose(hmdDesc.EyeRenderOrder[0]).Orientation.z, 
                hmdDesc.getEyePose(hmdDesc.EyeRenderOrder[0]).Orientation.w);
        quat.print("quat");

        checkError(gl3);
    }

Ps: Quat is one of my classes..

Instead if I move it inside the hdm frame handling it works (I get orient for both eyes), but then it fails the same way at the endFrame

@Override
    public void display(GLAutoDrawable glad) {

        System.out.println("display");
        GL3 gl3 = glad.getGL().getGL3();

        
        
        hmdDesc.beginFrame(++frameCount);
        for (int i = 0; i < 2; ++i) {
            int eye = hmdDesc.EyeRenderOrder[i];
            Quat quat = new Quat(
                hmdDesc.getEyePose(hmdDesc.EyeRenderOrder[0]).Orientation.x, 
                hmdDesc.getEyePose(hmdDesc.EyeRenderOrder[0]).Orientation.y, 
                hmdDesc.getEyePose(hmdDesc.EyeRenderOrder[0]).Orientation.z, 
                hmdDesc.getEyePose(hmdDesc.EyeRenderOrder[0]).Orientation.w);
        quat.print("quat");
            {
                frameBuffers[eye].activate(gl3);
                {
                    render(gl3);
                }
                frameBuffers[eye].deactivate(gl3);
            }
        }
        hmdDesc.endFrame(poses, eyeTextures);

        checkError(gl3);

Replacing begin/endFrame with FrameTiming it works like a charm..