HDR + Tonemapping + Skylight = Fail?

What kind of tonemapper are you using? Are you using a decent adaptive exposure system?
HDR isn't just some plug-and-play technique, you need to design your lighting pipeline around it to make it work properly.

Hi,

Probably your sky texture is a low-dynamic-range texture ranging from 0.0 - 1.0 and your HDR values are some magnitude bigger. So, you may multiply your sky color by some value which makes it look nice. Also, you may make your sky texture a HDR texture too, and using some clever encoding it may not take more space than a regular texture.

Cheers!

What kind of tonemapper are you using? Are you using a decent adaptive exposure system?
HDR isn't just some plug-and-play technique, you need to design your lighting pipeline around it to make it work properly.

Indeed, we noticed this shortly after adding it to the project! It changes all my settings when I enable the HDR since sun and sky and even ground lighting has to be modified to correct for it. We are using the system that MJP suggested for tonemapping, although our knowledge on the subject is limited compared to his we figured it would be best to try and mimic it. I think the name is called Reinhart? We do have auto exposure system... although as to how well it is working cant really be decided at this point since everything is just ultra dark!

Hi,

Probably your sky texture is a low-dynamic-range texture ranging from 0.0 - 1.0 and your HDR values are some magnitude bigger. So, you may multiply your sky color by some value which makes it look nice. Also, you may make your sky texture a HDR texture too, and using some clever encoding it may not take more space than a regular texture.

Cheers!

Well, you are correct to some degree, although we do not have a sky texture. We are using code to create the colors, but we are noticing the same thing... the sky light in hdr is like 12 but with the tone mapping applies we are getting .42 or something... obviously very different numbers.

and to better understand I have attached some pictures!

BEFORE TONEMAPPING and AUTO EXPOSURE ( So just HDR ):


AFTER TONEMAPPING AND AUTO EXPOSURE:

I'd recommend you try out some different tone mapping algorithms (definitely look at some filmic tone mappers) and to adapt your lighting to work properly in a HDR environment.
Have a look at John Hable's site, he has some very decent articles about tonemapping and HDR-related techniques which go into quite some detail.

I'd recommend you try out some different tone mapping algorithms (definitely look at some filmic tone mappers) and to adapt your lighting to work properly in a HDR environment.
Have a look at John Hable's site, he has some very decent articles about tonemapping and HDR-related techniques which go into quite some detail.

You are a wealth of information sir! thank you

My pleasure

My pleasure

saw your project, looks really good! Good luck with the engine!

[quote name='Radikalizm' timestamp='1345935064' post='4973357']
My pleasure

saw your project, looks really good! Good luck with the engine!
[/quote]

This is quite off-topic, but our site is horribly outdated I'm afraid.
There have been some major improvements to our technology (the screenshots on the site show mostly old techniques) and our main focus is actually our game of which we've shown absolutely nothing yet

[quote name='riuthamus' timestamp='1345937053' post='4973362']
[quote name='Radikalizm' timestamp='1345935064' post='4973357']
My pleasure

saw your project, looks really good! Good luck with the engine!
[/quote]

This is quite off-topic, but our site is horribly outdated I'm afraid.
There have been some major improvements to our technology (the screenshots on the site show mostly old techniques) and our main focus is actually our game of which we've shown absolutely nothing yet
[/quote]

Indeed, off topic, but i saw your engine and saw some of the screenshots you had and thought "This guy might actually know what he is talking about" since you already seem to have some of the effects/lighting being described here. Anyway, back to ON TOPIC!

I'm not sure how to try different tone mapping algorithms or how to even adjust the one we have. I adapted the code from here to work in our project: http://www.xnainfo.com/content.php?content=28. The tone mapping code from that looks like this:


float g_fMiddleGrey = 0.3f;
float g_fMaxLuminance = 16.0f;

static const float3 LUM_CONVERT = float3(0.299f, 0.587f, 0.114f);

float3 ToneMap(float3 vColor)
{
// Get the calculated average luminance
float fLumAvg = SourceTexture1.Sample(PointSampler, float2(0.5f, 0.5f)).r;

// Calculate the luminance of the current pixel
float fLumPixel = dot(vColor, LUM_CONVERT);

// Apply the modified operator (Eq. 4)
float fLumScaled = (fLumPixel * g_fMiddleGrey) / fLumAvg;
float fLumCompressed = (fLumScaled * (1 + (fLumScaled / (g_fMaxLuminance * g_fMaxLuminance)))) / (1 + fLumScaled);
return fLumCompressed * vColor;
}


I've tried adjusting the constants, nothing seemed to change really. Ive also looked at the code from the DX sample and from this site: http://filmicgames.com/archives/75 but I have no idea how to adapt it to work with what I have

