JOVR 0.4.3.0: Java/Maven bindings for 0.4.3

"elect" wrote:
In this case should I just continue to use the deprecated

public Posef getEyePose(int eye)

or..?

No, you can use getEyePoses even if you're using client side distortion.

"phr00t" wrote:
Unfortunately, looks like all I see is a black screen. I simply removed the JOVR 0.4.2.0 JAR & put in JOVR 0.4.3.0 on my linux machine, and its black. No crashes or exceptions... I'm running oculusd in the background. Same code displays stuff fine when I use JOVR 0.3.2.4, while 0.4.2.0 obviously can't be run...

My laptop has a NVIDIA 760M, Intel I7 if it matters... any suggestions? Is there anything I'm suppose to be doing differently?

I haven't been able to get the SDK to do distortion rendering via Java in Linux yet using the SDK. I believe that the SDK code for creating an additional context is unstable, and even though it works in C++, I think developers would be better off if they were allowed to manage their own contexts and just provide the SDK a way of switching between them.

I've made some modifications to the SDK to try this out. Here is a commit t the SDK that modifies it so that rather than using native window identifiers, it uses callbacks to the client code to manage the contexts.

I've made corresponding changes in the Java bindings here and modified my example application to conform to the new API here. Once I did this, I was able to run my example and see the output.

This is just a first pass, only targeting Linux. However, I'm going to try to experiment with this more tomorrow and see if I can produce a new JOVR version that takes this approach for all of the platforms.

The upside of this approach is that it removes the need for exposing native window identifiers. The downside is that it places the burden of managing the creation of shared contexts on the client. However, with LWJGL this is pretty simple.

Thanks for another quick release cycle!

I'm trying again to get my very simple tiled floor example with JOGL working. It is still skewing the scene :(

https://github.com/WhiteHexagon/example-jovr-jogl-rift

I tried to maven-ify my project, but I still need a custom JOVR build, because of the OSX 10.8 compatibility. Which branch should I use for 0.4.3 if I want to build it locally? I can see '0.4.x' but it looks older. Or should I use 'stable'? I wish I had documented the procedure last time... does the following sound about right:

download branch
point cmake at root
generate config
generate files
build
repackage jocular

"whitehexagon" wrote:
I tried to maven-ify my project, but I still need a custom JOVR build, because of the OSX 10.8 compatibility.

I'm sorry, what's the compatibility problem exactly?

Which branch should I use for 0.4.3 if I want to build it locally? I can see '0.4.x' but it looks older. Or should I use 'stable'?

0.4.x is going to go away, since they've finally added Linux support to the SDK, I've merged everything into the 'stable' branch which is my 'master' branch (I should probably just rename it master... I've just renamed it master).

I usually work starting from my primary book example repository 'OculusRiftExamples', but the whole example set is pretty big so checking that out takes a while. If you're just trying to rebuild JOVR then I suggest the following steps.

git clone git@github.com:jherico/OculusSDK.git
cd OculusSDK
mkdir .build
cd .build
cmake .. -G Xcode -DCMAKE_BUILD_TYPE=Release  -DBUILD_SHARED_LIBS=ON
xcodebuild -target OculusVR -configuration Release

This should produce a 'libOculusVR.dylib' file in the .build/output directory.

At that point you can unzip the JOVR jar library and replace the binary in the darwin folder.

"jherico" wrote:
I haven't been able to get the SDK to do distortion rendering via Java in Linux yet using the SDK.

You mean working properly? What I reported above (the working sample code) was under Linux. In my opinion everything seems to be working fine (general distortion, orientation + positional tracking) except for the judder. You mean that it is only working by chance? I actually wasn't even aware that the SDK is creating an additional context. I guess I have to study this a bit more to understand your motivation of that callback approach.

"bluenote" wrote:
You mean that it is only working by chance? I actually wasn't even aware that the SDK is creating an additional context. I guess I have to study this a bit more to understand your motivation of that callback approach.

Probably. The creation of the shared context seems to be very vulnerable to the drivers in use. In particular this code seems problematic.

"jherico" wrote:

"whitehexagon" wrote:
I tried to maven-ify my project, but I still need a custom JOVR build, because of the OSX 10.8 compatibility.

I'm sorry, what's the compatibility problem exactly?

0.4.1 (0.4.2 wasnt good on mac) was producing:

dyld: Symbol not found: ___sincosf_stret

I'm running OSX 10.8.5, I tried updating to 10.9, but it's no longer available! and I cant use 10.10 at the moment. So last time I just recompiled the library:

MACOSX_DEPLOYMENT_TARGET=10.8

and that has been working fine, apart my matrix issues :)

"jherico" wrote:

git clone git@github.com:jherico/OculusSDK.git
cd OculusSDK
mkdir .build
cd .build
cmake .. -G Xcode -DCMAKE_BUILD_TYPE=Release  -DBUILD_SHARED_LIBS=ON
xcodebuild -target OculusVR -configuration Release

This should produce a 'libOculusVR.dylib' file in the .build/output directory.

At that point you can unzip the JOVR jar library and replace the binary in the darwin folder.

I had to change the clone command for it to work (I'm new to git, 10yrs svn is hard habbit to kick)

git clone https://github.com/jherico/OculusSDK.git

The build had an error on nullptr in CAPI_GLE.cpp, which I changed to 0.

but now I'm seeing some more fundamental issues, maybe due to mountain lion. roughly:

unknown type name OVR_PRIVATE_FILE in OVR_OSX_FocusObserver.mm

seems like maybe some macros missing? but this is now beyond my current skills.

"whitehexagon" wrote:

unknown type name OVR_PRIVATE_FILE in OVR_OSX_FocusObserver.mm

Sorry about that. I thought I'd added the CMake code to fix that, but apparently I hadn't committed it properly. I've fixed it now with this commit: https://github.com/jherico/OculusSDK/commit/291ccb6db852a3e05421400d784a6435c99784d3

You should be able to fetch and rebase and build on OSX now.

"jherico" wrote:

You should be able to fetch and rebase and build on OSX now.

Thanks! that's working, I only had to drop the nullptr again, but it is built, and packaged :)

I've also tried to update my JOGL example to the new API, I think I got it right looking at your RiftApp from jocular examples, but now my tiled floor has completely gone, so I cant see if I still have my modelview issue. I will try again tomorrow after some sleep!

https://github.com/WhiteHexagon/example-jovr-jogl-rift

btw does JOVR now support suppressing the health insanity popup?

"whitehexagon" wrote:
btw does JOVR now support suppressing the health insanity popup?

If you're talking about the new option to disable it for development, that functionality is built into the SDK. You need to modify your JSON profile. There's another thread around here somewhere that discusses it and something in the developer docs for 0.4.3 apparently. But basically, JOVR doesn't need to do anything special to support it.