Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Why does Deferred Lighting work with MSAA?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Tubos   Members   -  Reputation: 177

Like
0Likes
Like

Posted 14 August 2014 - 08:21 AM

I want to change my existing application from Forward Shading to Deferred Lighting.

I read that Deferred Lighting works with MSAA from the start. But I don't understand why.

 

In Deferred Lighting, we have a "n-buffer" which stores surface normals per screen pixel. We also have a "light buffer" which accumulates the intensity of diffuse lighting. (Let's ignore specularity for the moment).

Deferred LIghting has 3 steps:

1. Render geometry (surface normals and z-buffer only) to n-buffer

2. Render light volumes, adding their contributions into the light buffer

3. Render geometry again, reading from the light buffer to calculate final shading.

 

In my understanding, the backbuffer is antialised while n-buffer and light buffer are not.

In MSAA, the pixel shader is executed for each pixel center where one of the sub-samples is occupied by a triangle.

Wouldn't that mean that in step 3, the pixel shader would read from the wrong values in the light buffer, as the light buffer is not antialiased?


Edited by Tubos, 14 August 2014 - 08:22 AM.


Sponsor:

#2 MJP   Moderators   -  Reputation: 11593

Like
4Likes
Like

Posted 14 August 2014 - 02:48 PM

Your understanding is correct. In order to get the "correct" MSAA results (same results as if you used forward rendering), your lighting pass has to output lighting for every subsample in each pixel. Then, your geometry pass would also have to sample only the relevant subsamples from the lighting buffer based on the coverage of the triangle over the pixel. If you don't get this then your per-pixel lighting will cause strange artifacts at edges, and the results won't really appear to be antialiased (especially when using HDR lighting with arbitrary intensities).

 

Deferred lighting for situations where you really need a very small G-Buffer (TBDR GPU's on phones, Xbox 360 eDRAM) but otherwise it really doesn't have any advantages over a more traditional deferred rendering setup.



#3 Hodgman   Moderators   -  Reputation: 31153

Like
4Likes
Like

Posted 14 August 2014 - 08:29 PM

You can fix most of the MSAA artifacts (to the point where you can pretty much say that it 'supports MSAA') by using more than one lighting sample and a depth-sensitive filter during pass #3.

 

Normally in pass #3, you sample the lighting buffer once and use that data to calculate the final shaded colour.

Instead, sample the lighting buffer and the depth buffer multiple times -- say the pixel you would normally sample, plus the pixels to the left/right/top/bottom of it, for a total of 5 samples. For each sample, compare the geometry's current depth to the sampled depth value -- if the difference is beyond some threshold, then mark this lighting sample as being 'rejected'.

If the traditional (center) sample is not rejected, then use it. Otherwise, average together all of the non-rejected samples to get an approximately correct lighting value.

If all of the samples are rejected, then you're in trouble, and are forced to return an incorrect result -- maybe the sample with the lowest depth difference, or just the average of all samples. This case should only occur when rendering extremely thin objects.



#4 Tubos   Members   -  Reputation: 177

Like
0Likes
Like

Posted 15 August 2014 - 01:07 AM

Deferred lighting for situations where you really need a very small G-Buffer (TBDR GPU's on phones, Xbox 360 eDRAM) but otherwise it really doesn't have any advantages over a more traditional deferred rendering setup.
It does have the advantage of supporting MSAA on Direct3D9 hardware with little effort. For traditional deferred rendering there is no good Direct3D9 MSAA solution that I'm aware of.

 

In order to get the "correct" MSAA results (same results as if you used forward rendering), your lighting pass has to output lighting for every subsample in each pixel.
OK, if I understand that correctly, I can do one of two things:
a) Lighting and normals buffer has to be 2x or 4x the size (for 2x or 4x MSAA, respectively).

or b) Make the lighting and normal buffers antialiased, and then read from them. This only works in DirectX 10 and up, Direct3D9 cannot use an antialiased rendertarget as texture.

 

Thanks Hodgman, that flitering idea sounds nice and would work on DX9 class hardware with no problems as far as I can see.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS