SDK 0.3 preview?

I just ran into this (predicted values being chaotic while recorded values are fine) porting my Ogre Oculus wrapper to the new sdk.
It seems the problem is ovrHmd_GetSensorState(hmd, 0.0) (which is what the sdk docs show).
The value of 0.0 doesn't seem to give the pose for the current time as documented.
Instead it works correctly if you use: ovrHmd_GetSensorState(hmd, ovr_GetTimeInSeconds())
I haven't looked into the source to see what's going on or if I left some initialisation step out.

"kojack" wrote:
I just ran into this (predicted values being chaotic while recorded values are fine) porting my Ogre Oculus wrapper to the new sdk.
It seems the problem is ovrHmd_GetSensorState(hmd, 0.0) (which is what the sdk docs show).
The value of 0.0 doesn't seem to give the pose for the current time as documented.
Instead it works correctly if you use: ovrHmd_GetSensorState(hmd, ovr_GetTimeInSeconds())
I haven't looked into the source to see what's going on or if I left some initialisation step out.

Yeah I noticed that when running my 'tracker test' example, which renders an outer transparent sphere with the current reading, and an inner solid sphere with the prediction reading. If I pass 0.0 into the method, the inner sphere starts off peaceful and then begins to spasmodically twitch around with increasing fury as the small noise values in the acceleration and angular velocity get increasingly amplified.

"kojack" wrote:
It seems the problem is ovrHmd_GetSensorState(hmd, 0.0) (which is what the sdk docs show).
The value of 0.0 doesn't seem to give the pose for the current time as documented.
Instead it works correctly if you use: ovrHmd_GetSensorState(hmd, ovr_GetTimeInSeconds())
I haven't looked into the source to see what's going on or if I left some initialisation step out.

In the OculusRoomTiny example, they use ScanoutMidpointSeconds from the ovrFrameTiming returned by ovrHmd_BeginFrame() (or ovrHmd_BeginFrameTiming() if not using SDK rendering).

From the Oculus docs:

To facilitate prediction, ovrHmd_GetSensorState takes absolute time, in seconds, as a second argument. This is the same value as reported by the ovr_GetTimeInSeconds global function. In the example above, we specified a special
value of 0.0 that is used to request the current time.

I just checked the code, ovr_GetTimeInSeconds doesn't check for special values of time. It gets passed to SensorFusion::GetSensorStateAtTime(double absoluteTime) which does:

const double        pdt   = absoluteTime - lstate.State.TimeInSeconds;

So a value of 0.0 results in a negative delta time (increasing in magnitude over time). Not healthy for prediction.

"kojack" wrote:
From the Oculus docs:

To facilitate prediction, ovrHmd_GetSensorState takes absolute time, in seconds, as a second argument. This is the same value as reported by the ovr_GetTimeInSeconds global function. In the example above, we specified a special
value of 0.0 that is used to request the current time.

I just checked the code, ovr_GetTimeInSeconds doesn't check for special values of time. It gets passed to SensorFusion::GetSensorStateAtTime(double absoluteTime) which does:

const double        pdt   = absoluteTime - lstate.State.TimeInSeconds;

So a value of 0.0 results in a negative delta time (increasing in magnitude over time). Not healthy for prediction.

Based on the sensor state structure returned, I suspect that they originally wrote that against a version of ovrSensorState that only returned a single pose. The current version returns both the instantaneous pose, as well as a predicted pose. So to use the predicted you have to pass in the absolute time, but to use the 'actual' pose, it doesn't matter what you pass in.