Basic Linux Rift library with OpenGL in C

"amnipar" wrote:

Any idea if I could change something to avoid this..? I'm not really familiar with opengl so I don't know how I should debug this.

Ack. Apologies... this actually looks like you might not have a Rift attached, or it wasn't detected?

In displayFunc, following the comment "Orientation, from HMD sensor", change the code to this:

   double orient[4] = { 0., 0., 0., 1. };
   if( dev ){
      quat_set( dev->Q, orient );
      quat_multiply( orient, g_qref, NULL ); // apply inverse-reference orientation
   }

This way at least it won't segfault on no "dev", which might be what happened to you. I got a segfault at the same point when I tried an old laptop (without Rift attached).

Also, sorry for leaving the OpenGL version at 4.2. I did that to help me avoid using any deprecated features, but this code should be compatible with 3.0, or even 2.1 which supports EXT_framebuffer_object.

To run this on an old laptop of mine I had to make some other changes (it can't support shaders with conditionals, and it didn't have glut so I added SDL support, and deformable terrain didn't work yet so I'm looking at that).

Let me know if you still have problems. I might have an update that's friendly to a wider range of machines. Thanks for trying this, as I'd only run it on one system beforehand.

Actually the problem above seems to have disappeared after I set up a separate screen for my Rift (it is attached to the hdmi output of my laptop) and used DISPLAY=":0.1". Looks very good. Earlier I just cloned my display to Rift and that wasn't optimal it seems.

"amnipar" wrote:
Actually the problem above seems to have disappeared after I set up a separate screen for my Rift (it is attached to the hdmi output of my laptop) and used DISPLAY=":0.1". Looks very good. Earlier I just cloned my display to Rift and that wasn't optimal it seems.

Hmm, that's interesting. On reading your post with the screenshot I was going to suggest that your GPU might not like conditionals (multiple code-paths) -- my laptop doesn't and it created some glitchy output like that (fixed by changing the shader). Now I wonder what cloning is changing...

Thank-you for trying this out! I'd try cloning with my laptop, but it only has VGA out. :/

Thanks for elaborating atavener! I've read up on the distortion, glanced at the source and see how the display info is read from the device, so my mind is much more at ease now :) Seems things aren't so bad after all.

Oh and I also had some initial trouble running gldemo in case you're planning to develop it further. It wouldn't run on my main system at all (running fglrx from debian experimental) showing only a black screen and some shader compilation errors. The shader errors were fixed by adding a version declaration in the shaders, but still no graphics. It worked flawlessly with with another nvidia pc, cloning from(to?) the rift.

Great work for demonstrating the lib support and showing off some of your skills as well.

The following error was preventing this from running properly.
The following function

uint32_t edgeId( uint32_t a, uint32_t b ){
   if( a < b ) interleaveBits( a, b );
   else interleaveBits( b, a );
}

Should read as

uint32_t edgeId( uint32_t a, uint32_t b ){
   if( a < b )
        return interleaveBits( a, b );
   else
        return interleaveBits( b, a );
}

I originally was hitting the assert statement within adjAdd when I would run it after compiling with optimizations (-O2, -O3).
Tried to track it down but ultimately I compiled it with clang to compare warnings and errors to gcc. And got the "control reaches end of non-void function" on edgeId.

Also gcc picks up the printf on line 131 is missing the expected variable.

Thanks for the demo.
Works on Ubuntu 13.04, gforce gtx 550

James

"thegreatpissant" wrote:

The following error was preventing this from running properly.
The following function

uint32_t edgeId( uint32_t a, uint32_t b ){
   if( a < b ) interleaveBits( a, b );
   else interleaveBits( b, a );
}

*facepalm*... I've been programming in OCaml for the past several years. It took a bit to get my C legs (haha) back to write this demo, but I see I still need to be cautious. Thank-you for catching that.

A dangerous thing I've gotten accustomed to -- is the compiler catching everything. I should compile with -Wall. :)

Thanks for the update, the new version now renders on my main pc with the fglrx, though for some weird reason the sensors aren't read anymore/can't look around :P They are read and printed properly by consoletest.

I have a few questions in case anyone is feeling generous. I've been reading up on lens distortion (correction) and going through the source in libovr_nsb and gldemo.c. From what I understand, distortion coefficients are specific to a lens, but there seems to be only one set of coefficients retreived from the device. Does that mean that the three lens types in the development kit (A, B and C) have the same coefficients?

There is also a variable "DistortionType" retrieved (mentioned in gldemo.c and OVR_HID.c/OVR_Device.h) which isn't mentioned in the reference documention here on developer.oculus.com (or at least I can't find it) and which doesn't seem to be used. What does this do?

Lastly, if anyone happens to have any great reading tips for thoroughly understanding lens correction that would be very much appreciated :)