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

Design question: Anti-aliasing and deferred rendering.

This topic is 864 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 would like to render smooth images.

Current application has evolved from forward renderer to differed and consist of several stages:

  1. <not implemented yet> Shadow map.
  2. Opaque meshes geometry pass: to GBuffer (no MSAA).
  3. SSAO: to 8-bit texture, opaque meshes only (no MSAA) + 2-pass bilateral blur.
  4. Light pass: rendering into HDR texture (no MSAA).
  5. Tone mapping: rendering to LDR back buffer (MSAA). Depth is copied pixel-by-pixel.
  6. Transparent pass: rendering to back buffer (MSAA).
  7. HUD meshes (mostly wireframes): to back buffer (MSAA).

Because of this architecture, I have 2 depth buffers: no-MSAA for GBuffer and MSAA for back buffer.

Also I have excellent quality on stages 6 and 7.

 

But right now I am thinking of making opaque meshes look better.

It seems it’s good time to redesign stages.

 

I read it’s better to make all rendering without MSAA and make additional last full-screen pass that blurs aliasing like FXAA.

In this case I will no need of 2 depth buffers, just one, and also back buffer and depth buffer will have no MSAA.

Question1: is this correct?

 

I assume I should implement FXAA by myself. It is not video card feature.

Question2: is this correct?

 

It seems a lot of full-screen AA algorithms out there.

Question3: which algorithm it’s better to use?

 

Question4: could you add other suggestions on improving my rendering pipeline from design point of view?

 

Thanks for help.

Edited by Happy SDE

Share this post


Link to post
Share on other sites
Advertisement

You can't go from a non-MSAA GBuffers & Light passes go to MSAA tonemapping. It just doesn't work like that and makes no sense.

 

Overview of MSAA is a good introduction on how MSAA works. MSAA resolve filters is also a good read.

 

You have to start with MSAA GBuffers, avoid resolving them, and resolve the tonemapped result. This is what makes Deferred Renderers + MSAA so damn difficult. SV_Coverage + stencil tricks can help saving bandwidth.

Share this post


Link to post
Share on other sites

You can't go from a non-MSAA GBuffers & Light passes go to MSAA tonemapping. It just doesn't work like that and makes no sense.

I don't.

 

For lighting pass, render target (HDR texture) is DXGI_FORMAT_R16G16B16A16_FLOAT, 1 sample count, 0 quality.

 

For tone mapping, all SRV are 1 sample count, 0 quality. Render target is back buffer with MSAA enabled, output depth buffer is MSAA enabled.

Texture2D<float4> HdrColor     : register(t0);
Texture2D<float>  HdrDepth     : register(t1);
StructuredBuffer<float> AvgLum : register(t2);

float4 ToneMapping(float4 HDRColor)
{
        ... calculate
	return float4(HDRColor* LScale);
}

struct PS_OUTPUT
{
	float4 color : SV_Target;
	float  depth : SV_DEPTH;
};

PS_OUTPUT main(float4 pos : SV_Position)
{
	int3 texCoord = int3(pos.xy, 0);

	PS_OUTPUT ret;
	
	ret.color = ToneMapping(HdrColor.Load(texCoord));
	ret.depth = HdrDepth.Load(texCoord);

	return ret;
}
Edited by Happy SDE

Share this post


Link to post
Share on other sites

That doesn't work either. You can go from MSAA to non-MSAA (resolving) but the opposite makes no sense.

Share this post


Link to post
Share on other sites

You probably don't want your HUD to be done with MSAA. If it's a 2D thing you can bake in the AA, simplifying everything. If it's a 3D hud then sure MSAA might make sense.

 

Your tone mapping appears to be rendering a fullscreen quad. Since MSAA only really does anything for edges, this isn't going to do anything.

Share this post


Link to post
Share on other sites

You probably don't want your HUD to be done with MSAA.

Sorry, (I am not a native speaker) maybe I stated it wrong.

 

"HUD" for me is rendering aux objects like origin, axes, bounding boxes, vertex normals, ...

I like them be AA. =)

 

Please take a look at a picture below.

Edited by Happy SDE

Share this post


Link to post
Share on other sites

That doesn't work either. You can go from MSAA to non-MSAA (resolving) but the opposite makes no sense.

Please take a look at the picture: lines and transparent objects are AA, opaque - are not =(

I don't resolve anything.

Upon non-AA (low-quality) GBuffer geometries, I am rendering AA (high-quality) transparent geometries and lines.

In current implementation tone mapping is not applied to HUD and transparent meshes.

 

Right now I want to remove aliasing from opaque meshes.

All four questions from this post are about better design.

 

[attachment=30970:sample.png]

Edited by Happy SDE

Share this post


Link to post
Share on other sites

If you want to remove aliasing from your opaque meshes then you need to make your GBuffer and light passes MSAA. Or use some kind of post processing filter like FXAA or SMAA.

Edited by Mona2000

Share this post


Link to post
Share on other sites

If you want to remove aliasing from your opaque meshes then you need to make your GBuffer and light passes MSAA.

Or use some kind of post processing filter like FXAA or SMAA.

 

So I have to choose =)

 

Let it be FXAA! smile.png (I saw it in Hodgman’s perf log)

 

I will restate all my questions in two statements:

  1. FXAA is a post-processing full screen effect, that should be implemented by me. It is not NVidia driver’s settings. It might be an NVidia settings, but I should implement this effect as my own code in order to be user-friendly.
  2. In all stages there is no need to use MSAA render targets, because FXAA algorithm will fix aliasing.

Please correct me if I am wrong.

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!