Monoscopic background with render texture ?

Background monoscopic rendering is fairly tricky due to the difference in head pose between the mono pass and the stereo pass. You can see an example in the "Mono Optimization" scene of our Sample Framework at https://developer.oculus.com/downloads/game-engines/1.3.0/Oculus_Sample_Framework_for_Unity_5_Project. We are working on first-class support for this technique inside of Unity, but there isn't a firm ETA yet.

 @vrdaveb thanks for the infos, however i can't find a scene named "Mono Optimization" in the Sample Framework 1.3.0 (nor something related at first glance)

Does the difference in head pose matter is the mono camera is rendered with a near clip plane of 1000 Unity units (standard OVR scale so 1 unit = 1m)?

I tried this and the background looked to be in the right place but I had problems with 'gaps' opening up between the near cam's far plane and render texture billboard around the edges of the screen (but not the middle). I switched to having a near OVRCameraRig and and far OVRCameraRig (the far one only rendering a few layers) but the render texture method should be more efficient?

I had some hopes reading @vrdaveb answer but now it looks like my GearVR project is stuck for good. I can't find up to date infos on this anywhere, and nothing in the Sample Framework after many checks. the desktop and mobile results are differents and unpredictable from one version to another. Any advices are welcomed.

Looks like i found a workaround. My background RT cam mimics the main camera on precull. RT quad is parented to bg cam. According to the device (desktop/mobile) i search and setup the best quad's z-distance from cam. A little hacky but seems to do the trick.

> i can't find a scene named "Mono Optimization" 

Sorry, looks like that one hasn't shipped yet. We are working on first-class support for this, but the internal sample does it a different way, using command buffers to make sure there is no pose drift between the background and foreground cameras. I'll see if we can expedite shipping the feature or the sample. In the meantime, your current approach sounds reasonable.

> I had problems with 'gaps' opening up between the near cam's far plane and render texture

Make sure you use the same head pose for both the foreground and background cameras. The background camera should render from the midpoint between the two eyes. You can copy the background image to the left and right eye buffers before the foreground cameras start rendering. Shift the image to the left or right to account for the eye pose difference. If the background's near-clip plane matches the foreground's far-clip plane and you use the same projection matrix for both, the images should line up almost perfectly. You will only see gaps if the split plane is closer than ~10m, where binocular parallax is more than a pixel or two.

Thanks vrdaveb. The image was correct in the XY plane and my far clip plane for the normal cam was 1000m. I had to overlap the planes slightly to avoid a halo effect on steep triangles (possibly my render texture was too low res).

What it looked like was that the far plane of the normal cam and near plane of the background diverged towards the edge of the view but matched up in the centre. I think it only happened on the Gear, not when testing on the PC (monitor, not Rift). I don't understand how that could happen - I could have had the head pose for the background wrong if that would explain it. I switched to the dual camera rig method a while ago so can't check. Not critical, just wondered if this was a common error with a known change to correct it.

Cheers. Do you have a recommendation on which technique to use for a space game (so sparsely populated scenes) with the far clip plane of the normal camera at 1000m? Presumably the Oculus sample when it's available should be the most efficient?

Your approach sounds good for a space shooter. Performance-wise, your approach should be pretty similar to ours. You may just see a slight wobble in the background image until we share our sample. Your projection issues should be fixable today. Are you setting Camera.projectionMatrix equal on all your cameras?