Yeah, so this is more or less the issue... i guess. Our implementation is off or we are stuck with trying to modify it... hm...

On my last game, we just gave our sky dome shader a 'brightness multiplier' so we could tweak it until it looked right. IIRC we went with something like the sky being 10x brighter than our average spot lights, but in real-life the sky is more like 10000x brighter than a light-bulb...

Interesting... that is something we might be able to try. We removed the complicated sky and added in a basic one to see if that was causing the problem but it was not. We will see what doing the brightness, would do. Thanks!

Which tonemapper are you using? I had a lot of trouble getting it to look right for my project, but the uncharted 2 filmic mapping method ended up looking great. The cause could either be the tone mapping algorithm itself, or just incorrect light values in your scene. From your screenshots, it looks like the tone mapper itself isn't set up right.

I think the reason for the problem is a combination of drawing the sky to the gbuffer's color RT (which is a R8G8B8A8_UNORM_SRGB surface) and that the final composite gbuffer RT is also in that format. If I switch them to 64 bit formats everything seems to work then. If I do that though, we end up with 4 (and probably more from the intermediate RTs) of these 64 bit fullscreen RTs, which uses quite a bit of memory. I can avoid that if I use LogLuv encoding, but then the image looks weird when using an _SRGB surface. Does the SRGB gamma correction not work with LogLuv? Is there a way around that?

I think the reason for the problem is a combination of drawing the sky to the gbuffer's color RT (which is a R8G8B8A8_UNORM_SRGB surface)

Usually the GBuffer stores surface albedo, which is a 0-1 fractional/percentage value. A skydome is more like an emissive surface though, than a regular diffuse surface, so yeah, it doesn't make sense to render it into your GBuffer's albedo channels. When adding emissive surfaces to a deferred renderer, the usual approach is to render these surfaces directly into your light-accumulation buffer, instead of into the GBuffer.

Regarding SRGB and LogLUV: when using an SRGB texture, it will go through a linear->gamma transform when writing, and a gamma->linear transform when sampling, so it shouldn't have much of an impact, but it can mean that the value that you sample later is slightly different to the value that you wrote originally. This transform is only designed to be used to store RGB "colour" information in a perceptually efficient way (distributing more bits to darker colours) where it doesn't matter if there is a slight change in the values.
However, LogLUV splits the L component over 2 8-bit channels, and if either of those channels is slightly modified, then when you reconstruct the original 16-bit value, it will be wildly different. This makes it more of a "data" texture than a "colour" texture, and so SRGB encoding should not be used.

[quote name='Telanor' timestamp='1345966702' post='4973421']I think the reason for the problem is a combination of drawing the sky to the gbuffer's color RT (which is a R8G8B8A8_UNORM_SRGB surface)

Usually the GBuffer stores surface albedo, which is a 0-1 fractional/percentage value. A skydome is more like an emissive surface though, than a regular diffuse surface, so yeah, it doesn't make sense to render it into your GBuffer's albedo channels. When adding emissive surfaces to a deferred renderer, the usual approach is to render these surfaces directly into your light-accumulation buffer, instead of into the GBuffer.

Regarding SRGB and LogLUV: when using an SRGB texture, it will go through a linear->gamma transform when writing, and a gamma->linear transform when sampling, so it shouldn't have much of an impact, but it can mean that the value that you sample later is slightly different to the value that you wrote originally. This transform is only designed to be used to store RGB "colour" information in a perceptually efficient way (distributing more bits to darker colours) where it doesn't matter if there is a slight change in the values.
However, LogLUV splits the L component over 2 8-bit channels, and if either of those channels is slightly modified, then when you reconstruct the original 16-bit value, it will be wildly different. This makes it more of a "data" texture than a "colour" texture, and so SRGB encoding should not be used.
[/quote]

Thank you, this is very informative. We got part of it working, once we get the overblur fixed I will show you guys... hell ill show you right now i guess! just know we got more to fix

Massive Overblur:


Normal Look:


Slight Overblur:

Dont want to bump but not sure if somebody saw my question, any clue as to what would create that? Would it be the bloom maybe? we placed a block that was very light purple and the block more or less lit itself up... was odd.

Hopefully I did not overread something...
Do you stll use the tonemapping function from xnainfo? If so: there is a small error in the shadercode Telanor posted.
Instead of
return fLumCompressed * vColor
it has to be
return fLumCompressed * vColor / fLumPixel
MJP posted it on his blog but it was never corrected on xnainfo.

Makes it look better but I also have a hard time getting it to work and I don't think it helps with your overblur sorry...