Minimal Oculus Application Tutorial

Thanks for this! One of my pieces of feedback was that I found working off the sample source much easier than the documentation, so I was going to suggest that you guys do one of these source-and-explanation tutorials. The documentation is great for understanding the "why," but I think the "how" is best communicated through something like this.

Should be helpful for others trying to get up to speed! I spent a bit of time going through the docs trying to figure out what the K-values were for the headset before realizing you could read them from the device config by looking at the sample source :)

That's a great tutorial. It really does make it easier to identify core elements.

Beginners will have some challenge wrapping their heads around the pseudo-managed pointers.

Overall it's a helpful time saver. Thanks.

Very useful guide, tyvm. I Now If you could do the same for setting up the warp and SBS rendering that would help me out quite a bit! :P

Here is an enhanced version of the Minimal App that adds acceleration data:

https://developer.oculus.com/wiki/Add ... ation_Data

"geekmaster" wrote:
Here is an enhanced version of the Minimal App that adds acceleration data:

https://developer.oculus.com/wiki/Add ... ation_Data

Technically that's a mixture of acceleration and the up vector. It will report an acceleration upwards even when the Rift isn't accelerating (and will report zero when the Rift is accelerating at 9.8m/s/s downwards). I was hoping Oculus had already separated out accelerations for us, but they are just giving us the calibrated accelerometer data.

Contrary to what that page says, it is giving you the UP vector, not the DOWN vector. The reason is, accelerometers can't detect the force of gravity or acceleration due to gravity, but can detect the equal and opposite force of you holding it up against gravity. Accelerometers work by having a weight on a spring (usually a microscopic one). It's like when you stand up on a bus, you get pushed back when the bus accelerates, and flung forwards when the bus decelerates suddenly. Most forces (like you moving your head) are applied to the outside of the Rift, while the weight has inertia and lags behind. But that doesn't happen with gravity, which pulls on the inside weight at the same time it pulls on the outside.

If you can find out which way is UP some other way (by remembering from when there was no true acceleration, and applying the change from the gyros), then you can subtract it to get a rough idea of the true acceleration, but that's not usually accurate enough for much.

Here is a "pure C" version of the minimal app that reports Orientation and Acceleration data:
https://developer.oculus.com/wiki/Tracker_Data_for_C

This C program links to a minimal C++ wrapper module (included in the tutorial) that exports C bindings for initRift() and readRift() functions. Most other languages can call these C functions, including python, lua, VisualBasic, and many more.

Enjoy!

I was just investigating my unhandled exception problem when I tried just getting rid of all my code and seeing if this minimal application worked instead, to try figure out where I'm going wrong. Lo and behold, this one appeared to work fine without any of the problems I'd had. But then I noticed something.

I tried setting a break point at the Clear() function in main(), and found that the program never actually makes it there because of the exit(0); line. If I replace the exit with a break;, then it does run the cleanup and I get the same unhandled exception problem I've been experiencing myself. Is using exit() without running the cleanup an acceptable way to end the program and something I would be able to use with my own one? So far it seems to be the only way around the problem.

"Gookanheimer" wrote:
I was just investigating my unhandled exception problem when I tried just getting rid of all my code and seeing if this minimal application worked instead, to try figure out where I'm going wrong. Lo and behold, this one appeared to work fine without any of the problems I'd had. But then I noticed something.

I tried setting a break point at the Clear() function in main(), and found that the program never actually makes it there because of the exit(0); line. If I replace the exit with a break;, then it does run the cleanup and I get the same unhandled exception problem I've been experiencing myself. Is using exit() without running the cleanup an acceptable way to end the program and something I would be able to use with my own one? So far it seems to be the only way around the problem.

Although it was important to free resources before shutting down in Windows 3.x, 32-bit Windows (Win 9x and newer) clean up and release resources for a program when the process terminates (even if you kill it with Task Manager). However, it is generally considered good practice to release all resources as soon as you are done with them, to prevent resource leaks when a program runs for a very long time (such as when running as a service or daemon in the Windows Tool Tray).

Although I did not study this problem, an unhandled exception could be caused by trying to free a resource that was already released, but there are many other potential causes as well. To prevent such problems, I like to check for non-zero pointers and handles before releasing them, and set them to zero or NULL after releasing them. That is the sort of bug I would look for first in the Clear() code.

After a little more poking around, it seems like it's coming from the DeviceManager's Clear() function. Commenting out just that line and leaving the sensor and HMD ones in gives me no problem.

Stepping through in the debugger, the only difference I've seen is that for the other two, when it ends up in OVR_DeviceImpl.cpp refCount is 1 and they seem to go through things ok. They both enter into the first branch of an If statement at line 650 and it all seems to work out fine. But when DeviceManager gets there, refCount is 3 which makes it skip to the other branch of the If statement at line 670, which then decrements refCount to 2 before exiting the function completely. Seems like this could maybe be the problem area? I'm not really sure what to do about it though, I'm very much noob. It kind of looks like it should be looping until refCount gets decremented to 1 so that that first branch is entered, but I don't know.

Seems like this tutorial is obsolete now as the SDK has changed quite a bit. Any suggestions on getting similar data given that the SensorFusion library no longer uses the GetOrientation method? I am attempting to get data from fusion->GetSensorStateAtTime(fusion->GetTime()) but the Magnometer seems to be the only property with useful data... Am I heading in the wrong direction here?