Screen coverage - why isn't it maximized?

Beautiful blog post, jherico! I learned a lot. :thumbup:

Of course I wrote it before I discovered a bug in the SDK that refuses to respect the distortion fit point below a certain point.

fov is also a function of eye-relief (distance between your eye and the lens). A given rendered fov assumes an eye distance from which you will not be able to see the surrounding black pixels. Now this is trickier than it first seems because your natural intuition is to think that your left fov is bounded by the amount that your eye is able to look left. But in fact it's exactly opposite. The geometry of an eye rotation means that light from further left will actually enter your eye as you rotate your eye towards the right. So your maximum left fov in the Rift is bounded by what is visible when looking right. But these are often extreme cases and you can often get away with only accounting for visible screen area while looking directly ahead. The point is that making tradeoffs in fov for performance doesn't always degrade the experience in the way you might assume. Not everyone will sense the same (or any) amount of black edge and they may only be able to sense it a small percentage of the time. Recall that Valve suggests to TF2 players that they adjust their eye-relief dials all the way out. At this setting, the reduced TF2 fov is almost entirely a non-issue.

"brantlew" wrote:
Recall that Valve suggests to TF2 players that they adjust their eye-relief dials all the way out. At this setting, the reduced TF2 fov is almost entirely a non-issue.

Isn't this the same as saying: "they already recommend you play in a broken fashion, so they render in such a way that it doesn't whether you take their advice or not"?

Since the lens light is collimated, adjusting the eye relief only alters the FOV, not the relationship between perceived FOV and physical FOV, right?

I believe I've seen a screenshot of a demo or a game with full 100% coverage of 1280x800 Rift's screen including corners. Can't find it now. Curious how that application renders the image.

Instead of doing barrel distortion in post processing. Could the the GPU rasterize diamond shaped camera views, multiple diamond shaped camera views when stitched together on a standard rectilinear screen should have the required fish eye distortion using all the screens native resolution and not having to resort to scaling and super sampling.

"mrmonkeybat" wrote:
Instead of doing barrel distortion in post processing. Could the the GPU rasterize diamond shaped camera views, multiple diamond shaped camera views when stitched together on a standard rectilinear screen should have the required fish eye distortion using all the screens native resolution and not having to resort to scaling and super sampling.

What you're suggesting is sort of the really long-way-around of accomplishing mesh-based distortion. You'd likely lose tons of performance because of the number of times you'd be rerendering the scene, even though each render would be for a tiny portion of the overall scene.

However, it does suggest a possible alternative approach. You could render the entire scene to a framebuffer of a given (low) resolution and paint that image into the backbuffer. You could then re-render a much smaller section of the scene (the area near the lens axis) to the same framebuffer, and paint it to the backbuffer in the appropriate area, using a subset of the mesh used for the larger scene.

Whether this approach would improve performance largely depends on what your limiting factor is. If you're fill rate limited (perhaps because of very complex per-pixel lighting or other effects) then it might improve performance, because you may end up rendering a smaller number of pixels overall, as long as the frame buffer you use is less than half the size of the framebuffer you'd need to use to render the whole scene. If you're rendering to the 'whole screen', I believe the framebuffer required is 1.7x the target surface in each dimension or ~2.9x the number of pixels.

If you're vertex rate limited, then this isn't going to help at all, because you're doubling the amount of vertex processing by rendering the scene twice as often.

The best approach is probably just to use shader based texture-lookup distortion until and unless you find a performance problem you need to solve.