• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
riuthamus

HDR + Tonemapping + Skylight = Fail?

53 posts in this topic

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:

[b]HDR:[/b] ( fastest description for easy understanding )

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

[b]TONEMAPPING:[/b]

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!!
0

Share this post


Link to post
Share on other sites
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!
2

Share this post


Link to post
Share on other sites
[quote name='Radikalizm' timestamp='1345931888' post='4973346']
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.
[/quote]

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!

[quote name='kauna' timestamp='1345931889' post='4973347']
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!
[/quote]

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!

[b]BEFORE TONEMAPPING and AUTO EXPOSURE ( So just HDR ):[/b]
[img]http://www.bhslaughter.com/forum/uploads/gallery/album_168/gallery_1_168_46374.jpg[/img]

[b]AFTER TONEMAPPING AND AUTO EXPOSURE:[/b]
[img]http://www.bhslaughter.com/forum/uploads/gallery/album_168/gallery_1_168_53750.jpg[/img]
0

Share this post


Link to post
Share on other sites
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 [url="http://www.filmicgames.com"]John Hable's site[/url], he has some very decent articles about tonemapping and HDR-related techniques which go into quite some detail.
2

Share this post


Link to post
Share on other sites
[quote name='Radikalizm' timestamp='1345934207' post='4973352']
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 [url="http://www.filmicgames.com"]John Hable's site[/url], he has some very decent articles about tonemapping and HDR-related techniques which go into quite some detail.
[/quote]

You are a wealth of information sir! thank you
2

Share this post


Link to post
Share on other sites
[quote name='Radikalizm' timestamp='1345935064' post='4973357']
My pleasure [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
[/quote]

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

Share this post


Link to post
Share on other sites
[quote name='riuthamus' timestamp='1345937053' post='4973362']
[quote name='Radikalizm' timestamp='1345935064' post='4973357']
My pleasure [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
[/quote]

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
0

Share this post


Link to post
Share on other sites
[quote name='Radikalizm' timestamp='1345937553' post='4973365']
[quote name='riuthamus' timestamp='1345937053' post='4973362']
[quote name='Radikalizm' timestamp='1345935064' post='4973357']
My pleasure [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
[/quote]

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

Share this post


Link to post
Share on other sites
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:

[code]
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;
}
[/code]

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
0

Share this post


Link to post
Share on other sites
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...
0

Share this post


Link to post
Share on other sites
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...
0

Share this post


Link to post
Share on other sites
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!
0

Share this post


Link to post
Share on other sites
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.
1

Share this post


Link to post
Share on other sites
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?
1

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1345971949' post='4973427']
[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)[/quote]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 [i]much[/i] 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! [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] just know we got more to fix

[b]Massive Overblur:[/b]
[img]http://www.bhslaughter.com/forum/uploads/gallery/album_371/gallery_1_371_54240.jpg[/img]

[b]Normal Look:[/b]
[img]http://www.bhslaughter.com/forum/uploads/gallery/album_371/gallery_1_371_15973.jpg[/img]

[b]Slight Overblur:[/b]
[img]http://www.bhslaughter.com/forum/uploads/gallery/album_371/gallery_1_371_12084.jpg[/img] Edited by riuthamus
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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
1

Share this post


Link to post
Share on other sites
Yea I did see that on the blog and fixed it. It did indeed make it look a lot better.
1

Share this post


Link to post
Share on other sites
I just finished my implementation this morning and at the end when the color correction worked I had some issues with blur and brightness. The main ideas I got from MJPs implementation but I changed two things:
First: Sampling the luminance from the downscaled HDR texture was not acceptable for me. The average luminance difference were way too high when moving the camera through the scene. I know could change the adaption but sampling it from the whole screenspace gives smoother results too.
Second: I changed the luminance sampling code itself to the code that is provided in the DirectXSDK:
[source lang="cpp"] float3 vSample = 0.0f;
float fLogLumSum = 0.0f;

for(int iSample = 0; iSample < 9; iSample++)
{
// Compute the sum of log(luminance) throughout the sample points
vSample = tex2D(PointSampler0, PSIn.TexCoord ) +1;
fLogLumSum += log(dot(vSample, LUM_CONVERT)+0.0001f);
}

// Divide the sum to complete the average
fLogLumSum /= 9;

return float4(fLogLumSum, fLogLumSum, fLogLumSum, 1.0f);[/source]
1

Share this post


Link to post
Share on other sites
[quote name='quiSHADgho' timestamp='1346069573' post='4973756']
I just finished my implementation this morning and at the end when the color correction worked I had some issues with blur and brightness. The main ideas I got from MJPs implementation but I changed two things:
First: Sampling the luminance from the downscaled HDR texture was not acceptable for me. The average luminance difference were way too high when moving the camera through the scene. I know could change the adaption but sampling it from the whole screenspace gives smoother results too.
Second: I changed the luminance sampling code itself to the code that is provided in the DirectXSDK:
[source lang="cpp"] float3 vSample = 0.0f;
float fLogLumSum = 0.0f;

for(int iSample = 0; iSample < 9; iSample++)
{
// Compute the sum of log(luminance) throughout the sample points
vSample = tex2D(PointSampler0, PSIn.TexCoord ) +1;
fLogLumSum += log(dot(vSample, LUM_CONVERT)+0.0001f);
}

// Divide the sum to complete the average
fLogLumSum /= 9;

return float4(fLogLumSum, fLogLumSum, fLogLumSum, 1.0f);[/source]
[/quote]

Do you have a project as well? or are you just doing these things for fun? Curious is why I ask. When telanor gets up I will make sure he goes over what you have provided. Thank you again for all your help, and those who have helped previously.
0

Share this post


Link to post
Share on other sites
I have a project but not published any footage because I think it is not good enough yet and need to grow a bit more. It's a RPG and I write the engine in C# like you guys but atm I got XNA under the hood.
1

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1345971949' post='4973427']
[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)[/quote]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.
[/quote]

This is an interesting point to make, because most people would just render their skyboxes/skydomes in the albedo buffer and make it skip the lighting pass so it keeps its original color in the final render. So suppose if the sky is a blue gradient, you just leave the pixels black in the albedo buffer where the sky would be, and draw the shades of blue in the lighting pass? How would you apply sky lighting to all the objects in it? Usually, I lit everything in outdoor scenes with directional lighting. Edited by CC Ricers
1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0