Multisampled Post-Processing (MSAA)
Currently, post-process shaders force a multisampled framebuffer to be resolved (converted to a single value per pixel by blending the samples together based on their coverage). For things like fog, this means there's only a single depth value available, and so fog changes sharply from pixel to pixel, removing nearly all the benefit of multisampling.
There are two kinds of mutlisampling-aware post-processing possible:
Custom resolve
Instead of having fixed-function hardware do the resolve, it's possible to have a single post-process shader see the multisampled FBO as a multisampled texture and output to a regular FBO. Normally this is used for things like fancy antialiasing that combines a post technique with the extra samples to get better results for less work, but it could instead resolve the fog problem. Irritatingly, it can't do both unless someone writes a monolithic post pass that applies all the effects together, which would be nightmarish.
Supersampled post-processing
If you have a custom resolve pass copy the data from a mutlisampled texture into a much higher-resolution single-sampled one, you can avoid discarding any data, and then can do regular post-processing on the bigger textures before finally downsampling to the display resolution. However, you'll have a majority of pixels that are identical to all their neighbours as they came from a pixel in the original FBO that only had one sample with any coverage, and that means the later post passes need to do duplicate work. Also, depending on how the hardware implements multisampled FBOs and textures, it might eat more VRAM and bandwidth.
True multisampled post-processing
GL4 capable hardware can run compute shaders, and one of the things a compute shader can do that other shaders can't is arbitrary writes to images. That means a compute shader can run a post pass once on each of the samples with coverage, output the results to samples in a new multisampled texture, and copy across the coverage mask.
So...
Implementing support for custom resolve shaders should be pretty simple as nearly everything's exactly the same as we've got already, except we make the last pass texture a GL_TEXTURE_2D_MULTISAMPLE
instead of a GL_TEXURE_2D
, and then OSG won't resolve it for us. It's not hugely helpful on its own, but will be useful for things like SMAAS2X.
Implementing the compute-shader-based approach would be nice, so unless we think of something clever, that's what I'd count as this feature request being fulfilled.
Despite working on older hardware, I'd not bother with the supersampling-based approach as I expect nearly all hardware that can't handle compute shaders to also be so old and slow that it can't handle high-quality rendering anyway.