LWJGL 3 with Oculus Rift

[Kai]

Nice! Gonna try that out in the evening without a Rift.
Yes, the Quaternion class got renamed to Quaternionf in 1.3.0.
And since 1.3.5-SNAPSHOT, angles are now all in radians instead of degrees.
I would really encourage you to use at least the 1.3.0 release, since there were some bugs resolved in all classes of JOML.

[BrickFarmer]

I would really encourage you to use at least the 1.3.0 release, since there were some bugs resolved in all classes of JOML.

I wait for both libs to be stable in maven central first, since I also prefer the degrees for now

btw any tips on making a lightweight simple menu in LWJGL3, just to select which 'scene' my demo shows.  I'm thinking maybe a secondary window, that has a background image (if possible?) and just doing a mouse x/y check for which quarter of the screen was clicked...

[Kai]

Do you need a graphical selection for that, or would a simple keyboard input (like numpad '1' being the first scene, '2' the second, or arrow keys up/down or page up/down to cycle, etc.) suffice?

Some years ago, I came across the Themable Widget Library, which provides a "window manager" and "compositor" for LWJGL/OpenGL applications, although I believe that they are still using LWJGL2, so a little porting needs to be done. But it is really great. Have tried their demos right now, and I am impressed!

The 1.4.0 release of JOML is due to tomorrow and will deploy to Central.

EDIT: Just had a more thorough look into TWL. Boy is that a nice library with nice pluggable renderer and input support. Got it to work easily with kappa's fantastic lwjglx library to adapt LWJGL 3 to the API of LWJGL 2, which TWL currently expects. Although some few methods are missing. But it would be very little work to actually port TWL to LWJGL 3.

[BrickFarmer]

TWL looks really interesting, but keyboard is probably enough for now! why didnt I think of that!  

Also in my mission to separate out the boiler plate code, my window now ends up 'not responding' and I dont get key press info, but the scene renders fine.  I thought my render loop might be hogging the main thread, but that doesnt seem to be the case.  Any idea what might cause the window title to have the not responding message appended please?

I've checked in my latest code, MirrorWindow holds all the glfw stuff.

btw Nice to see JOML reach Central, well done!

[spasi]

Also in my mission to separate out the boiler plate code, my window now ends up 'not responding' and I dont get key press info, but the scene renders fine.  I thought my render loop might be hogging the main thread, but that doesnt seem to be the case.  Any idea what might cause the window title to have the not responding message appended please?

Why are you calling glfwPollEvents() in SwingUtilities.invokeLater? This makes no sense. The EDT is not the main thread (on Windows) and it is not the thread that created the GLFW window. You also trigger AWT initialization, which is tons of overhead. Keep it simple, move all event polling in Client.run(), which runs on the main thread. Also, there are probably more lightweight ways to throttle the mirror blit than ScheduledExecutorService.scheduleAtFixedRate.

[BrickFarmer]

Why are you calling glfwPollEvents() in SwingUtilities.invokeLater? This makes no sense. The EDT is not the main thread (on Windows) and it is not the thread that created the GLFW window. You also trigger AWT initialization, which is tons of overhead. Keep it simple, move all event polling in Client.run(), which runs on the main thread. Also, there are probably more lightweight ways to throttle the mirror blit than ScheduledExecutorService.scheduleAtFixedRate.

Great it's working now, thanks for your help with that!

Yeah, I wasnt sure about that blit stuff.  I've used a similar approach for a scene animator in the past and found it very smooth, but maybe it is overkill here.  Although currently 97% CPU time is spent in novrHmd_SubmitFrame

[BrickFarmer]

Now that JOML has reached Maven, I'm just wondering if/when LWJGL 3 Rift beta support might also make it into maven?

I'd like to publish some of my new experiments over on the Oculus forums, but the setup is probably too complex right now.  I still have loads of work to complete, but I'm just wondering if there was a timeline I could work to that might help promote the LWJGL3 Rift support

otherwise I might try to build an .exe for now

[spasi]

I haven't enabled the LibOVR bindings in the official builds because:

a) It's (very) beta.
b) It's Windows-only currently.
c) The Windows build server does not have the Oculus SDK.
d) Very few people use it. You're probably the only one.

But promoting LWJGL is welcome... I'll see what I can do, will let you know.

[BrickFarmer]

I haven't enabled the LibOVR bindings in the official builds because:

a) It's (very) beta.
b) It's Windows-only currently.
c) The Windows build server does not have the Oculus SDK.
d) Very few people use it. You're probably the only one.

But promoting LWJGL is welcome... I'll see what I can do, will let you know.

a) I think people expect that, especially since the Oculus SDK will probably be in beta until the release next year of CV1

b) Sadly I dont think they change that policy too soon, since they have a tie up with MS for CV1 release

c) and there is now a new SDK 0.6.0.1 if you do get a chance for that.

d) Probably right, but I'm doing my best to change that, and I can help test new builds as and when you release them   and of course I try to make more demos to show whats possible.  maybe even some with modern OpenGL as soon as I get my head around it

This time next year there will be a lot of units out there, and probably more developers looking to jump on the VR bandwagon.  Maybe Unity is the preferred choice right now, but if the cross platform support comes back to Oculus, then I think people will consider Java as a good choice for that.  Especially if they manage to combine the mobile and desktop SDKs into a common ES2 platform.  Thanks anyway for the great work so far, here is a peak at my next demo:

https://www.youtube.com/watch?v=ZD1ry73TW2I

[spasi]

The latest nightly (3.0.0b #8) now comes with LibOVR 0.6.0.1 bindings. Have fun!

[BrickFarmer]

Thanks!!  Well I downloaded the nightly and it took me 10 mins to update a few API changes and implement the new performance HUD from the latest SDK (F11 in my demo) so that's already a much easier process

I spent the rest of the day trying to get LWJGL into my local maven repository.  I kinda managed to get that working including the .dll. Next I try to find a solution for setting the java.library.path.  I will feed back if I get that working. Thanks. Peter

[spasi]

This sample project might help.

[BrickFarmer]

Is the statement there correct, or the plan going forward? 'LWJGL also releases snapshot builds daily to SonaType'

It's a slightly different approach than what I found:

http://stackoverflow.com/questions/7515504/maven-project-with-native-dependency-and-copying-files

but neither one is ideal, since for example openAL is in a different .dll but shares the same master .jar.  The problem is more with mavens approach of one artifact per pom.  I had a look this morning at the maven natives plugin, and trying to pack the dll into a jar, and then unpack it into /lib, but it was all getting very messy!

Next I'm looking at Gradle, seems a lot more flexible...

[spasi]

Is the statement there correct, or the plan going forward? 'LWJGL also releases snapshot builds daily to SonaType'

Yes, it is: https://oss.sonatype.org/content/repositories/snapshots/org/lwjgl/lwjgl/3.0.0b-SNAPSHOT/

It's a slightly different approach than what I found:

http://stackoverflow.com/questions/7515504/maven-project-with-native-dependency-and-copying-files

Not sure what the best practice is, but keep in mind that we also support 3 OSes. Times 2 files, that's 6 artifacts. Would get messy and it doesn't scale well if we add more libraries in the future.

[BrickFarmer]

Great! I was assuming that this maven work hadn't yet been done for LWJGL, and was trying to be helpful in my own way. 

Anyway I tried gradle today, and I felt like I swapped one set of problems for another   So I went back to maven and the link you provided,  I added the SharedLibraryLoader and now my project is pulling direct from sonotype, and doesnt require the java.library.path setting, which is another step in making things easier.  Thanks for the info!