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

"metameta" wrote:
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.

The client application isn't responsible for rendering the framebuffer color attachments to the screen. The SDK is. Once you've rendered your scene to the offscreen framebuffers, calling OvrLibrary.ovrHmd_EndFrame(hmd, poses, textures) should cause the content to be rendered to the Rift screen with the proper distortion. It's also important to remember that for this to work, the SDK becomes responsible for performing the swapbuffer operation, so you need to disable it in your own application.

For JOGL, that means finding where you're calling GLAutoDrawable.swapBuffers() and disabling it when rendering to the Rift.

The client application isn't responsible for rendering the framebuffer color attachments to the screen. The SDK is. Once you've rendered your scene to the offscreen framebuffers, calling OvrLibrary.ovrHmd_EndFrame(hmd, poses, textures)

Ok this is what I guessed. Thank you. What I'm still confused about is how are the framebuffers attached to the window (Display)? Is it glBindFramebuffer that does it? The SDK only knows about the 2 textures. We don't tell it about the window, so I assume the textures or framebuffers must know they are supposed to draw to the window. Is that what the binding is about? And it just knows because the window is the current context when we create and bind them?

In Processing there is a GLCanvas which is the main window. I can create PGraphics objects which in turn create offscreen buffers but I don't think they are bound to anything. I have to manually draw them to the main window. There's one place that calls swapBuffers() but it only gets called on dispose(). Maybe Processing is just not set up in a way that would play nice with the SDK rendering?

"metameta" wrote:
Ok this is what I guessed. Thank you. What I'm still confused about is how are the framebuffers attached to the window (Display)? Is it glBindFramebuffer that does it?

In OpenGL terms, a framebuffer is a drawing surface. An OpenGL Context at any time has an active 'draw' framebuffer. Typically this represents the surface of the OpenGL window displayed on the screen. However you can create additional framebuffers that act as offscreen rendering targets. Calling glBindFramebuffer makes a given framebuffer active (with 0 always being the default framebuffer). Once a framebuffer is bound, all subsequent rendering calls go to that framebuffer.

"metameta" wrote:
The SDK only knows about the 2 textures. We don't tell it about the window, so I assume the textures or framebuffers must know they are supposed to draw to the window.

We bind the framebuffers and render the scene to each one, which paints the scene to the textures attached to the framebuffer, with slightly different views and different projection matrices for each one. When we're done with them, we unbind the framebuffers, making the window once again the rendering target. When we hand the two textures to the Oculus SDK, it defaults to painting to the window because that's the default target of the OpenGL context.

"metameta" wrote:
Maybe Processing is just not set up in a way that would play nice with the SDK rendering?

It's possible. If processing doesn't let you override the buffer swapping mechanism, it would still be possible to do client side distortion rendering, but it's significantly more complex than just handing the textures to the SDK.

Ah! Ok that's a very helpful explanation. Thanks, I'll keep looking through Processing source tomorrow with a better picture of what's going on.

EDIT: couldn't wait, and I found a line to comment out in Processing. Works like a charm. It's definitely a hack, but it's a one liner so I'm happy with it for now. Thanks again for your help! That last post really made things click.

"jherico" wrote:

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.

Ah yes, thanks for that! I was initially pointing at the LibOVR directory and something got cached by cmake.
Anyway I've now managed to build the dylib, but got the same compatibility issue. I fixed it by setting the following before building:

MACOSX_DEPLOYMENT_TARGET=10.8

So now I'm another step closer...

setupOculus()
OVR::DeviceManagerThread - running (ThreadId=0x0x1a1f62000).
OVR::DeviceManager - initialized.
*** SensorFusion Startup: TimeSeconds = 1408720717.577994
Exception in thread "main" java.lang.UnsatisfiedLinkError: Error looking up function 'ovrHmd_ConfigureTracking': dlsym(0x7f8031a38eb0, ovrHmd_ConfigureTracking): symbol not found

Is the sensor stuff included in the dylib that I've now build? I copied the dylib to the jocular project and rebuilt that. This is how I'm running the example I found:

java -cp dist/OculusRoomTiny.jar:lib/jogl-all.jar:lib/Jglm.jar:lib/javaUnofficialOpenglSDK.jar:lib/jna-4.1.0.jar:lib/gluegen-rt.jar:lib/jovr-0.4.1.2-SNAPSHOT.jar -Djava.library.path=lib roomTinySimplified.core.OculusRoomTiny

Since jna is doing the unpacking of the dylib I assume I dont need any oculus related natives in my lib directory?

"whitehexagon" wrote:
So now I'm another step closer...

setupOculus()
OVR::DeviceManagerThread - running (ThreadId=0x0x1a1f62000).
OVR::DeviceManager - initialized.
*** SensorFusion Startup: TimeSeconds = 1408720717.577994
Exception in thread "main" java.lang.UnsatisfiedLinkError: Error looking up function 'ovrHmd_ConfigureTracking': dlsym(0x7f8031a38eb0, ovrHmd_ConfigureTracking): symbol not found

ovrHmd_ConfigureTracking is a new function in 0.4.x (it was named ovrHmd_StartSensor in 0.3.x). The fact that it's failing on that function and not on something ovrHmd_Create() seems to imply that perhaps it's somehow picking up an 0.3.x

"whitehexagon" wrote:
Is the sensor stuff included in the dylib that I've now build? I copied the dylib to the jocular project and rebuilt that.

It is. The library should be exporting all of the C API.

"whitehexagon" wrote:
This is how I'm running the example I found:

java -cp dist/OculusRoomTiny.jar:lib/jogl-all.jar:lib/Jglm.jar:lib/javaUnofficialOpenglSDK.jar:lib/jna-4.1.0.jar:lib/gluegen-rt.jar:lib/jovr-0.4.1.2-SNAPSHOT.jar -Djava.library.path=lib roomTinySimplified.core.OculusRoomTiny

Since jna is doing the unpacking of the dylib I assume I dont need any oculus related natives in my lib directory?

I suggest you do two things. First launch your application with "-Djna.debug_load=true". This should cause JNA to print out the exact path it uses on loading libraries. The second thing is, once you've determined the exact location the library is being loaded from, scan it with nm to dump the symbol list and verify that ovrHmd_ConfigureTracking is there. If ovrHmd_StartSensor is there instead, you've got a build of the 0.3.x SDK. If both are missing then there's some other build issue that I'd probably have to diagnose.

Hah! my fault entirely. I grabbed the main branch of the project not realising the 0-4-1 stuff was on a separate branch. Apologies if I wasted your time, but thanks for helping me get to the bottom of this. Next I have some Java specific issue that I'm going to post on the JOGL site.

Exception in thread "main-AWTAnimator" com.jogamp.opengl.util.AnimatorBase$UncaughtAnimatorException: javax.media.opengl.GLException: Caught GLException: Not a GL3 implementation on thread main-AWTAnimato

Hi.

This 'juddering' you speak of, is it as if the framerate is really low when moving the HMD? While everything is smooth as long as it's still?

Bumping for new version

Thanks for the fast update jherico!