JOVR 0.4.3.0: Java/Maven bindings for 0.4.3

Wow, that was quick. Thanks again for your efforts! I'm really excited to finally move my entire project to SDK 0.4.

"bluenote" wrote:
Wow, that was quick.

Actually I feel bad for not releasing it Friday night.

My CMake stuff for building the SDK is pretty mature at this point. The C API changes in this release were minimal, so I just had to tweak the existing bindings rather than regenerating them, which can be a pain. Most of the work just involved building the binaries on each of the 3 platforms (4 if you count 32 / 64 bit windows separately) and getting tests running. Sadly the Linux testing didn't work very well, so I'm not sure how well it will work on other systems. I'm having trouble getting Linux to play nice with my GeForce 970, and the current Oculus SDK won't work properly with my motherboard's Intel chipset.

I usually see the JAR for simple downloading here:

http://mvnrepository.com/artifact/org.saintandreas/jovr

... but I don't for 0.4.3.0 :(

EDIT: Found it here!

http://repo1.maven.org/maven2/org/saintandreas/jovr/0.4.3.0/

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?

Hi jherico,

thanks for the update!

Anyway I saw now

public Posef getEyePose(int eye)

is deprecated, but if I switch to the

public Posef[] getEyePoses(int frameIndex, OvrVector3f[] hmdToEyeViewOffsets)

I get the continuos memory location error..


Ps: anyway I saw they somehow reduced the visible area by increasing the black area at the borders... why?

@phr00t: I only had time for a very quick test yesterday evening and this was also what I was experiencing (black screen, but I only tested under Linux). I will try to port my own examples tonight to see what I'm doing wrong.

One very weird thing I observed: Running any of the examples made my PC "scream". I don't know if it was a fan or maybe a mainboard capacitor. I was quite puzzled since my PC never made that noise before, even under very heavy load (it is a silent setup in general). At first, I even neglected the possibility that it could be the demo. But the noise was fully deterministic, i.e., it started right after launching a demo and stopped immediately after terminating. Anyone else experiencing this?

@elect: To my knowledge, the idea is to make the borders less pronounced (more like fading out). There seems to be mixed reactions over at reddit: Some hate it, some like it...

"elect" wrote:
if I switch to the

public Posef[] getEyePoses(int frameIndex, OvrVector3f[] hmdToEyeViewOffsets)

I get the continuos memory location error..

You have to allocate the eye offsets like this:

  private final OvrVector3f eyeOffsets[] =
      (OvrVector3f[])new OvrVector3f().toArray(2);

And you have to initialize them like this:

    final EyeRenderDesc eyeRenderDescs[] = hmd.configureRendering(
        rc, distortionCaps, fovPorts);

    for (int eye = 0; eye < 2; ++eye) {
      this.eyeOffsets[eye].x = eyeRenderDescs[eye].HmdToEyeViewOffset.x;
      this.eyeOffsets[eye].y = eyeRenderDescs[eye].HmdToEyeViewOffset.y;
      this.eyeOffsets[eye].z = eyeRenderDescs[eye].HmdToEyeViewOffset.z;
    }

You must not do something like this:

    for (int eye = 0; eye < 2; ++eye) {
      this.eyeOffsets[eye] = eyeRenderDescs[eye].HmdToEyeViewOffset;
    }

"elect" wrote:

Ps: anyway I saw they somehow reduced the visible area by increasing the black area at the borders... why?

They start the vignette effect earlier apparently. I've no idea why.

"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've been able to get the C++ version to run on Linux, so it's not a problem with the SDK. However on Linux you do have to populate the X11 Window and Display stuff in rendering config. This is challenging because Java doesn't really make it easy to get at the native window identifiers. I've been trying to get it working correctly, but without luck so far. If I get a working example I'll let you know.

I may actually have to go in and do significant surgery inside the SDK to fix the issue.

@elect: I also had an error regarding contiguous memory, but in a different method. What was very useful in this case is this function in the JOVR library. In my case the problem was the eyeTextures array that I passed in endFrame.

Now my sample code is working! However, I'm currently calling Display.update() in order to see anything (otherwise just black screen). I guess I'm not supposed to call it (it is commented out in the RiftApp example), since it seems to mess with the frame timing (judder), but for today that's good enough :). I also noticed that the ovrDistortionCap_NoSwapBuffers flag is no longer there. I guess this means that swapping is now always the job of the SDK in endFrame? Maybe I have missed it, but is there currently a way to disable vsync completely?

Thanks for your answers, jherico and bluenote :)

"jherico" wrote:

You have to allocate the eye offsets like this:

  private final OvrVector3f eyeOffsets[] =
      (OvrVector3f[])new OvrVector3f().toArray(2);

And you have to initialize them like this:

    final EyeRenderDesc eyeRenderDescs[] = hmd.configureRendering(
        rc, distortionCaps, fovPorts);

    for (int eye = 0; eye < 2; ++eye) {
      this.eyeOffsets[eye].x = eyeRenderDescs[eye].HmdToEyeViewOffset.x;
      this.eyeOffsets[eye].y = eyeRenderDescs[eye].HmdToEyeViewOffset.y;
      this.eyeOffsets[eye].z = eyeRenderDescs[eye].HmdToEyeViewOffset.z;
    }

Uhm.. anyway I saw they are using that hmd.configureRendering only for the SDK render mode, not the client one (as I do), is it right? In this case should I just continue to use the deprecated

public Posef getEyePose(int eye)

or..?