Oculus Rift Support?

I read somewhere that JOGL has some Oculus Rift support now? :) Is this for DK2? Any pointers as to what demo or test I should be running (OSX).  Is it included in the jogamp/current/achieve downloads, or do I need to build from sources?

On 08/19/2014 06:02 PM, BrickFarmer [via jogamp] wrote:
> I read somewhere that JOGL has some Oculus Rift support now? :) Is this for
> DK2? Any pointers as to what demo or test I should be running (OSX).  

We currently include 'Oculus VR RIFT SDK 0.3.2'
in our build (git sub-module).

In theory it should also support DK2,
however, the new SDK says 'added DK2' support.

Hence me mentioning in the other thread (RoomTiny),
that I need to update the SDK we build and support.

Please have a look at our Siggraph 2014 slides and
at StereoDemo01 in our unit tests (jogl git repo).

> Is it
> included in the jogamp/current/achieve downloads,
It is included, and you need to add 'jar/atomic/oculusvr.jar'
to your classpath.

> or do I need to build from
> sources?
No, but you can.

~Sven

Looks interesting! I've managed to build the sources but I'm stumbling over this dependency:

java -cp build/jar/jogl-all.jar:build/jar/jogl-all-natives-macosx-universal.jar:build/jar/atomic/oculusvr.jar:build/jar/atomic/oculusvr-natives-macosx-universal.jar:build/jar/jogl-test.jar com.jogamp.opengl.test.junit.jogl.stereo.StereoDemo01
Exception in thread "main" java.lang.NoClassDefFoundError: com/jogamp/common/type/WriteCloneable

It looks like a gluegen dependency? is that right and if so which jar am I best using?

I also read through the siggraph slides (link missing from your front page) and found the stereo renderer references. My Java is very rusty after a few years ion iOS.  But I had a quick browse of the code.  One idea I had about this kind of rendering was that not the whole scene needs to be rendered twice.  It should be possible to pass in a FBO for the background to each eye renderer.  ie. a single distant background.  That might involve some low level clone of an FBO, if that is possible, so that each stereo renderer is drawing on top of the same background.  Just an idea, and I'm a long way from being able to know if that's possible :)  I'm still trying to work out wether to use objective-c or Java for my next project.

btw running the NEWT unit tests gave me some very tantalising insights into what's now possible with JOGL, exciting stuff!

On 08/20/2014 12:54 PM, BrickFarmer [via jogamp] wrote:
> Looks interesting! I've managed to build the sources
which is ofc optional - but possible

> but I'm stumbling over this dependency:
>
> java -cp
> build/jar/jogl-all.jar:build/jar/jogl-all-natives-macosx-universal.jar:build/jar/atomic/oculusvr.jar:build/jar/atomic/oculusvr-natives-macosx-universal.jar:build/jar/jogl-test.jar

-cp \
../gluegen/build/gluegen-rt.jar:\
build/jar/jogl-all.jar:\
build/jar/atomic/oculusvr.jar:\
build/jar/jogl-test.jar

You missed gluegen-rt.jar

^^ Do not include the native jar files as long they are in the same folder
as their 'pure' java counterpart.

>
>
com.jogamp.opengl.test.junit.jogl.stereo.StereoDemo01
> Exception in thread "main" java.lang.NoClassDefFoundError:
> com/jogamp/common/type/WriteCloneable
>
> It looks like a gluegen dependency? is that right and if so which jar am I
> best using?

Yup, see above.

>
> I also read through the siggraph slides (link missing from your front
> page)
Pls update your browser cache, it's there.

> and found the stereo renderer references. My Java is very rusty after
> a few years ion iOS.  But I had a quick browse of the code.  One idea I had
> about this kind of rendering was that not the whole scene needs to be
> rendered twice.  It should be possible to pass in a FBO for the background
> to each eye renderer.  ie. a single distant background.  That might involve
> some low level clone of an FBO, if that is possible, so that each stereo
> renderer is drawing on top of the same background.  Just an idea, and I'm a
> long way from being able to know if that's possible :)  I'm still trying to
> work out wether to use objective-c or Java for my next project.

It is possible to employ such mono-parts strategy sharing an FBO, ofc.
The StereoGLEventListener.reshapeForEye(..) receives the EyeParameter,
which includes knowledge of the target eye (left/right eye).

StereoGLEventListener extends CustomGLEventListener.

