jherico / jovr

Java access to the Oculus Rift sensor device

Java bindings for using the Oculus Rift head tracker

Changes

1.3.0.0

• Initial support for Oculus SDK 1.3.0.0

0.7.0.0

• Initial support for Oculus SDK 0.7.0.0

0.4.3.0

• Initial support for Oculus SDK 0.4.3
• Linux support added to SDK, linux binary added

0.4.2.0

• Initial support for Oculus SDK 0.4.2
• Exposing high quality rendering flag (no effect on GL)

0.4.1.2

• Exposing HSW render disable method

0.4.1.1

• updating binaries

0.4.1.0

• Initial support for Oculus SDK 0.4.1
• OSX support added to SDK, OSX binary added

0.4.0.1

• Adding some annotations and missing functions

0.4.0.0

• Initial support for Oculus SDK 0.4.0
• Removed swapbuffer callback mechanism

0.3.2.5

• Adding swapbuffer callback

0.3.2.4

• Adding static init and shutdown methods to convenience class

0.3.2.3

• Added Guava dependency
• Added some argument checking with more informative errors than a crash inside the binary would provide
• Added JSR305 dependency
• Updated some Pointer types to String
• Moved OvrLibrary.ovrHmd type to Hmd
• Removed the need to expose the .ByValue types to clients
• Added some static methods to Hmd to remove the need to call OvrLibrary.INSTANCE directly
• Changed some functions which had output arguments to return the output instead: i.e. 'void foo(String[] results)' becomes 'String [] foo()'
• Defaulted all API values to OpenGL.
• Added some unit tests

0.3.2.2

• Updated SDK binary.
• Added the ovrDistortionCap_NoSwapBuffers flag for preventing SDK side buffer swapping

0.3.2.1

• Fixed incorrect Linux binary.

0.3.2.0

• Initial release of Java bindings for Oculus SDK 0.3.2
• Renamed artifact from Jocular to JOVR to reset numbering

Modified the OculusSDK to include a new value for ovrDistortionCaps: ovrDistortionCap_NoSwapBuffers

If this value isn't specified in ovrHmd_ConfigureRendering then the Oculus SDK will revert to it's default behavior of performing the SwapBuffers() call inside the SDK. However, if you include this value when configuring rendering, then the SDK will continue to exhibit the modified behavior I've introduced, and NOT perform the SwapBuffers() call in the SDK.

Most Java applications will want to include this new distortion cap value, since the parameters required for buffer swapping are not normally exposed to Java client applications.

Update 5/26: Updated to 0.3.2.1. The Linux binary was a 32 bit shared object, instead of 64 bit.

Update 5/24: I've built a new release of the Maven jars to connect with the Oculus SDK version 0.3.2. Like my previous releases, I've disabled the buffer swapping in the SDK, which means you don't need to pass any window information to the SDK in the configureRendering call.

I've also renamed the Artifact so that I can reset the versioning and match the Java jar version to the Oculus SDK version. Adding a dependency on the Java bindings should now look like this.

CODE: SELECT ALL org.saintandreas jovr [0.3.2.0, 0.3.3)

The Jar no longer depends on another jar for the binaries. Rather, the binary shared library files are baked into the main jar. The only dependency of this jar is the JNA library, which I have bumped up to 4.1.

Since the SDK now supports Linux natively, I'm using their Linux code. I've also added the OSX binary as well. Both Linux and OSX are 64-bit only. Windows still has 32 and 64 bit jars built in.

Update 5/21: I've migrated my releases to the Maven central repository. You can now use the Oculus SDK simply by adding the following into your maven project file:

CODE: SELECT ALL org.saintandreas jocular [2.0.2, 3)

My example project has been updated to reflect the latest version of the code and the central repository hosting.

The Java example project can be found independently in it's own repository here: https://github.com/jherico/jocular-examples

The main branch of the examples project consists of only three files. The Maven project file, a RiftApp base class for creating simple applications for the Rift, and a single RiftDemo class which actually draws a simple scene with a skybox and number of cubes surrounding the user.

Update 5/4:

As I mentioned in this thread, I've refactored my Github copy of the Oculus SDK to extract the C API out of the main body of code and made an individual project out of it, which produces a standalone DLL. I've now created a JNA binding for that DLL that will let you use the C API from Java.

The Java project for the bindings can be found here: https://github.com/jherico/jocular <--- new URL

The URL has changed from the old location in my OculusSDK repository, because I forgot how annoying it is to try to release a Maven project from within a larger repository.

jovr's Issues

ovr.dll for 32bit jre

Hi jherico,

I recently switched from a 64 bit to 32 bit jre (1.8), and the old OculusVR.dll is no longer found. I get the error below.

