Faster fisheye lens effect

[mankrip]

From what I know, everyone seems to post-process this by rendering the scene 5 or 6 times on different faces of a cube, and then render the resulting cube through a fisheye lens algorithm on the screen.

However, if the framebuffer was expanded to the corresponding dimensions of the area of a FOV expanded from an area with a 90° FOV, it would be possible to apply a fisheye lens effect through compressing the expanded framebuffer to the dimensions of the 90° FOV area. This way, the scene would only have to be rendered once, and the fisheye lens algorithm could probably also replace the screen compression algorithm used in the underwater screen warp effect, making the resulting effect much, much faster.
It would also be possible to do a lower-quality faster approach by kind of inverting the area calculations; calculating the smaller area that corresponds to the limits of a 90° FOV inside a bigger FOV with the regular dimensions of the framebuffer, and applying a fisheye lens algorithm that would expand the smaller area up to the dimensions of the framebuffer.

The only limitation of an approach like this is that the effect would be limited to FOV values below 180°.

[edit] Hmm, actually, judging from the 90° and 170° flat FOV screenshots from the Fisheye Quake website, a fisheye lens effect through the way I've suggested would need an expanded framebuffer with about 1100% of the size of the regular framebuffer. Such an expanded resolution would be much slower to render than a cubemap.

[Spike]

a 360 view can be done with dual paraboloid mapping.
http://www.klayge.org/material/3_12/DPS ... Shader.pdf

with this approach, triangle edges are logicailly non-linear. for this to look anywhere decent in quake, you'll need to chop up the world geometry fairly significantly, probably no surface larger than 32qu (maybe 16 if you want decent quality).

this technique is sometimes used for shadowmapping too.

tbh, you're probably better off rotating which alternative view to update each frame.

[mankrip]

Well, another way to speed up fisheye lens below 180° would be to try to reduce the number of faces of the cubemap.

If one of the corners of the cubemap is placed exactly at the center of the screen, the number of faces can be reduced to 3. Furthermore, if the shape of the framebuffer for each face could be changed from a rectangle to a triangle by reducing the width of each scanline, the drawing for each face could be cut in half, essentially turning the cubemap into a 3-face pyramid.

[Spike]

with a single paraboloid you could do 180 degrees with a single 'face', which is basically what you were going for earlier. of course, if you use a second one you can get full 360 with two views instead of 6. hence why I mentioned it.
with gl and a geometry shader you can just render to all 6 sides of a cubemap at the same time.
seeing as I'm not entirely sure why you created this topic, I'm not sure I can really help beyond that.

[mankrip]

Chopping up the surfaces for paraboloid mapping would require additional preprocessing and could result in significant slowdowns (just a guess). I can't see how two paraboloid maps could be faster than a single cubemap in this specific case. And as mentioned in this thesis, dual paraboloid maps have artifacts on their borders and aren't recommended for dynamic scenes because they can get wobbly.

Also, paraboloid mapping would probably allow for creating a fisheye lens effect without post-processing, but the post-processing step for this kind of effect is fast enough to be done in the software renderer, and can probably be done "for free" when underwater, so there's no need to avoid post-processing on the fisheye lens effect.

[mankrip]

Another idea: Since, in the software renderer, lines can be skipped while the spans are being drawn, it would be easy to do the vertical compression of the fisheye lens effect by skipping the unnecessary lines and condensing the required lines together on the fly, while still doing its horizontal compression during postprocessing. This would allow the number of cubemap faces to be reduced down to two, one for the left and one for the right.

[mankrip]

A run-lenght encoded offset table would probably solve the problem with the first approach I've suggested in this thread. It would allow the required pixels to be drawn directly at their final positions, while simultaneously skipping the rendering of all others, so an expanded framebuffer wouldn't be necessary. Such a table would also allow for linear filtering of the fisheye lens effect, but I don't think that would be necessary.

[qbism]

Related to cubmap face reduction, I wonder if a mask could be used to avoid rendering non-visible pixels of the cubemaps.

[qbism]

Looking at Aardappel fisheye code for speed gains, there's an expensive buffer copy that can be replaced with a simple swap-

Code: Select all

void rendercopy(int *dest)
{
    int *p = (int*)vid.buffer;
    vid.buffer = dest;
    R_RenderView();
    vid.buffer = p;
    /*int x, y;
    for(y = 0; y<vid.height; y++)
    {
        for(x = 0; x<(vid.width/4); x++,dest++) *dest = p[x];
        p += (vid.rowbytes/4);
    }; */
};

[qbism]

Just noticed activity on Blinky https://github.com/shaunlebron/blinky. Various types of Fisheye projection, scripted in Lua. Possibly some type is more efficient than cubemap and can be optimized.