I already read articles about the pannini projection, which is quite cool, but I guess occulus is facing the same issues and has similar solutions...
I already read articles about the pannini projection, which is quite cool, but I guess occulus is facing the same issues and has similar solutions...
You can render a single quad and calculate UV in the pixel shader. Geometrically, this is the most accurate method.
You can do without any shaders, write a CPU code that builds a reasonably dense (about 8x8 pixels/triangle) static geosphere mesh with position and texcoord channels.
You can also build a reasonably dense grid mesh occupying just the screen with just the positions in clip space, and calculate UV channel in the VS based on the rotation.
GS will work too but I’m not sure it makes sense performance-wise. People normally use GS-es to implement small dynamic objects. For static geometry I won’t be surprised an immutable buffer will be faster, just because that’s what hardware & drivers are optimized for. See e.g. this http://www.joshbarczak.com/blog/?p=667
1. Cubemap (source) - 360° videos are often sourced from six different images stitched together.
2. Equirect (video) - the cubemap is transformed to "equirect" trivially with a fragment shader—which maps every output pixel to some input pixel.
3. Perspective (output) - Mapping equirect video to a perspective projection is also done with a fragment shader, just using a different transformation depending on the focal point of the user.
4. Pannini (alternative output) - You mentioned this projection, and it's an alternative to the "perspective" projection that allows a wider output FOV that minimizes distortion in the periphery.
I researched this a bit here: https://github.com/shaunlebron/blinky
Mandatory XKCD: [1]