Unable to load library 'OculusVR': JNA native support (win32-x86/OculusVR.dll) not found in resource path.

Switching back to 64 bit solves the problem and everything works fine.

I saw your updates, and I believe the new library is the ovr.dll (correct me if I'm wrong), but it does not seem to be a valid library. I get "This file is not a valid 32-bit or 64-bit Windows module" when running a dependency walker. Maybe I'm doing something wrong? Any ideas?

Thanks,
Jason

[1.8.0.0] Unable to load library 'LibOVRRT64_1.dll'

Where do I get this file? I downloaded the Oculus 1.8.0 SDK and it does not contain it, nor does the jovr JAR from mavenCentral. Will LibOVR.lib work?

RiftTest

So if I try to build, it works
"
--- maven-jar-plugin:2.3.2:jar (default-jar) @ jocular ---
Building jar: C:\Users\gbarbieri\Documents\NetBeansProjects\jocular\target\jocular-0.0.3-SNAPSHOT.jar

--- maven-install-plugin:2.3.1:install (default-install) @ jocular ---
Installing C:\Users\gbarbieri\Documents\NetBeansProjects\jocular\target\jocular-0.0.3-SNAPSHOT.jar to C:\Users\gbarbieri.m2\repository\org\saintandreas\jocular\0.0.3-SNAPSHOT\jocular-0.0.3-SNAPSHOT.jar

Installing C:\Users\gbarbieri\Documents\NetBeansProjects\jocular\pom.xml to C:\Users\gbarbieri.m2\repository\org\saintandreas\jocular\0.0.3-SNAPSHOT\jocular-0.0.3-SNAPSHOT.pom

BUILD SUCCESS
"

But when I run the org.saintandreas.input.oculus.RiftTest, I get this
"
--- exec-maven-plugin:1.2.1:exec (default-cli) @ jocular ---
log4j:WARN No appenders could be found for logger (org.saintandreas.input.oculus.RiftTest).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
"
Shouldn't I get some reads from the oculus? (It is connected and on)

These are the log4j.properties
"
log4j.rootLogger=INFO, stdout

log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%-4r %-5p %c %x - %m%n
"

Ps: why there are basically a correspondence between com.oculusvr and org.saintandreas? Where does each come from?

Unable to properly load project

Hi jherico,

I am getting this whenever I try to build the jovr 0.4

Some problems were encountered while processing the POMs:
[ERROR] Unresolveable build extension: Error resolving version for plugin 'org.apache.maven.wagon:wagon-ssh' from the repositories [local (D:.m2\repository), central (http://repo.maven.apache.org/maven2)]: Plugin not found in any plugin repository @

Difference between this project and lwjgl/ovr

Just wondering why this project does not use https://github.com/LWJGL/lwjgl3/tree/3.2.1/modules/lwjgl/ovr?

Judder issues

I'm still struggling to create a usable VR experience with JOVR because of a heavy juddering. My observations are:

• I tried a lot of different approaches on client side (including jocular-examples and my minimal Scala example). Whatever I do, I get the same judder.
• I get the judder under both Linux and Windows.
• Running with vsync off (+ timewarp off) and very high framerates still judders.
• I don't think GC is to blame for the judder.
• I only get this judder with JOVR -- all native examples under both Linux and Windows run very smooth (sometimes requires specific configurations).

I have documented my observations in more detail in the Oculus Developer Forums.

Currently, I don't even know if anyone else has this problem (or can reproduce it under a certain configuration). I have no explanation at all for this behavior and I even don't think that it is an issue of JOVR. But maybe creating this as an "issue" helps to track down the true problem.

Get Started file / test fails

Hi there

Could you perhaps provide some "get started" information? I am a bit unsure wheter I actually need to install the Occulus SDK to get this working. Here is what I get on Linux 64 bit:

$ mvn --version
Apache Maven 3.0.5
Maven home: /usr/share/maven
Java version: 1.7.0_72, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-oracle/jre
Default locale: da_DK, platform encoding: UTF-8
OS name: "linux", version: "3.13.0-39-generic", arch: "amd64", family: "unix"

$ mvn package

...

T E S T S

Running com.oculusvr.capi.OvrHmdTest
Tests run: 2, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 2.171 sec <<< FAILURE!
Running com.oculusvr.capi.OvrLibraryTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec

Results :

Failed tests: testDistortionMesh(com.oculusvr.capi.OvrHmdTest)

Tests in error:
testDistortionMesh(com.oculusvr.capi.OvrHmdTest)

Tests run: 3, Failures: 1, Errors: 1, Skipped: 0

It seems the test does not create a mesh.

I realise this is probably way to little information for you to help, but perhaps you can ask me to provide some more information.

Kind regards