does this mean that if a game doesn't support different camera angling the headset will need to reproject anyway, but the index will do that with dedicated hardware as opposed to software emulation, thus mitigating the performance hit?
I do not know, but my
guess is that It is just similar software reprojection to what Pimax does, and that this is the default mode, which is automagically used whenever Steam in one manner or other (I could think of a few) determines the application that is being started has no support for canted screens (here's hoping for a user setting, just in case, btw),
but…
First of all: It is not the reprojection that constitutes the performance hit, but that the game renders a larger bitmap with more anisotropy, for the parallel viewplane, and that problem does not go away.
...but the overhead is likely to be less significant for a few reasons:
- The lens/screen cant is half of that of the Pimax headsets, so there is less "distance" to reproject over.
- The FOV is smaller than that of the Pimaxes, which leads to the same.
- The hidden area mask is probably properly projected to the parallel intermediate viewplane, unlike with Pimax's current runtime (...which appears to use its regular one), which should lead to further savings, provided the game actually makes use of it.
I whipped up an example (
NB: no real data used - I pulled it all out of a dark place, and have also since forgotten the exact numbers I used) diagram for a hypothetical 8:9 viewplane, with a 60°+50°*110° frustum, and a later added circular hidden area mask...
So the rectangle outlined in blue would be the screen, which it would have been optimal to render directly for.
...and the red one is the parallel viewplane that you would being rendering instead, given a few assumptions: -We want to maintain angular resolution, so we need to match the right edges, where the two planes "hinge together", with the same amount of pixels per degree, and -We want the full vertical FOV all the way out in the far periphery, so the parallel screen buffer needs to be both wider and taller, so that its corners of the left align with those of the "real screen" buffer, when projected to the observer.
Then you take the hidden area mask into consideration, and see that you hadn't needed to go all the way out to the corners, when determining the size of the parallel projections viewplane bitmap; Its top and bottom edges could be brought together, to the point where the hidden area mask intersects the line that delineates the projection (the line from the top left corner of the red rectangle to the top right one on the blue - the left one of the two intersections)
So, basically compare the area of the circle on the blue rectangle with the area of the circle on the red rectangle, to estimate the pixel shading overhead in this speculative example - doesn't look all
that bad to me... :7
