Colour Banding in the sky when doing Supersampling

[werner.poetzelberger]

Hello,

 

I just have to explain it cant show an image right now, but would need an urgent answer and ideas about that!

 

We do have color banding occuring in the sky at certain times. You know these stepping of a gradient as there is too little differentiation between colors, so the gradient goes green/red at a transition.

 

This is NOT a problem when rendering in a standard resolution (nothing special applied, no post effects, no aa, no dof etc.)

 

We are doing Supersampling with the scene. So we are rendering the image 2x bigger and then showing it in the final resolution.

Using this method, these color banding occurs.

 

Unforunately I cant explain it technically atm.

 

I know, that Unigine got rid of color bending artefacts in the sky as I can remember a SDK where it was posted as a feature.

 

Does someone know anything about a method of getting rid of those things even when we use supersampling?

The thing is, that we will show the image on a huuge LED wall, so every little artefact is totally distracting.

 

I will add some more infos or screens soon.

 

Thank you.

 

Werner

 

[silent]

Hi Werner,

 

We managed to solve this issue by using RGB10A2 color buffer. Variable render_use_rgb10a2 should be set to 1 in application config to remove banding artifacts.

[werner.poetzelberger]

Hello Silent-
Right.

Somehow that doesnt work with our Supersampling implementation.

It is becoming quite obvious at dusk/dawn but when turning down scattering quickly (low frequenzy gradients), the streaks can be avoided.

Not a solution but a hack.

[helmut.bressler]

Hello Silent,

In order to achieve supersampling we have introduced our own App implementation. It is D3D11 only, it is creating a off screen render target in DXGI_FORMAT_R10G10B10A2_UNORM format of twice the window resolution. In the App::doSwap() method the image is downsampled to the acutal window resolution and written into the swap chain (which is of DXGI_FORMAT_R10G10B10A2_UNORM format as well as the offscreen highres texture). Our App implementation also supports rendering without super sampling, which works identitcal except that it is using the ID3D11DeviceContext::CopyResource() method instead of a shader in order to get the image into the swap chain.

Now the interesting thing is that the banding problem only arises when I'm using my own App implementation WITH supersampling turned on. (I also tried using a copy pixel shader instead ID3D11DeviceContext::CopyResource(), but it didn't change the color banding behaviour).


I have made screengrabs for documenting this.screengrabs.zip


My assumption would be that there is sort of a noise overlay in the scattering which gets cancelled out while the high res image gets downsampled.

We quite urgently need to find a solution for this, we have only a few days remaining before the whole project will be shown to the public, so any advice is highly appreciated!

Thanks for your help!
   Helmut

(OT: by the way I have seen your response on the expression parameter issue, thank you very much for this, I just was too busy to respond!)

[silent]

Hi,

 

Any change to take a look at your App implementation? Basically, we need a App sample code which can be build using our SDK to check what really is going on here.

 

Thanks!

[werner.poetzelberger]

We get some very good results by blending a noise texture post over the scene.

(an old trick we were doing before) but it actually helps a lot.

[silent]

Hi Werner,

 

Great news! I believe this is the fastest method to get rid of the colour banding.

[helmut.bressler]

Hello Silent,

 

Thank you for offering your help, my from App derived class is using my own d3d11 c++library (which I usually use for tests/demo programming), it contains some unused stuff which is beyond a minimal implementation of an App class. The reason for this is that my .exe provides also functionality for per frame cubemap blending, so they are sharing the d3d11 device and code for shader loading, render state managing and so on.

We are so under time pressure now that I don't see the possibility of cleaning up the code right now, but if the noise solution does not help we will continue to investigate it in october.

 

Many thanks!

 Helmut