Forum Discussion
Some general dk2 questions...
Hi,
I'm working on a project that involves integrating dk2 into an opengl based 3d engine and have a few questions:
* On DK1, I had to translate the projection matrix to shift the output to the eye centre. However, with DK2 I'm just using the hmd->DefaultEyeFovs to generate 'skewed' projection matrices - is this correct? New docs don't mention having to translate projection matrix, and it seems to work fine as is.
* Head orientation tracking seems to be a bit jerky (have noticed this on all ovrs). The internal tracking update rate is apparently 1000hz so I would have expected tracking to be as smooth as rendering, if a bit laggy. What exactly is up here? Do hardware samples need to be averaged over time or something? Is it a side effect of lag? I'm using ovrHmd_GetTrackingState( _hmd,ovr_GetTimeInSeconds() ) to read head orientation.
* Has anyone got direct rendering to the front buffer going in opengl on the mac. I've tried to set glDrawBuffer to GL_FRONT, but this results in pretty spectacular crashes! If not on Mac, is front buffer rendering possible on windows/linux?
* Is there anyway to obtain the x,y,z offset from the pivot point on the neck to each eye?
And kudos to the oculus team on the work done on the SDK, definitely much improved on last time I used it!
Bye,
Mark
I'm working on a project that involves integrating dk2 into an opengl based 3d engine and have a few questions:
* On DK1, I had to translate the projection matrix to shift the output to the eye centre. However, with DK2 I'm just using the hmd->DefaultEyeFovs to generate 'skewed' projection matrices - is this correct? New docs don't mention having to translate projection matrix, and it seems to work fine as is.
* Head orientation tracking seems to be a bit jerky (have noticed this on all ovrs). The internal tracking update rate is apparently 1000hz so I would have expected tracking to be as smooth as rendering, if a bit laggy. What exactly is up here? Do hardware samples need to be averaged over time or something? Is it a side effect of lag? I'm using ovrHmd_GetTrackingState( _hmd,ovr_GetTimeInSeconds() ) to read head orientation.
* Has anyone got direct rendering to the front buffer going in opengl on the mac. I've tried to set glDrawBuffer to GL_FRONT, but this results in pretty spectacular crashes! If not on Mac, is front buffer rendering possible on windows/linux?
* Is there anyway to obtain the x,y,z offset from the pivot point on the neck to each eye?
And kudos to the oculus team on the work done on the SDK, definitely much improved on last time I used it!
Bye,
Mark
3 Replies
- Well, solved one of my problems...
Juddery head tracking appears to be caused by using extended mode for the rift, and using different refresh rates for the main monitor and the rift.
I was running my main monitor at 60hz and the rift at 75hz - end result, lumpy head tracking. Either changing main monitor to 75hz, or rift to 60hz solved the problem.
The 'tinyroom' sample doesn't appear to suffer from this problem (it seems to always open the rift at 60hz regardless) but plenty of 3rd party apps appear to.
This is something that really needs to be cleaned up! - Regarding the stuttering: When you are using the direct rift mode the stuttering issues should disappear.
However, in OpenGL it is somewhat tricky to get everything up and running with the direct rift mode. You need to initialize the rift before creating the context and you need to make sure that you don´t have any OpenGL Errors occuring. For this you need to consider that the direct rift mode is rendering to an FBO, not to the normal front/back buffer. So calling glDrawBuffer(GL_BACK) will give you an glError and cause the direct rift mode to fail or even crash the application.
However, I am not sure what the current status of the direct rift mode is for Mac. "marksibly" wrote:
* On DK1, I had to translate the projection matrix to shift the output to the eye centre. However, with DK2 I'm just using the hmd->DefaultEyeFovs to generate 'skewed' projection matrices - is this correct? New docs don't mention having to translate projection matrix, and it seems to work fine as is.
Yep, translating the projection matrix isn't needed anymore. That was to skew the frustum, to take into account that each eye sees more to one side than the other (because of the nose divider). But the defaulteyefovs are asymmetric, the left and right angles aren't equal, so they build a skewed projection too (when you give them to ovrMatrix4f_Projection)."marksibly" wrote:
* Is there anyway to obtain the x,y,z offset from the pivot point on the neck to each eye?
You can get it like this:float eyeoffset[2] = { OVR_DEFAULT_NECK_TO_EYE_HORIZONTAL, OVR_DEFAULT_NECK_TO_EYE_VERTICAL };
ovrHmd_GetFloatArray(m_hmd, OVR_KEY_NECK_TO_EYE_DISTANCE, eyeoffset, 2);
float ipd = ovrHmd_GetFloat(m_hmd, OVR_KEY_IPD, OVR_DEFAULT_IPD);
ovrVector3f lefteyepos;
ovrVector3f righteyepos;
righteyepos.x = ipd;
righteyepos.y = eyeoffset[1];
righteyepos.z = eyeoffset[0];
lefteyepos.x = -ipd;
lefteyepos.y = eyeoffset[1];
lefteyepos.z = eyeoffset[0];
lefteyepos and righteyepos should now be positions relative to the neck pivot.
I've never used this myself, but the values look correct.
No idea on the mac bit.
