Forum Discussion
Upside down image - details inside
I experimented with the near/far camera setup that others have mentioned in other threads.
I thought I would point out a potential issue, although it's entirely possible I was doing something wrong.
I have one OVRCameraController set up to render large scale scenery (with camera depths 0 and 1), and a second OVRCameraController set up to render very-nearby scenery (with camera depths 2 and 3, depth clear only). The large scale scenery has Lens Correction and Chromatic Aberration Correction turned off. The camera controllers have their orientation linked (thanks rje for the static orientation idea).
The output of the large scale scenery cameras looked fine, but then the final output after the nearby cameras were rendered, everything was flipped upside down.
I looked into the OVR Unity integration code, and found this:
I also saw that under certain conditions (relating to Windows, MSAA, deferred lighting), the Blit() method takes care of flipping (or not flipping) the image by drawing a quad with texture coords as appropriate.
With some level of MSAA on (via Quality Settings), there is no problem.
When MSAA is disabled, the image from the second set of OVRCameras are upside down.
I was able to fix it by changing the above code to this:
I assume Graphics.Blit was the original approach and this was replaced by doing flipping with a shader via Blit(). However, this fix seems to increase my frame rate slightly (from 270 to 300 in this case). I'm curious if my fix above is taking a step backward in some other way that I'm not aware of? Does Graphics.Blit do the wrong thing in certain conditions relating to Windows/MSAA/deferred lighting? Am I applying the wrong band-aid?
Any feedback is appreciated, but entirely optional. :)
I thought I would point out a potential issue, although it's entirely possible I was doing something wrong.
I have one OVRCameraController set up to render large scale scenery (with camera depths 0 and 1), and a second OVRCameraController set up to render very-nearby scenery (with camera depths 2 and 3, depth clear only). The large scale scenery has Lens Correction and Chromatic Aberration Correction turned off. The camera controllers have their orientation linked (thanks rje for the static orientation idea).
The output of the large scale scenery cameras looked fine, but then the final output after the nearby cameras were rendered, everything was flipped upside down.
I looked into the OVR Unity integration code, and found this:
Blit(SourceTexture, destination, material, flipImage);
//Graphics.Blit(SourceTexture, destination, material);
I also saw that under certain conditions (relating to Windows, MSAA, deferred lighting), the Blit() method takes care of flipping (or not flipping) the image by drawing a quad with texture coords as appropriate.
With some level of MSAA on (via Quality Settings), there is no problem.
When MSAA is disabled, the image from the second set of OVRCameras are upside down.
I was able to fix it by changing the above code to this:
//Blit(SourceTexture, destination, material, flipImage);
if(material != null)
Graphics.Blit(SourceTexture, destination, material);
else
Graphics.Blit(SourceTexture, destination);
I assume Graphics.Blit was the original approach and this was replaced by doing flipping with a shader via Blit(). However, this fix seems to increase my frame rate slightly (from 270 to 300 in this case). I'm curious if my fix above is taking a step backward in some other way that I'm not aware of? Does Graphics.Blit do the wrong thing in certain conditions relating to Windows/MSAA/deferred lighting? Am I applying the wrong band-aid?
Any feedback is appreciated, but entirely optional. :)
1 Reply
Replies have been turned off for this discussion
- The upside-down image is a strange Unity quirk due to the different ways coordinates are stored in OpenGL vs DirectX in regards to render-textures. Setting MSAA on will effect this, in which case our integration will try to flip the image to make it normal again. However if you have multiple cameras this trick won't work anymore.
Whatever the case, this is all very hackish at the moment. There are two things that could happen. One: (hopefully) Unity will correct the problem at the source, so everything works like you would expect. Or, we find a better work-around that has better compatibility and is less hackish.
