Jump to content
  • Advertisement
Sign in to follow this  
WFP

Direct3D 11 Deferred Shading Banding

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

Greetings,

 

I am having some issues with my deferred shading implementation that I am spinning my tires on.

 

The back buffer format I am using is:

DXGI_FORMAT_R8G8B8A8_UNORM.

 

My GBuffer render targets are:

 

GBufferSetup     R                 G                B                A
SV_Target0        normal.x      normal.y     normal.z     specularPower
SV_Target1        diffuse.r       diffuse.g     diffuse.b     ambient.r
SV_Target2        specular.r    specular.g   specular.b  ambient.g
SV_Target3        position.x     position.y   position.z   ambient.b
 

SV_Target0 is DXGI_FORMAT_R32G32B32A32_FLOAT

SV_Target1 is DXGI_FORMAT_R8G8B8A8_UNORM

SV_Target2 is DXGI_FORMAT_R8G8B8A8_UNORM

SV_Target3 is DXGI_FORMAT_R32G32B32A32_FLOAT

 

The texture used for my light pass (additive blending) is also DXGI_FORMAT_R32G32B32A32_FLOAT.

 
I know some the rgba32_f textures may be overkill, but I'm just trying to get things working before worrying about saving too much on bandwidth and other similar concerns - with such simple scenes (one sphere and a plane for the ground, oh my!) there's not too much performance impact smile.png.
 
I have Googled around and tried a number of different fixes such as using a DXGI_FORMAT_R16G16B16A16_FLOAT back buffer format and changing the GBuffer and light pass render target formats around, but so far everything still has the ugly banding present.

 

Here is an example of what is going on.

[attachment=14417:ugly banding r8g8b8a8_unorm_bbuffer.PNG]

 

Any insight to possible fixes I may have missed would be greatly appreciated.  I may be missing something obvious, and have just been staring at it for too long.  If there is any other information I can supply to better troubleshoot this issue, just let me know.

 

Thanks!

 

Share this post


Link to post
Share on other sites
Advertisement

Have you tried putting a texture on the plane ? :)

I think that would plainly fix the problem you're having. (You are talking about the banding at the light's falloff on the ground, right?)

You might want to read this: http://en.wikipedia.org/wiki/Colour_banding. Basically it has something to do with the monitor not being able to produce the gradients in between.

Anyway try to put a texture on it.

Share this post


Link to post
Share on other sites

Analyzing the picture in an image editor shows the 8-bit color value decreasing by one at each band, so you simply don't get more color resolution from a 8-bit backbuffer. The result would be the same with forward rendering.

Share this post


Link to post
Share on other sites

liprsyme:  Yes, I should have mentioned it, but the texture I'm using for the floor plane is just a 1 x 1 pixel white texture that's just tiled over the entire thing.  The texture's format is X8R8G8B8, but I also tried just a few moments ago changing that to A16G16B16R16F just to see if it would help.  It did not.

 

AgentC:  Interesting.  What about the fact that the bands are still there when using the DXGI_FORMAT_R16G16B16A16_FLOAT back buffer format?  I've posted a picture.  Please disregard the non-gamma-correctedness of it (it's automatically put into linear color space, see here http://msdn.microsoft.com/en-us/library/windows/desktop/ff471325(v=vs.85).aspx).  At this point, is it basically just the fact that the monitor is incapable of producing a colors between those banded values?  By the way, you're right - the image is produced identically when I switch to the forward renderer.

 

powly k:  That's a good idea, I may try that out if it turns out to be strictly a monitor-related issue.

 

Editted to include image and forward rendering comment.

Edited by WFP

Share this post


Link to post
Share on other sites

Well of course what I was trying to say was not to use a solid color as the texture but an actual "texture". Because you will only see color banding appear clearly on those solid color gradients. Giving the backbuffer more precision won't help either as powly k also pointed out it's a (monitor)panel issue. Btw that doesn't mean that your monitor sucks xD probably 90%+ will show this behavior.

Edited by lipsryme

Share this post


Link to post
Share on other sites

lipsryme: OK, I see what you were saying now, and yes using a "real" texture does alleviate the problem (for example the sphere in the first picture I posted doesn't have an issue).  I was just making sure I wasn't doing something incorrectly elsewhere to cause the bands, but it definitely looks to be monitor limitations.

 

Thank you and all others who posted for your help with this!

Share this post


Link to post
Share on other sites

What about the fact that the bands are still there when using the DXGI_FORMAT_R16G16B16A16_FLOAT back buffer format?

 

Not 100% sure, but I would guess that Windows composites / blits a float backbuffer to 8 bits per channel before displaying.

Share this post


Link to post
Share on other sites

Of course there is going to be banding. Using a 16-bit back buffer isn't going to make any difference since it's still going to get quantized to 8-bit when being displayed. You would have to render to a HDR buffer and then perform some type of dithering operation when converting to 8-bit LDR for display.

Share this post


Link to post
Share on other sites

As far as I know A2R10G10B10 format is supported in full screen modes and should give less banding if your monitor supports more than 8-bits per channel. DX SDK even had a sample about it. 

 

The problem you are describing is difficult to handle, but typically you won't notice the problem since most of the surfaces are textured and texturing hides the problem pretty well.

 

Cheers!

Edited by kauna

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!