0.6.0 Extended Mode Window Positioning

I think you shouldn't use EM anymore. It's not even working for me in oculus samples and looks like enums to detect it are removed. Direct mode and mirroring works perfectly, i've migrated yesterday.

I use Direct Mode exclusively, and recommend it to all. That said, quite a few people have some sort of issue (be it driver/hardware incompatibility) which prevents them from using direct mode, so I like to support Extended Mode also. Most users of my software use Direct Mode, but for the few that can only use extended, I like to support them. Especially when the Oculus runtime still has an option for it.

Extended mode is still available, since some GPUs still have trouble with Direct Mode, but it's now invisible to the SDK. You use both modes the same way. Read the 0.6.0 developer guide for more details, but the basics flow is now:

- Ask the Oculus SDK to create some textures for you via ovrHmd_CreateSwapTextureSetGL/D3D11
- Render your scene either directly to the textures as a render target or blit your rendered scene into it.
- Call ovrHmd_SubmitFrame, passing the Oculus-created textures back into it.
- Optionally have the Oculus SDK give you back a "mirror texture" that shows exactly what's being presented to the HMD and render that to your application window however you see fit.

I've read through the developer guide. I've looked through the ovrTinyRoom sample. No mention of actual window positioning, or how the compositor displays the view in extended mode :?:

If I create a mirror texture, how do I decide where to position my window, that I'm drawing a mirror texture to, so that I don't just place it behind the Oculus view on the HMD rather than the user's monitor so that they can see the mirror?

Does the Oculus compositor handle drawing the image to the device in extended mode, rather than requiring a window? The documentation would imply yes, the rendering is the same in both modes. The Oculus Room sample would imply no. If I comment out the mirror texture rendering, everything works fine in direct mode. In extended mode, I now get a black screen. It looks as if it's actually the window with the mirror texture appearing on the Rift rather than the compositor somehow showing the image directly. I'm still doing some testing to confirm this suspicion.

The statement "Changed Extended mode to use the compositor process. Rendering setup is now identical for extended and
direct modes. The application no longer needs to know which mode is being used." is quite inadequate. I'm seeing what looks like a dependency on the mirror texture in extended mode (but not direct), not to mention that any "mirror" window is going to end up on the HMD if the Rift is set as primary display, unless I position it through code, which is tricky without DisplayDeviceName.

If any Oculus developer could comment, I'd really appreciate it. You've done an absolutely amazing job on the new SDK, especially direct mode. I may be making it up, but it feels more locked in, and I really like the new layers/ovrHmd_SubmitFrame APIs, they match my application much better than the older APIs. On the other hand, the behavior I'm seeing from extended mode is not matching the documentation, and I feel like I'm taking crazy pills here.

Hopefully a minor issue as more and more users switch to direct mode over time, but one I'd really like to resolve in my software.

"CrazyNorman" wrote:
Does the Oculus compositor handle drawing the image to the device in extended mode, rather than requiring a window?

Yes. The Oculus runtime creats the actual target window in extended mode, so you no longer need to worry about creating the window or positioning it.

"CrazyNorman" wrote:
not to mention that any "mirror" window is going to end up on the HMD if the Rift is set as primary display, unless I position it through code, which is tricky without DisplayDeviceName.

There's no real reason to set the Rift to be the primary display any more. However, I still think that extended mode display information should be available so that apps that might be trying to evaluate multi-monitor systems know how to avoid placing windows on the Rift display accidentally.