Jump to content
  • Advertisement
Sign in to follow this  
Happy SDE

GBuffer and Antialiasing. Part2

This topic is 914 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

Hi!

 

I am doing my rendering engine.

It contains GBuffer that has no subsamples (only 1 sample per pixel).

I added FXAA post-processing filter and it works good.

 

I decided to do better and after some research found SMAA filter.

SMAA filter has several modes: 1x, S2x, 4x;

1x works with only 1 sample/pixel, but S2x and 4x are require input texture to be MSAA 2x.

 

And now I get lost.

 

Does it mean that all textures inside my GBuffer (Normal texture, Diffuse, Specular, Emissive, HDR light accumulator, and HDR output) should be MSAA 2x also?

I can't understand: after geometry pass, would subsamples in Normal, Diffuse, Specular... textures contain information of different geometries?

In other words: in light pass, would it be possible to run on sub-pixel level of GBuffer or all geometry information will merged to per-pixel data right after geometry pass?

 

Are there some caveats I should be aware of before moving GBuffer to be MSAA 2x?

 

Or should I do something different in order to achieve SMAA 4x quality with reasonable performance impact?

 

Has anyone implemented engine with GBuffer and SMAA?

How does it look like (stages+main textures with or without MSAA)?

It seems I came to a point where tutorials are no longer source for further information smile.png

 

Thanks in advance.

Edited by Happy SDE

Share this post


Link to post
Share on other sites
Advertisement

One thing that puzzles me, is where the MSAA subsamples information is stored?

I am curious about this because I can't figure out, how to do straight MSAA between geometry and light passes in deferred renderer.

Common sense says to me that subsample information should be stored somewhere before I do resolve, but I can't find it in a debugger.

All the articles I read say that MSAA increases memory footprint proportionally of samples count.

 

My engine is capable of forward rendering with 8xMSAA and here the only biggest textures were created:

Name                                                         Size       Type                           width height Samples

Forward::DepthStencil D3D11 Texture2D 7916912 R24G8_TYPELESS   1916 1033   8

Forward-BackBuffer     DXGI Surface       7916912 R8G8B8A8_UNORM 1916 1033   8

 

 

The same texture sizes I can see with sample count = 1 in other, deferred renderer mode:

Name                                                                        Size         Type                                  width height Samples

GBuffer::8_HDR Light Accum    D3D11 Texture2D 15833824 R16G16B16A16_FLOAT  1916 1033 1

Deferred::DepthStencil D3D11  Texture2D              7916912   R24G8_TYPELESS         1916 1033 1

Deferred-BackBuffer                  DXGI Surface        7916912   R8G8B8A8_UNORM       1916 1033 1

GBuffer::0_Normal                     D3D11 Texture2D  7916912   R10G10B10A2_UNORM 1916 1033 1

 

I see the same result in VS 2015 and NSight 5.0

 

In the other words, if I am going to make all textures in GBuffer 2xMSAA, it should increase memory footprint twice.

But right now I can't see size difference between textures created with 8xMSAA and without MSAA.

 

Any ideas? =)

If it does matter, I have NVidia 660GTX.

Edited by Happy SDE

Share this post


Link to post
Share on other sites

I found a way to measure memory footprint for MSAA textures!

Process Explorer can show it on process properties tab:

footprint.png

Deferred renderer has a lot of full-screen textures (about 10), all of them are no-AA,

Forward renderer has only 2 (render target and depth), but it uses twice memory than Deferred.

 

It seems that VS 2015 and NSight 5.0 debuggers mean something different for size of textures.

 

So I am ready to convert my GBuffer to 2xMSAA in order to use 4xSMAA!!! :)

Edited by Happy SDE

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!