SDK Monoscopic Mode Flag For The OVR Controller

Left and right images will not be showing the same thing, even in mono mode. This is due to needing custom projection matrices to line the image up with the lenses/eyes. So I don't think sharing a render target would work.

However, I do agree that there should be an easy switch into mono mode exposed in the integration.

"cybereality" wrote:
Left and right images will not be showing the same thing, even in mono mode. This is due to needing custom projection matrices to line the image up with the lenses/eyes. So I don't think sharing a render target would work.

However, I do agree that there should be an easy switch into mono mode exposed in the integration.

Ahh, but of course, I hadn't considered the distortion which requires two separate buffers and copying the data over pre distortion probably couldn't be done fast enough?

Good to hear you agree a flag would be useful. :)

Your "switch" is

IPD * stereo

where stereo is either 1 or 0, i.e. true or false.

"raidho36" wrote:
Your "switch" is

IPD * stereo

where stereo is either 1 or 0, i.e. true or false.

Yeah it's a simple thing to make the IPD 0, what I am asking for is an official addition to the SDK since it is a 'Best Practices' suggestion this should be a standard feature.

While I'm on it I think handling the Stereo/Headphones Audio setting should also be handled by the SDK to change the parent of the Listener.

"cybereality" wrote:
Left and right images will not be showing the same thing, even in mono mode. This is due to needing custom projection matrices to line the image up with the lenses/eyes.

Actually, while this is true, I believe it should be possible to construct a single projection matrix for the entire image, and then crop part of it for the left and right views. How this would impact performance is tricky (at least for me) to estimate. If your bottleneck is tied to the number of pixels rendered, then you should probably see a 30%-50% improvement, because that's roughly the amount of crossover area you're rendering (the portion of the view that's visible to both eyes). If your rendering bottleneck is tied to the number of GL / DirectX calls you're making, then you should see a substantially better improvement, but it would probably also mean you're using the rendering API inefficiently.

Of course I just noticed that this is the Unity 4 forum, so I don't know where the bottlenecks there would lie.

It would be in the amount of draw calls and a some bit of frustum culling CPU processing. In this regard, Unity lacks of flexibility - it would make A LOT of sense to compute frustum culling for a combined frustum and use it with both cameras, rather than compute it individually for both cameras that barely differ anyway.

Yes, just setting regular camera to the right FOV and then rendering the same image to both eyes with specific sampling offset should do the trick just fine.

@jherico: Yes, what you say would work, but unfortunately there are limits to how much you can customize the Unity render pipeline without having the source code. Even just using a render target that is a different size (ie bigger) than the display resolution is problematic. Though with lower-level APIs it could be a possibility.