JOGL/Rift/jocular - Exception in thread "main-Display-.windows_tiny-1-EDT-1"

CONTENTS DELETED

So I have moved my Rift test over to a new windows box.  Now I'm seeing a new exception (below).

My project is at:

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

JOVR 0420 works, but if you switch the pom to 0430 then the RiftClient0430 example fails.

I've been trying to get some help on the Oculus forums, but now I'd like someone here to please take a look at the exception and my code in case I'm doing something wrong with my JOGL setup / initialisation. Thanks.

https://forums.oculus.com/viewtopic.php?f=20&t=16263&start=20

step 7 - window
Found Rift Monitor
got: GL4bc
reshape loc 0,0 size 1920x1080
Exception in thread "main-Display-.windows_tiny-1-EDT-1" javax.media.opengl.GLException: Caught Error: Invalid memory access on thread main-Display-.windows_tiny-1-EDT-1
	at javax.media.opengl.GLException.newGLException(GLException.java:75)
	at jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:1311)
	at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:1131)
	at com.jogamp.newt.opengl.GLWindow.display(GLWindow.java:675)
	at jogamp.opengl.GLAutoDrawableBase.defaultWindowRepaintOp(GLAutoDrawableBase.java:213)
	at com.jogamp.newt.opengl.GLWindow.access$100(GLWindow.java:119)
	at com.jogamp.newt.opengl.GLWindow$2.windowRepaint(GLWindow.java:136)
	at jogamp.newt.WindowImpl.consumeWindowEvent(WindowImpl.java:3692)
	at jogamp.newt.WindowImpl.consumeEvent(WindowImpl.java:2665)
	at jogamp.newt.DisplayImpl.dispatchMessage(DisplayImpl.java:664)
	at jogamp.newt.DisplayImpl.dispatchMessage(DisplayImpl.java:691)
	at jogamp.newt.DisplayImpl.dispatchMessages(DisplayImpl.java:727)
	at jogamp.newt.DisplayImpl$7.run(DisplayImpl.java:656)
	at jogamp.newt.DefaultEDTUtil$NEDT.run(DefaultEDTUtil.java:343)
Caused by: 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.Hmd.endFrame(Hmd.java:179)
	at com.sunshineapps.riftexample.RiftClient0430$DK2EventListener.display(RiftClient0430.java:196)
	at jogamp.opengl.GLDrawableHelper.displayImpl(GLDrawableHelper.java:690)
	at jogamp.opengl.GLDrawableHelper.display(GLDrawableHelper.java:672)
	at jogamp.opengl.GLAutoDrawableBase$2.run(GLAutoDrawableBase.java:441)
	at jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:1277)
	... 12 more
step 8 - loop

Hi

We don't use JNA, it comes from your code, JOGL just catches the error.

Is there any way I can avoid the reshape call in JOGL? ie. by having something already initialised with the correct dimensions?  It seems to be related to my display being called before my animator is started.

You can put a flag into your implementation of display and/or reshape to control when you consider it should really do something but I don't know how you initialize JOGL, I have to look at your code a bit more.

Edit.: Please use the class Buffers instead of trying to do almost the same when creating your direct NIO buffers. Your management of those objects is quite poor, you shouldn't need to recreate them in reshape(). Sorry for my silly question but why not using JOGL classes to access Occulus?

The delayed display flag didnt help (key press triggered).  I was basing that option on the response I got on the Rift forum, ie. that there was something clashing between the two APIs.

I think I found the Buffer class you mean, GLBuffer? Well I implemented that one now.  Thanks for the tip.

I dont think JOGL is supporting DK2 yet, Sven was waiting for a test unit I think.  Plus I wanted to be on the latest SDK rendering pipeline.

btw is there a good test case showing proper shutdown etiquete? the 042 test gives me some exceptions.

Anyway thanks for looking at my code.  I've updated a few things again, but so far no progress.  I may try again over on the Oculus forum if you think my JOGL code is looking correct.

No I meant Buffers:
http://jogamp.org/deployment/jogamp-next/javadoc/gluegen/javadoc/com/jogamp/common/nio/Buffers.html

I don't see why JOGL would influence a context out of its control, you don't call GLDrawableFactory.createExternalGLContext().

Which exceptions??

In my humble opinion, "JOVR" uses JNA which is slower than JNI and it has no intention to support other VR hardware than Occulus, its name is confusing and it has nothing to do with JogAmp (it doesn't use GlueGen), picking such a name is opportunist and anyway JOGL will get some DK2 support. You might waste a lot of time in making your solution work but I don't want to discourage you to do so.

Ah thankyou, the example I found somewhere was using GLBuffers, confusing.

OK thanks for investigating.  The inner workings of both libraries is far too complex for me.  Shame if they can not coexist like this though.  Although I think another user has them working ok with more modern OpenGL.  Maybe I try and see if that runs on this windows box next.

Shutdown log:

attempt shutdown
doing SHUTDOWN
animator.stop
animator.stop - done
hmd.destroy & Hmd.shutdown
hmd.destroy & Hmd.shutdown - done
glWindow.destroy
STOP
NativeWindowFactory.shutdown: Caught java.lang.NullPointerException during customShutdownHook #1/3
Thread[main-Display-.windows_tiny-1-EDT-1,5,main]: Warning: Default-EDT about (2) to stop, task executed. Remaining tasks: 1 - Thread[main-Display-.windows_tiny-1-EDT-1,5,main]
glWindow.destroy - done
3

So do you think JOGL will include a similar thin wrapper over the SDK in the future?  The less dependencies the better :)

