One of the problems with bit-mapped graphics is “aliasing”. This is the phenomenon by which pixels along the edge of a pure shape will seem either to belong to that shape or not so, resulting in an edge which has rectangular errors. Even at fairly high resolutions, this can lead to a low-quality experience. And so schemes have been devised since the beginning of digital graphics, to make this effect less pronounced, even if we do choose raster-graphics.

3D has not been left out. One of the strategies which has existed for some time, is to Super-Sample each screen pixel, let us say by subdividing it by a fixed factor, such as 4×4 sub-pixels. This is also known as “Full-Screen Anti-Aliasing”, or ‘FSAA’. The output of the sub-pixels can be mixed in various ways, to result in a blended color-value for the resulting screen pixel.

But one problem with FSAA has been from the start, that it slows down rendering a whole lot. And so an alternative was devised, called Multi-Sampling.

The main idea behind Multi-Sampling is, that only the screen-pixels that span a triangle-edge, are objectionable in the degree with which they suffer from aliasing. Therefore, most of the screen-pixels are not super-sampled. And, the limited logic of the GPU has a hard time trying to distinguish, which triangle-edges are also model / entity -edges, where aliasing does the most damage. But, because the GPU has specialized logic circuits, which are referred to somewhat incorrectly as one render-output generator, that rasterize a given triangle, those circuits can be expanded somewhat feasibly into also being able to detect which screen-pixels do straddle the edge between two triangles. And then, for the sake of argument, only those may be subdivided into 4×4 sub-samples, each of which is Fragment-Shaded once.

But the logic gets just a bit more complicated. There is no simple way, in which the render-output generator can know, which other triangle a current triangle borders on. This is because in general, once each triangle has been processed, it is forgotten. Once each Geometry Shader input-topology has been processed, it too is forgotten, and the GS proceeds to process the next input-topology with complete amnesia…

And so in the case of Multi-Sampling, each border-pixel gets super-sampled at least twice, once as belonging to each of the adjacent triangles which share the edge. Also, because the GPU core is unknowing of the bordering triangle, it is unknowing at first, of possible jumps in depth that result.

(Edit 12/04/2017 :

The text which follows should be regarded as erroneous, because as I last learned, this was based on the false assumption, that Mulit-Sampling is indeed based on alpha-blending.

I have a more recent posting, in which I updated my blog with some more-accurate information on the subject. )

I think the way this gets handled, is in using something akin to Alpha-Blending. The screen-alpha of each pixel normally communicates to different rendering steps, to what extent the pixel in question is already occluded, on a continuous scale between [ 0.0 … 1.0 ] . Alpha-textures generally do not write the Z-buffer for that.

If the current triangle occupies 12% of any given screen-pixel, this fact is recorded in the alpha-channel.

But this effectively turns every screen-pixel into a potential alpha-pixel. Therefore the fact is curious, that such advanced rendering systems are still capable of distinguishing between entities which the content-developers deems to have alpha, and those which he deems not to.

BTW, in Multi-Sampled systems, all the screen-pixels that are deemed to have alpha by the content-definitions, are also super-sampled.



Print Friendly, PDF & Email

3 thoughts on “Multisampling”

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>