Forum Discussion
jherico
11 years agoAdventurer
JOVR 0.4.4.0: Java/Maven bindings for 0.4.4
I've updated my Java bindings for SDK 0.4.4. The source code can be found on Github here. Example code can be found here.
Developers using Maven (or a Maven compatible tool like Gradle) can declare a dependency on the following artifact:
Known issues
Developers using Maven (or a Maven compatible tool like Gradle) can declare a dependency on the following artifact:
<dependency>
<groupId>org.saintandreas</groupId>
<artifactId>jovr</artifactId>
<version>0.4.4.0</version>
</dependency>
Known issues
- Only light testing has been done.
28 Replies
- whitehexagonExplorerIs that already pushed to maven repository? it's not showing up so far. Thanks.
- jhericoAdventurerWhoops, forgot to promote it from the staging repository. Should show up in a few minutes.
- whitehexagonExplorerThanks. Great job btw :)
So I saw the documented change for 'RTSize is now BackBufferSize'.
Is it still required to do the toArray call, since there seems now to be a new Texture sub structure (ogl).private final GLTexture eyeTextures[] = (GLTexture[]) new GLTexture().toArray(2);
Anyway thanks for adding support for OSX 10.8.5! And this release seems to have fixed the strange exception I was seeing with the endFrame call under JOGL. I was about to port it over to LWJGL3!
Anyway my basic scene is now running under OSX, so I'm very pleased about that :) On windows maven is struggling to pull in the JOVR dependency. Maybe its pulling from another proxy server that hasn't synced up yet.
I'm still doing something wrong with the processing of the Position/Orientation and model view stuff. Here is my test if any one is willing and able to assist:
https://github.com/WhiteHexagon/example-jovr-jogl-rift - bluenoteExplorerI was trying to run your code (under Linux), but I get:
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:293)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.RuntimeException: javax.media.nativewindow.NativeWindowException: X11Util.Display: Unable to create a display(tiny) connection. Thread com.sunshineapps.riftexample.RiftClient0440.main()
at jogamp.newt.ScreenImpl.create(ScreenImpl.java:143)
at com.jogamp.newt.NewtFactory.createScreen(NewtFactory.java:217)
at com.sunshineapps.riftexample.RiftClient0440.run(RiftClient0440.java:321)
at com.sunshineapps.riftexample.RiftClient0440.main(RiftClient0440.java:428)
... 6 more
Caused by: javax.media.nativewindow.NativeWindowException: X11Util.Display: Unable to create a display(tiny) connection. Thread com.sunshineapps.riftexample.RiftClient0440.main()
at jogamp.nativewindow.x11.X11Util.openDisplay(X11Util.java:452)
at jogamp.newt.driver.x11.ScreenDriver.runWithTempDisplayHandle(ScreenDriver.java:266)
at jogamp.newt.driver.x11.ScreenDriver.validateScreenIndex(ScreenDriver.java:226)
at jogamp.newt.ScreenImpl.create(ScreenImpl.java:121) - jhericoAdventurer
"bluenote" wrote:
I was trying to run your code (under Linux), but I get:
Is the code checked in anywhere so I can try it out? - jhericoAdventurer
"whitehexagon" wrote:
Is it still required to do the toArray call, since there seems now to be a new Texture sub structure (ogl).
Yes. The change to the types is because I'm trying to more closely mirror what the C API interface looks like, which means expressing the texture and rendering config data as a union. But the array allocation requirement comes because the API requires you to pass in a fixed size array to the method."whitehexagon" wrote:
Anyway thanks for adding support for OSX 10.8.5! And this release seems to have fixed the strange exception I was seeing with the endFrame call under JOGL. I was about to port it over to LWJGL3!
Well, that must be something internal to the OVR library, cause I didn't change anything."whitehexagon" wrote:
https://github.com/WhiteHexagon/example-jovr-jogl-rift
I'll try to find the time to take a look, but I can't promise anything. - bluenoteExplorer
"jherico" wrote:
"bluenote" wrote:
I was trying to run your code (under Linux), but I get:
Is the code checked in anywhere so I can try it out?
Sorry for the confusion: I was referring to whitehexagon's example. As always, porting to the new JOVR version worked like a charm. Thanks a lot for your efforts! Unfortunately, my judder issue has not changed, but I still have things to try. Currently I'm stuck at the point that enabling timewarp now always gives me 37.5 fps -- this was not the case with the same code in 0.4.3. If you are interested: https://github.com/bluenote10/ScalaOculusRiftExample
By the way: In sheer desperation, I created a LWJGL3 branch (still on 0.4.3) of my example, because I was hoping this might change things. No luck with my judder but overall I think LWJGL3 is going in a very good direction. The GLFW bindings are looking pretty good and (surprisingly?) there also seems to be a significant performance gain -- at least with what I was testing... - phr00tHonored GuestGlad you got JOVR updated! Tried to port it to jMonkeyEngine and all I am seeing is solid distorted colors on Linux. Seems to be expanding a 1x1 area to fill up each eye, since the colors change depending on what *should* be rendered & the colors might be different in each eye. I posted a screenshot and a little more info here:
http://hub.jmonkeyengine.org/forum/topic/oculus-rift-support/page/33/#post-300490
Hoping you could help! Thanks. - bluenoteExplorer@phr00t: Did you try to access the texture header with "eyeTexture.ogl.Header" instead of "eyeTexture.texture.Header" (in this line for instance). I'm not sure what is the actual difference between the two. But if I remember correctly I think I had the same problem at first, and I somehow concluded it must be "eyeTexture.ogl.Header".
- jhericoAdventurerYeah, you need to access the texture via the ogl path, not the texture path. This has to do with the wacky way JNA handles union types.
Quick Links
- Horizon Developer Support
- Quest User Forums
- Troubleshooting Forum for problems with a game or app
- Quest Support for problems with your device
Other Meta Support
Related Content
- 1 year ago