Jump to content

  • Log In with Google      Sign In   
  • Create Account


HDR + Tonemapping + Skylight = Fail?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
53 replies to this topic

#1 riuthamus   Crossbones+   -  Reputation: 4454

Like
0Likes
Like

Posted 25 August 2012 - 03:41 PM

So, we got some free time and wanted to add in some sexy lighting to our system. ( we already had lighting but without the HDR and Tonemapping ). We took a look at how MJP suggested to do it and implemented it in a way that matched his for the most part. After doing so we noticed our entire world got really dark! Some of you might not know what these two things are:

HDR: ( fastest description for easy understanding )

Basically makes your images high contrast showing a wider range of color and depth.

TONEMAPPING:

Takes HDR and turns it back to LDR for displaying on monitors and for print preparation, since most monitors do not display images in HDR contrast ratios.

So... in theory this is why our entire world started to get dark. The problem is we dont know what settings to modify or mess with in order to fix our issue related to darker than normal looks. We could, and have, amped up the lighting values to some crazy number and while that did fix some of the issues it did not fix our sky.

This brings us to the new problem, how do we get the HDR and Tonemapping to properly apply to the sky? BTW, this was all spawned from trying to create caves and lighting in them! DAMN YOU CAVES!!

Sponsor:

#2 Radikalizm   Crossbones+   -  Reputation: 2793

Like
3Likes
Like

Posted 25 August 2012 - 03:58 PM

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.

I gets all your texture budgets!


#3 kauna   Crossbones+   -  Reputation: 2278

Like
2Likes
Like

Posted 25 August 2012 - 03:58 PM

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!

#4 riuthamus   Crossbones+   -  Reputation: 4454

Like
0Likes
Like

Posted 25 August 2012 - 04:21 PM

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 ):
Posted Image

AFTER TONEMAPPING AND AUTO EXPOSURE:
Posted Image

#5 Radikalizm   Crossbones+   -  Reputation: 2793

Like
2Likes
Like

Posted 25 August 2012 - 04:36 PM

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 gets all your texture budgets!


#6 riuthamus   Crossbones+   -  Reputation: 4454

Like
2Likes
Like

Posted 25 August 2012 - 04:39 PM

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

#7 Radikalizm   Crossbones+   -  Reputation: 2793

Like
0Likes
Like

Posted 25 August 2012 - 04:51 PM

My pleasure Posted Image

I gets all your texture budgets!


#8 riuthamus   Crossbones+   -  Reputation: 4454

Like
0Likes
Like

Posted 25 August 2012 - 05:24 PM

My pleasure Posted Image


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

#9 Radikalizm   Crossbones+   -  Reputation: 2793

Like
0Likes
Like

Posted 25 August 2012 - 05:32 PM


My pleasure Posted Image


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


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

I gets all your texture budgets!


#10 riuthamus   Crossbones+   -  Reputation: 4454

Like
0Likes
Like

Posted 25 August 2012 - 05:54 PM



My pleasure Posted Image


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


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


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! :P

#11 Telanor   Members   -  Reputation: 1295

Like
0Likes
Like

Posted 25 August 2012 - 06:24 PM

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

#12 riuthamus   Crossbones+   -  Reputation: 4454

Like
0Likes
Like

Posted 25 August 2012 - 08:03 PM

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...

#13 Hodgman   Moderators   -  Reputation: 28426

Like
0Likes
Like

Posted 25 August 2012 - 10:34 PM

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...

#14 riuthamus   Crossbones+   -  Reputation: 4454

Like
0Likes
Like

Posted 25 August 2012 - 11:29 PM

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!

#15 ZBethel   Members   -  Reputation: 544

Like
1Likes
Like

Posted 26 August 2012 - 12:39 AM

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.

#16 Telanor   Members   -  Reputation: 1295

Like
1Likes
Like

Posted 26 August 2012 - 01:38 AM

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?

#17 Hodgman   Moderators   -  Reputation: 28426

Like
3Likes
Like

Posted 26 August 2012 - 03:05 AM

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.

Edited by Hodgman, 26 August 2012 - 03:11 AM.


#18 riuthamus   Crossbones+   -  Reputation: 4454

Like
0Likes
Like

Posted 26 August 2012 - 06:55 AM

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.


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! Posted Image just know we got more to fix

Massive Overblur:
Posted Image

Normal Look:
Posted Image

Slight Overblur:
Posted Image

Edited by riuthamus, 26 August 2012 - 07:09 AM.


#19 riuthamus   Crossbones+   -  Reputation: 4454

Like
0Likes
Like

Posted 27 August 2012 - 03:23 AM

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.

#20 quiSHADgho   Members   -  Reputation: 325

Like
1Likes
Like

Posted 27 August 2012 - 04:50 AM

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...

Edited by quiSHADgho, 27 August 2012 - 04:52 AM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS