Jump to content
  • Advertisement
Pilpel

Is MSAA affected by drawing order?

This topic is 443 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've read that in MSAA each pixel's final color is an interpolation of its current color and the triangles color, depending on how many samples the triangle is covering.

That means that when drawing the scene in different orders affects the "current color" I mentioned above. So if I draw the scene in different orders when using MSAA, will the final render image be affected by this?

Share this post


Link to post
Share on other sites
Advertisement
1 minute ago, Pilpel said:

I've read that in MSAA each pixel's final color is an interpolation of its current color and the triangles color, depending on how many samples the triangle is covering.

No, it stores N colours (e.g. 2xMSAA stores 2 colours) and the "resolve" stage at the end blends them together.

Share this post


Link to post
Share on other sites
1 hour ago, Pilpel said:

If it stores N times more colours, how is it different that SSAA?

For what I know, in SSAA that color is calculated per each pixel with the image being 4 times higher resolution if we talk about 4x SSAA and then downsampled to your actual resolution.

With MSAA you render the image at your monitor resolution (so you start with 4 time less calculation compared to above) and then for each pixel of that, the same calculated color is shared for each of the 4 sub-pixels based on visibility (using depth buffer, 4 times bigger) and coverage (is the subpixel inside or outside the polygon?), and then the 4 sub-pixels(my example is 4xMSAA) are averanged togeter to get the final color, and all this check and averange is apparently less expensive than actually calculating the real lighting for 4 pixels, since you do 1/4 of the heavy calculation only once compared to SSAA.

Take it as a grain of salt, I am begginner in this.

Edited by MarcusAseth

Share this post


Link to post
Share on other sites
40 minutes ago, Pilpel said:

So SSAA and MMAA have the same memory usage?

I bet they do, but I would like to know the informed answer to this as well :P

 

Share this post


Link to post
Share on other sites

I'm not sure if I get it. Does MSAA differ from SSAA in a way that the pixel shader is ran, most of the times, fewer times per pixel?

Quote

In the extreme case where each of the multi sample locations is covered by a different triangle, a different shading computation will be performed for each location and the results then combined to give the final pixel, and the result and computational expense are the same as in the equivalent supersampled image.

Memory usage (number of elements in the color buffer) seems to be the same for both MSAA and SSAA, no?

Share this post


Link to post
Share on other sites

MSAA doesn’t actually improve on supersampling in terms of rasterization complexity or memory usage. At first glance we might conclude that the only advantage of MSAA is that pixel shader costs are reduced. However this isn’t actually true, since it’s also possible to improve bandwidth usage. Recall that the pixel shader is only executed once per pixel with MSAA. As a result, the same value is often written to all N subsamples of an MSAA render target. GPU hardware is able to exploit this by sending the pixel shader value coupled with another value indicating which subsamples should be written, which acts as a form of lossless compression. With such a compression scheme the bandwidth required to fill an MSAA render target can be significantly less than it would be for the supersampling case.

Share this post


Link to post
Share on other sites
20 minutes ago, GibbonThatCodes said:

... As a result, the same value is often written to all N subsamples of an MSAA render target.

This only happens inside a triangle, right?

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!