SDK 0.3 preview?

For this release the SDK is still compiled as a static library. Down the road, that may change.

In terms of drivers, this may be necessary for certain features (i.e. for the camera).

Looks like its out!

Can you guys compile the LibOVR?

I get this

1>d:\documents\ovr_sdk_win_0.3.1\oculussdk\libovr\src\capi\d3d1x\CAPI_D3D1X_DistortionRenderer.cpp(33): fatal error C1083: Cannot open include file: '../Shaders/Distortion_vs.h': No such file or directory

I basically added

D:\Documents\ovr_sdk_win_0.3.1\OculusSDK\LibOVR\Src\CAPI\Shaders

wherever I could add it.. but still nothing..

Visual Studio C++ 2010 Express

Hi,

I put my compile-issues in a seperate thread.

Kind Regards
Patrick

So predictably not only is SDK 0.3.1 pre statically linked but they are releasing it for windows only. No sign of Linux support. No mention of plans to either. :( :evil:

Is this the start of the rot facing the FB buyout?

Hi,

I think their main focus is right now on the windows platform, because things are running much smoother there compared to Linux. I tried both and the rendering on the windows machine seems to be much smoother. I haven't tried it yet with the latest 14.04 Ubuntu (only 12.04 LTS), but during the next days I will.

And as they stated, it's just a PRE-view. That propably means, a normal release is supposed to support all platforms.

Kind Regards
Patrick

Well, read the eMail right:

Mac and Linux support has also been omitted from this release only.

So no worries. Nevertheless, I can't wait to get my hands on the Mac version, C API is much nicer to wrap than the C++ version. Any date on that maybe?

EDIT: Update: I've fixed the problem by turning off prediction. Prediction doesn't seem to work at all if you aren't using the rendering functions, and there are apparently no sanity checks in their algorithms to stop it predicting on garbage data.

I moved Doom 3 BFG to SDK 0.3.1 and the tracking (the only thing I am currently using, besides detection) has gone completely haywire and totally random. Here's the code:

#include "OVR_CAPI.h"
#include "Kernel/OVR_Math.h"
using namespace OVR;

...

	// *** Oculus Sensor Initialization
	ovr_Initialize();

    // Create DeviceManager and first available HMDDevice from it.
    // Sensor object is created from the HMD, to ensure that it is on the
    // correct device.

    //pManager = *DeviceManager::Create();

	// We'll handle it's messages in this case.
	//pManager->SetMessageHandler(this);

    // Release Sensor/HMD in case this is a retry.
    //pSensor.Clear();
    //pHMD.Clear();
	hmd = ovrHmd_Create(0);
    if (hmd)
    {
        // Get more details about the HMD
		ovrHmd_GetDesc(hmd, &hmdDesc);

		if (ovrHmd_StartSensor(hmd, ovrHmdCap_Orientation | ovrHmdCap_YawCorrection | ovrHmdCap_Position | ovrHmdCap_LowPersistence, 0)) {
			hasOculusRift = true;
			hasHMD = true;
		}
    }
    else
    {            
        common->Warning("Oculus Rift not detected.\n");
		LoadVR920();
	}

...

		if (hasOculusRift && hmd) {
            //float predictionDelta = in_sensorPrediction.GetFloat() * (1.0f / 1000.0f);
			// Query the HMD for the sensor state at a given time. "0.0" means "most recent time".
			ovrSensorState ss = ovrHmd_GetSensorState(hmd, 0.0);
			if (ss.StatusFlags & (ovrStatus_OrientationTracked | ovrStatus_PositionTracked))
			{
				Posef pose = ss.Predicted.Pose;
				float y = 0.0f, p = 0.0f, r = 0.0f;
				pose.Orientation.GetEulerAngles<Axis_Y, Axis_X, Axis_Z>(&y, &p, &r);
				roll =   -RADIANS_TO_DEGREES(r); // ???
				pitch =  -RADIANS_TO_DEGREES(p); // should be degrees down
				yaw =     RADIANS_TO_DEGREES(y); // should be degrees left
			}
		}

It's basically the same as the previous code, only using SDK 0.3.1.

Is that because I'm not calling any of the timing functions in the rendering loop?

OK, who left a breakpoint inside ovrHmd_BeginFrameTiming?
I guess I won't be running this in Debug mode. :(

EDIT: Adding ovrHmd_BeginFrameTiming and ovrHmd_EndFrameTiming around the sensor reading didn't work. It's still acting like a random number generator.

EDIT: Update: I've fixed the problem by turning off prediction. Prediction doesn't seem to work at all if you aren't using the rendering functions, and there are apparently no sanity checks in their algorithms to stop it predicting on garbage data.

Temporarily change ss.Predicted.Pose to ss.Recorded.Pose if you are having this problem. But try to eventually implement rendering the proper way, because turning off prediction and rendering incorrectly (like I'm currently doing) is very bad.

I've opened a separate thread for some issues I have encountered: viewtopic.php?f=20&t=8023

2EyeGuy: I've seen the same erratic prediction behaviour when I disabled the call to ovrHmd_endFrame() for debugging purposes. It's pretty wild (this forum needs a barf smiley ;) ).