Basic Linux Rift library with OpenGL in C

"Fawz" wrote:
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.

Hrmm... disappointing! Is the Rift detected? I used nsb's gltest1 as a basis to work from (I wasn't familiar with glut) --does gltest1 track?

"Fawz" wrote:
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?

I've wondered about this too, but since the different cups are to correct for user eyesight, the end result might be (ideally) the same -- this thought satisfied me enough to not get sidetracked by another detail, but I'm not an optics engineer. :)

"Fawz" wrote:
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?

I think this is for future use, allowing for possibly different distortion equations, or "none".

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

Geekmaster had previously posted such a list, here (I'm not sure if it's as thorough as you're looking for):

"geekmaster" wrote:
https://developer.oculus.com/forums/viewtopic.php?f=20&t=32#p3962

Thanks for the great fast answer! Good to know I'm not the only one to wonder about those things :P The list will certainly get me started, thanks for the link.

The sensors not working must have been something on my end :oops: though I don't know what, something must have been blocking access to the usb device. It was recognized correctly, permissions were set, gltest1 worked, but gldemo didn't. Then gltest1 also didn't work anymore, I tried another usb port and now both gldemo and gltest1 also works :P So that's good.

Does anyone know if nsb is still working on this? Is there any intent on being able to have the ability to use this instead of the official driver with games?

"theyain" wrote:
Does anyone know if nsb is still working on this? Is there any intent on being able to have the ability to use this instead of the official driver with games?

I think nsb is busy with work. He had just added support for HIDAPI, and was going to test Mac/Windows. I have no means for testing those platforms, but I have some changes to apply... I also want to break out the "stereo" portion of gldemo, either as an optional part of the library or companion library. I'll see if I can get hold of him for his thoughts on a public repo or whether he'll have time in the foreseeable future.

I'm using this for games. I was pursuing the same course, but he got there first, so switched to his lib. I can't use the official SDK, and have doubts it will suit me later (though maybe the addition of Tom Forsyth will change that...).

Oops. I knew I had to look around before starting my own lib...

Anyway, I've started writing a C lib (reading the SDK to get the HID reports... one should probably document them on the wiki?). It's intended to be simple, clean, and relatively HMD-agnostic.

It doesn't provide any OpenGL helper or anything like that, but it gets the physical parameters from the rift, and computes things like vertical fov, aspect ratio, distortion from it (well, I'm using the values hardcoded in the SDK for the distortion coefficients... the rift seems to report garbage...).

I'm now trying to get the sensors working... I should have the raw values, but I need to do some sensor fusion stuff before it's of any use. And I don't want to copy the SDK for that (one issue I have with the SDK is the license, so, I'm trying to avoid writing a derivative!)

One other thing I'm not too happy with is the use of hidapi. It seems to be the most simple and portable lib to handle HID devices, but it requires some manipulations from the user... I'm not sure there's a better way, though...

http://hg.sitedethib.com/libvr/

The latest public nsb code does not work on some linux distros (but it DOES work on my Raspberry Pi). So, I switched to the signal11 hidapi code, which also supports libusb (more linux distros, and Windows support too). The OculusVR SDK also has additional features, but if you only need tracker support there are multiple options, like this library.

Hi,

after my Rift arrived I gave this SDK replacement a try to get started on Linux. It works so far (by using code from the gltest1.c example, so I create a thread to sample the device), but it feels not as smooth as the demos I tested on Windows on the same machine. Is this a known issue (e.g. due to less complex sensor fusion) or does anyone has additional tips about how to get the best data out of this lib? Thanks!

Hi,

So, a friend and I have been working on a cross platform driver (Linux included) in C for a while now. This thread sort of pushed us over the edge to make an announcement. We have a project website and a github repository up...

website: http://openhmd.net/
github: https://github.com/OpenHMD/OpenHMD
reddit thread: http://www.reddit.com/r/oculus/comments/1f7vwl/openhmd_a_free_and_open_source_cross_platform/

It is quite usable already, with basic sensor fusion, view matrix calculations, etc. The OpenGL example also provides the necessary shaders for the barrel distortion.

Give it a spin!

noname, great stuff! The architecture looks really similar to mine!
Now, I have to decide whether I should continue mine or work on/with your stuff instead...
By the way, I now have basic sensor fusion (gyro integrating, no filtering, pitch correction as described in Steve LaValle's post, but no filtering yet), and it looks good :)
For the record, I did not copy code from the Oculus SDK, but I have been reading the HID packet handling directly in it, so, it's maybe not exactly clean room here... I implemented sensor fusion as described in Steve LaValle's article, so, it's probably similar in the end.

Edit: I don't think having multiple libs makes much sense, we should probably communicate a bit more and discuss API design and stuff like that. Are you guys available on IRC or XMPP?

Yes, I just created a channel on freenode: #openhmd. Let's talk. :)