SDK 0.4.0, DK1, direct to HMD and ovrHmd_AttachToWindow

For what it's worth, I went ahead and rebuilt the Oculus libraries and samples against the Windows 8.1 SDK (read: latest windows and DirectX headers, libs, NOT the legacy June 2010 DirectX SDK), and apart from a couple of simple required compile fixes there was no ill effect on the samples (they all still run fine), but it also had no effect on my problem. I've also run my renderer single-threaded (meaning all Oculus SDK calls are happening in the same thread) and I've still had no success. The problem persists in both release and debug, in both my 64-bit and 32-bit builds.

I've scrutinized the window setup and DX initialization in the samples, and have tried tweaking my own to match exactly but this also had no effect.

I have seen on a few occasions the "every other scanline" view of the debugger in the HMD, as well as a static snapshot of my game render (but in the "scanlined" view) once.

Has anyone else experienced this sort of issue with direct HMD access client distortion rendering (Windows/DirectX)?

Can't get ovrHmd_AttachToWindow working here either, DK2.

For reference, I am attempting to attach an already running OpenGL 1.5 game. I find it quite important that users should be able to go in and out of VR without having to relaunch the game. For that matter, why is there no ovrHmd_DetachFromWindow?

Switching in and out of Rift in Extended mode is working perfectly without issues.

I'm having the same issue. The Oculus itself is black or sometimes corrupted, while the correct distorted scene is rendered to my window. This is with my custom engine which uses DirectX9Ex. Both samples function correctly.

Some other potentially relevant info:
Using SDK rendering.
DK1
Windows 7 Professional 64-bit
Visual Studio 2010
Geforce GTX 650

I've tried comparing my initialization/rendering with the samples, but it's been difficult to make them match exactly due to DX9 vs DX11.

One thing that is different than the samples is that I have a toggle which goes back and forth between normal rendering in the window (which is starts as default) and rendering to the Oculus. I've implemented it by only calling ovr_Initialize() during initialization so that I can detect if an Oculus HMD is present, and then when I want to enable it, I call ovrHmd_Create(0) and move on from there. To disable, I call ovrHmd_Destroy().

Additionally, right after enabling, I do a device reset with new D3D9 params to match the correct resolution for the SDK.

It does appear that we're all trying roughly the same thing, which is to initialize our HMD (ovrHmd_Create) on-demand instead of at startup. One thing that comes to mind is that in my render loop there is some other render post-processing that happens between my non-distorted eye renders and the final mesh distortion render (which means some render target switches, etc.). Additionally, enabling multisampling causes some other rendering state changes, but that seems to not affect the situation either enabled or disabled. It's hard to say how that might affect things without knowing what the underlying mechanics of the direct-to-HMD mode.

Also worth noting is that all of the tracking seems to be working, returning reasonable values.

For clarity's sake, here's my flow through the SDK calls:

On application initialize:

OVR::System::Init(), with my own allocator + logging. (NOTE: If you do this, you have to call OVR::System::Destroy() manually as well. I have tried disabling doing this with no effect.)
ovr_Initialize()
ovrHmd_Detect()
For every device: (I have also tried removing this, no effect)
ovrHmd_Create()
display some info
ovrHmd_Destroy()

When "starting" an HMD:
ovrHmd_Create()
ovrHmd_AttachToWindow()
For each eye:
ovrHmd_CreateDistortionMesh()
create my actual rendering meshes
ovrHmd_DestroyDistortionMesh()
ovrHmd_GetRenderDesc()
ovrHmd_GetRenderScaleAndOffset()

ovrHmd_SetEnabledCaps() (have tried removing this, no effect)
ovrHmd_ConfigureTracking()

I call ovrHmd_GetTrackingState() in my main game loop for the purposes of user input processing. I've tried removing this, no effect.

In my render loop:
ovrHmd_BeginFrameTiming(), just before rendering the non-distorted eye views
ovr_WaitTillTime() after the eye renders. Have tried removing this, no effect
for each eye:
ovrHmd_GetEyePose()
ovrHmd_GetTimewarpMatrices()
render the non-distorted eye views

for each eye:
render the distortion mesh

call present on the swap chain (tried both with and without vsync, no effect)
Have tried inserting a wait for GPU idle via a query afterwards (which you usually only do in extended mode), but that had no effect.
ovrHmd_EndFrameTiming()

"sbdykes" wrote:
It does appear that we're all trying roughly the same thing, which is to initialize our HMD (ovrHmd_Create) on-demand instead of at startup.

I'm starting to believe the same thing as well. I wish the docs or someone from Oculus could let us know the proper way to do this.

Some pitfalls I found for the direct mode:

• ovr_initialize need to be called before Direct3DCreate9/CreateDXGIFactory.


• The backbuffer size must be exactly 1920×1080 (or 1280×800 for the DK1).


• Direct3D9 only: ovrD3D9Config::D3D9::pSwapChain should be null.


• You'll probably need to do a reset of the device if ovrHmd_Create is called after the first present. (at least for direct3D9, I don't know how that works for direct3D11).

If you want to debug, look in the file: OVR_Win32_ShimFunctions.cpp.
The functions OVRRiftForContext and OVRExpectedResolution should be called after ovrHmd_Create. Check that they are called and that the returned values are correct.

"HunLyxxod" wrote:

ovr_initialize need to be called before Direct3DCreate9/CreateDXGIFactory.

Thank you! This was the problem. I was calling Direct3DCreate9 before calling ovr_initialize.

As a followup, though making that change did fix the problem of the DK1 not displaying anything, I now have two new problems:

1) After calling ovrHmd_Destroy() to leave Oculus mode, calls to both device->Present() and device->Reset() hang forever inside of the function ZwUserShowWindow().

2) My depth buffer doesn't appear to be working at all after calling ovrHmd_Create(). I'm using MAKEFOURCC('I','N','T','Z') as the format so that I can read the depth for deferred rendering.

I'll continue to look into these problems and will update if I find any solutions. Has anyone else encountered this?

I can confirm that moving my ovr initialize to before my renderer initialize fixed the display issue. Many thanks for the info!

I have seen freezing on terminating my application with the HMD still enabled, apparently hung up on releasing the swap chain. I'm pretty sure this is another order-of-operations issue, as when I manually/explicitly "turn off" the HMD before closing my app it terminates normally. I'll dig into that and let you know what I find.

It would appear that the swap chain is a bit fragile in direct mode. Even before enabling the HMD (via ovrHmd_Create), if I do anything that affects the swap chain after initialization "bad stuff" happens. Switching to fullscreen results in glitching artifacts. Enabling multisampling results in a completely blank screen.

If the HMD is enabled/active, any swap chain changes usually result in a hang when releasing the swap chain (including at shutdown). This shutdown problem appears to be something of a timing issue...as I previously stated if I manually destroy the HMD and then terminate the app it's fine. But if I terminate with it active, even though the sequence of calls is the same (HMD destroy, ovr system shutdown, renderer shutdown), it hangs on the swap chain release.

I've reported this in the "reporting issues" forum:

https://developer.oculusvr.com/forums/viewtopic.php?f=34&t=12133