(Sorry, reposting this from Community Support; didn't spot this forum before I posted)
A few months ago I borrowed a Rift and played Half Life 2 on it. Yesterday I got the chance to borrow one again.
Unfortunately, this time around, HL2 decided I must be standing on my head. The HUD and menus were the right way up, but the world was upside-down.
So I tried the Oculus World Demo from the 0.2.5c SDK. Again: menus correct, world upside down.
So I tried the calibration utility and the settings visualiser. UI correct, world upside down.
So I downloaded an executable of SensorBoxTest.exe, and that seemed to work fine. I ran the Oculus World Demo again, and THAT ran fine - but then I noticed I'd accidentally run the one from the 0.2.4b SDK. I checked back and forth and sure enough: the 0.2.4b SDK version is perfect, the 0,2.5c version is upside down.
More specifically than just 'upside down', this is what happens:
When I run the demo (or config utility, or HL2), the HUD and menus are fine but the world is inverted. If I turn the headset over 180 degrees while looking through the optics, the world stays put (ie, it still looks upside down to me) This is perfectly normal Rift behaviour apart from the fact that the world is upside down. After a second or two of holding the device upside down, the world will start to smoothly rotate (very much as though it's using the accelerometer to correct for drift) so that the world (through the upside down rift) looks the right way up.
I've tried this with the rift at various angles, and every time the drift correction kicks in, the world rotates AS THOUGH the rift were exactly upside down. It's as though the accelerometer is stuck reading gravity as (0,1,0).
So, to recap:
The 0.2.4b OculusWorldDemo and 0.2.4b Config Utility 'Interactive Utility' work perfectly (with latest firmware)
The 0.2.5c OculusWorldDemo, Config Utiliy 'interactive utility', Half Life 2 / HL2:EP1, Minecrift etc *ALL* render the world upside down (or as though the accelerometer is jammed reading (0,1,0))
I think it might be a hardware problem. I've compared the code in OVR_SensorFusion.cpp from 0.2.4b with 0.2.5c, and found that the method for determining 'down' and eliminating acceleration spikes has changed. Just inspecting the code, I can see how certain kinds of hardware fault would fool the newer code but not the older one (the old code threw away any values that weren't close to gravitational, whereas the new one always accepts the first value whatever it may be). This tallies with the fact that, running around the 'old' OculusWorldDemo, there's appreciable drift of the 'down' axis over time, very much as though it's never able to get any meaningful data from the accelerometer.
I'll give that one a try later. The fact that 0.2.4b oculusworld "works" (albeit with very bad drift), while the 0.2.5c build of the same thing puts the world upside down, coupled with the difference I can see in the code makes me reasonably confident I've diagnosed the problem.
I'm taking the kit somewhere today where I can try it on a mac; I'll see what happens there.
I just have to say that I was really disappointed on reading this post because I saw the title and I thought it was a complaint about a new SDK release that I'd somehow managed to miss.
Yeah, in general you should not use the term "latest SDK" as that will constantly be changing. It's much more helpful to say 0.2.5c or whatever the number actually is. Thanks.