btw are any of the third party files I'm using currently supported elsewhere inside JOGL?  Some of it seems fairly standard stuff...

PS I think the JNA was important for the toArray(2) calls, since I was misssing this at the start, and otherwise the Rift SDK complains about the two structures not being contiguous? in memory (side by side).  Off topic, but just in case someone hits that issue with a future JOGL wrapper :)

I need the full stack trace, I don't know why you get a NullPointerException.

On 11/19/2014 11:28 AM, BrickFarmer [via jogamp] wrote:
> So I have moved my Rift test over to a new windows box.  Now I'm seeing a new
> exception (below).

Hi all,

while I have no time to discuss this OVR binding,
at least I can confirm that our OVR binding in JOGL
will be updated this year.

We probably will add support to DK2 within our DK1 SDK binding,
which does not include head-tracking and hence not requiring
the binary blob.

We will also add a binding to the DK2 SDK, which requires the
binary blob for headtracking. The latter seems to be possible now,
since all drivers have been released by now.

Please forgive me my little time I currently have available,
family business (our new born son) requires a lot attention
within the first three month :)

+++

However - if you like to add support for another binding using JOGL,
or like to perform above mentioned tasks,
please have a look at our stereo API.

The API:


<http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/util/stereo/package-summary.html>

StereoClientRenderer, putting it all together (GLEventListener, ..):


<http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/util/stereo/StereoClientRenderer.html>

The demo:
  com.jogamp.opengl.test.junit.jogl.stereo.StereoDemo01

~Sven

I've removed the shutdown hook for now, that was just a distraction from the real problems.  
ie. the exception on 0430 and my strange projection issues that warp the scene.

I've updated my code to work without having a Rift now (flag is 'useDebugHMD')  :)  Since this is my first github experience, I'd be interested if anyone manages to run the code, or if I'm missing something from my commits.

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

I'm going to bounce this back over to the Oculus forum and see if anyone there can help.  Thanks for your inputs, and if you see anything I can be doing in a better 'JOGL way', please let me know!

Can someone please check if I am using NEWT correctly in my example please.  I tried another demo that was using NEWT but somehow attached to AWT window and that was working.  So now I'm wondering if it's related to my setVisible call.

Is there a simple test/example showing 'best practice' for startup and shutdown of NEWT window please?

Why do you call that? glWindow.setAutoSwapBufferMode(false)???

If I recall correctly, the Oculus SDK is now responsible for the buffer swap.  

That's why I think there is a clash here between what I manage on the OpenGL side and what the SDK manages.  For example I shouldnt need a resize, but JOGL seems to call that to initialise itself? and I think that the context may already be with the SDK.  So probably this is one of those 'getting the right sequence of startup events' on both APIs.  I'm new to NEWT so that's why I wanted to make sure I had the startup sequence / handling correct.

You don't use an external context, your JOGL drawable has its own OpenGL context or I missed something in your code.

The code is pretty much self contained in that example now, and runs without a rift with the useDebugHMD flag.

The author of JOVR seemed to think it was something to do with a JOGL resize triggering a display call:

https://forums.oculus.com/viewtopic.php?f=20&t=16263&start=20

Something about this call to display int he context of a resize event seems to be invalidating the VAO that the Oculus SDK creates on the first call to endFrame().

To be honest I dont know enough about the details of how openGL works at the level to have a proper opinion.

Actually, if the Oculus SDK creates its own OpenGL context, you need to create an external context in JOGL to make it work, otherwise you just manipulate the context of your window.

On 11/27/2014 03:25 PM, gouessej [via jogamp] wrote:
> Actually, if the Oculus SDK creates its own OpenGL context, you need to create
> an external context in JOGL to make it work, otherwise you just manipulate the
> context of your window.

That is why I use the client renderer approach
as demonstrated w/ our binding, which I have described in this forum thread.

~Sven

gouessej wrote

Actually, if the Oculus SDK creates its own OpenGL context, you need to create an external context in JOGL to make it work, otherwise you just manipulate the context of your window.

Since I only draw into some FrameBuffer objects, I assumed that would be okay.  ie. if the SDK uses my GLwindow context, or even creates it's own context (would that overwrite my context?), it should not affect my ability to render into a separate frame buffer?  Or do I need to do something special with NEWT/GLWindow for that to work like that?  

I had a look at the mentioned externalContext, but that seems to be making things worse, ie. then I would be trying to piggy back an unknown context and unknown handling of that context.

I suspect that both APIs are using the same context, and therefore this is probably just down to the startup sequence...  

So from what I'm trying to read and learn, it sounds like I should be quite close with my current approach?

Thanks Sven, I know you are busy, but in theory, is my JOGL approach correct for what I'm trying to do?  

Probably the issue is with 0430 since I got the earlier SDK running with JOGL :)  but I want to be sure my NEWT / JOGL code is correct :)