CustomGLEventListener.display(..) receives
the bit CustomGLEventListener.DISPLAY_REPEAT for the right eye.

Surely the Stereo*Renderer is designed for correct asymmetric FOV rendering,
see StereoDeviceRenderer API doc.
However - surely a shared FBO blended in the background is a great idea
to reduce costs.

>
> btw running the NEWT unit tests gave me some very tantalising insights
> into what's now possible with JOGL, exciting stuff!

Great that you like it.

Cheers, Sven

Sven Gothel wrote

> I also read through the siggraph slides (link missing from your front
> page)
Pls update your browser cache, it's there.

Sorry, I meant the JOGL main page, the links on the right hand side.

Anyway thanks for the extra info.  I tried again with the demo and suspect it might be designed for pre 0.4.1 SDK? because I get now a crash in some Oculus native library I think.  I'm not familiar with the earlier Oculus SDKs...

I also agree that this binary blob approach is a bit worrying.  Who knows what it's going to be doing in the future (facebook?).  Currently this blob is windows only, but I'm sure it will arrive on the mac and linux soon enough.

Anyway given the current situation I'm sure it would also be useful to also have just a thin wrapper for some requirements, especially whilst things are in flux and things like shader responsibility and other features may shift responsibility again going forward.  Is this something gluegen could be doing?  Or am I better to be focusing on JOVR for that lower level of access?  The idea of cross platform JOGL + Rift is so appealing!

Btw I'm happy to test DK2 code for you if you need!  OSX 10.5.8 Java 7 although my laptop can only handle simple Rift scenes...

glob duration 10000
glob useStereoScreen true
deviceType Default
deviceIndex 0
biLinear true
numSamples 0
useSingleFBO false
useRecommendedDistortionBits true
useVignette true
useChromatic true
useTimewarp true
useAutoSwap false
OVR::DeviceManagerThread - running (ThreadId=0x0x19713d000).
OVR::DeviceManager - initialized.
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000019702ad1c, pid=11336, tid=6403
#
# JRE version: Java(TM) SE Runtime Environment (7.0_67-b01) (build 1.7.0_67-b01)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.65-b04 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# C  [liboculusvr.jnilib+0x5d1c]  OVR::CAPI::HMDRenderState::GetDesc()+0x5c

On 08/21/2014 01:48 PM, BrickFarmer [via jogamp] wrote:
>     Sven Gothel wrote
>     > I also read through the siggraph slides (link missing from your front
>     > page)
>     Pls update your browser cache, it's there.
>
> Sorry, I meant the JOGL main page, the links on the right hand side.
>
Ah .. thx, have to update those.

> Anyway thanks for the extra info.  I tried again with the demo and suspect it
> might be designed for pre 0.4.1 SDK? because I get now a crash in some Oculus
> native library I think.  I'm not familiar with the earlier Oculus SDKs...

We are still using Oculus VR RIFT SDK 0.3.2,
maybe a 'firmware upgrade' renders this SDK incompatible ?

Works well here w/ DK1.

As mentioned, I will experiment w/ some patches to have it working
w/ DK2 .. even though the eye tracking might not be possible
w/o the 0.4.1 SDK version.

>
> I also agree that this binary blob approach is a bit worrying.  Who knows what
> it's going to be doing in the future (facebook?).  Currently this blob is
> windows only, but I'm sure it will arrive on the mac and linux soon enough.

We probably have to make a decision here .. maybe offer both bindings.

>
> Anyway given the current situation I'm sure it would also be useful to also
> have just a thin wrapper for some requirements, especially whilst things are
> in flux and things like shader responsibility and other features may shift
> responsibility again going forward.  Is this something gluegen could be doing?
>  Or am I better to be focusing on JOVR for that lower level of access?  The
> idea of cross platform JOGL + Rift is so appealing!

Well, we do not hide a thing of the SDK, i.e. all is accessible via
'com.jogamp.oculusvr'. We just don't support the SDK rendering approach,
since it cannot be properly compatible with JOGL.
The latter is due to different path of loading the GL library
and OpenGL profile usage - on all platforms.
Hence I chose the client rendering approach.

Our JOGL Stereo*Renderer is simply our general abstraction,
but you still can use the SDK API as mentioned above.
See above - maybe due to the firmware issue, or simply that SDK 0.3.2 is not
'fit'.

Thx for your offer, will update on forum when I have a patch in.

~Sven