Skip to main content
TeraBit
Up and Coming
May 11, 2014

Strange effect using Sdk 0.3.1

Hi All,

I've been writing some code interfacing a .NET application with the new Rift 0.3.1 code. But it's producing some strange effects.

I'm using the SDK rendering (a texture per eye) and although I get something showing up when I render, the are pushed out to the side. The cube is rendered dead centre of the texture but comes out like the picture below.

edit

Just to say that this is using OpenGL with OpenTK driving the GL on the .NET side.

The Setup follows the examples as far as I can see.
		
                eyes[0].Eye = ovrEye_Left;
		eyes[1].Eye = ovrEye_Right;
		eyes[0].Fov = hmdDesc.DefaultEyeFov[0];
		eyes[1].Fov = hmdDesc.DefaultEyeFov[1];
		eyes[0].TextureSize = renderTargetSize;
		eyes[1].TextureSize = renderTargetSize;
		eyes[0].RenderViewport.Pos = Vector2i(0,0);
		eyes[0].RenderViewport.Size = Sizei(renderTargetSize.w, renderTargetSize.h);
		eyes[1].RenderViewport.Pos = Vector2i(0,0);
		eyes[1].RenderViewport.Size = Sizei(renderTargetSize.w , renderTargetSize.h);

		eyeRenderDesc[0] = ovrHmd_GetRenderDesc(hmd, eyes[0]);
		eyeRenderDesc[1] = ovrHmd_GetRenderDesc(hmd, eyes[1]);

	    Cfg.OGL.Header.API = ovrRenderAPI_OpenGL;
	    Cfg.OGL.Header.Multisample = 0;
	    Cfg.OGL.Header.RTSize.w = hmdDesc.Resolution.w; 
	    Cfg.OGL.Header.RTSize.h = hmdDesc.Resolution.h;
	    Cfg.OGL.WglContext = wglGetCurrentContext();
	    Cfg.OGL.Window = HWND(hwnd);
	    Cfg.OGL.GdiDc = wglGetCurrentDC();

	    int l_RenderCaps = 0;
	    int l_DistortionCaps = ovrDistortion_Chromatic | ovrDistortion_TimeWarp;

		ovrHmd_ConfigureRendering(hmd, &Cfg.Config, l_RenderCaps, l_DistortionCaps, eyes, eyeRenderDesc);

	    EyeTexture[0].OGL.Header.API = ovrRenderAPI_OpenGL;
	    EyeTexture[0].OGL.Header.TextureSize.w = renderTargetSize.w;
	    EyeTexture[0].OGL.Header.TextureSize.h = renderTargetSize.h;
	    EyeTexture[0].OGL.Header.RenderViewport = eyes[0].RenderViewport;
	    EyeTexture[0].OGL.TexId = tid1;

	    EyeTexture[1].OGL.Header.API = ovrRenderAPI_OpenGL;
	    EyeTexture[1].OGL.Header.TextureSize.w = renderTargetSize.w;
	    EyeTexture[1].OGL.Header.TextureSize.h = renderTargetSize.h;
	    EyeTexture[1].OGL.Header.RenderViewport = eyes[1].RenderViewport;
	    EyeTexture[1].OGL.TexId = tid2;




NOTE:
Also using the SDK rendering seems to screw up OpenGL state something awful. My VBOs are stomped on and I need to re-upload the data each frame. :(

Any ideas?

    24 replies

    Show previous replies
    jherico
    Inspiring
    July 10, 2014
    "mikeant" wrote:
    The problem with pre-TimeWarp spin logic is that it absolutely must resume in time to do timewarp rendering followed by Present. If we miss by just 1 or 2 ms, it may result in in skipped VSync and frame judder -- that is very obvious and very bad, especially with low persistence.


    Given that the reasoning for the pause is to enable you to fetch the most accurate sensor readings immediately before the render, I have to wonder why instead of spinning, you don't at least poll on ovrHmd_GetEyeTimewarpMatrices() until the time is correct.

    Even better would be a mechanism that adds an additional parameter to ovrHmd_GetEyeTimewarpMatrices() specifying the exact timing of the matrices you want. The function could provide that time to the service along with an HEVENT type on which the function will wait. The background message handling thread or service could examine the time after each new packet and determine whether waiting for the next packet would push it over the line, in which case it populates the outbound matrices and signals the event. The calling rendering thread would then immediately resume and be able to continue with the rest of the distortion operation with no further thread synchronization required.

    Failing that, you could use a combination of Sleep and QueryPerformanceCounter (which should be accessing the HPET hardware on the host) to at least eliminate the bulk of the spinlock. This approach is described here.
    Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action
    mikeant
    Participant
    July 11, 2014
    Thank you guys for the suggestions and feedback. We'll experiment with WaitableTimer, which sounds like a good option and other alternatives; can't promise for certain it will make into the upcoming release, but we'll see and try to address this soon.
    jherico
    Inspiring
    July 11, 2014
    "mikeant" wrote:
    Thank you guys for the suggestions and feedback. We'll experiment with WaitableTimer, which sounds like a good option and other alternatives; can't promise for certain it will make into the upcoming release, but we'll see and try to address this soon.


    Actually the NVidia wgl_delay_before_swap extension mentioned in another thread looks like it was designed specifically with this use case in mind. Granted it's currently nVidia only, but I suspect that if it improves the quality of the VR experience it would be adopted pretty quickly by other vendors.
    Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action
    Fredz
    Up and Coming
    July 12, 2014
    "mikeant" wrote:
    Perhaps we can do something with GPU interrupts, etc, but that is all advanced and non-standard - this is an area we plan to research.

    The SoftGenLock/Genlock applications used this technique a decade ago to support shutter glasses for stereoscopic 3D or multi-display synchronization for CAVE setups on Linux. I modified the code some years ago for more recent kernels and NVIDIA GPUs (7XXX/8XXX) : http://www.mtbs3d.com/phpbb/viewtopic.php?f=6&t=10625
    I did adapt the code again for more recent kernels (3.6.11) and newer NVIDIA GPUs (GTX 460) some months ago and it did compile and launch, but since it's no longer possible to do hardware page flipping with recent NVIDIA GPU I don't know if the IRQ interception is still working correctly.

    I don't know if other GPUs can be supported either, but it could be interesting to investigate. I guess a similar technique could be used on Windows or OS X.

    "jherico" wrote:
    Actually the NVidia wgl_delay_before_swap extension mentioned in another thread looks like it was designed specifically with this use case in mind.

    John Carmack and Cass Everitt are listed as contributors of this extension so I guess they should be aware of this.
    Terms & ConditionsAccessibility statement