• 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
cifa

HDR ToneMapping: Exposure selection

1 post in this topic

Hi everyone!

 

I've been trying adding HDR support to my system but I got a couple of questions. I believe what I'm doing before  tone-mapping is fine: 

 

- Setup a RGBA16F Render Target

- Render to that RT

- call the postprocessing tone mapping on the cited RT and display the result on screen. 

 

 

Now to test this I've cranked up a bit my light intensity: 

 

jzHh4q5.png

 

Now if I apply the following tone mapping function (either one, the result is similar)

	col *= exposure;
	col = max(vec3(0.0), col -0.004);
	col = (col *(6.2*col + 0.5)) / (col *(6.2*col +1.7)+0.06);
	return vec4(col ,1.0)

or 

	col *= exposure;
	col = col / (1+col);
	return vec4(col, 1.0);

if the exposure is more than 0.5 for the above image and previous functions the result is pretty flat:

 

7eM68eY.png

 

Where for an exposure value of about 0.4 the result is ok: 

 

QoX5F2O.png

 

Although it's very darkish (unsurprisingly as the exposure is pretty low). 

 

Now the same issue (flatness of the tone-mapped image) is there for a "normal" light intensity which is fine even without using HDR. To get a decent result I have to lower the exposure even for that case, resulting though, again, in a darkish image. 

 

My questions are then two: 

 

- Am I missing something important here? I feel that the result I get is somewhat wrong

- Is there a way to "automatically" select what's considered a good exposure value for a given scene? 

 

 

 

Thank you very much

1

Share this post


Link to post
Share on other sites

- Is there a way to "automatically" select what's considered a good exposure value for a given scene?

 

Indeed, there is. Auto-exposure requires a few additional steps and probably even a different tonemapping-algorithm. It works like this:

 

- Take the scene-rendertarget and calculate the geometric luminance per pixel, save this in another render target.

 

- Sum up this geometric luminance to get the average scene luminance. This can be eigther done in a compute shader (complicated but best in performance if done right), by repeaded downsampling to half size & summing up 4 pixels per step until you hit 1x1-texture (easiest to do), or automatically computing the lowest possible mipmap-level for the luminance texture (not recommended, since you require a card that implements linear filtering for mipmap-generation in order for this to produce correct values - it didn't for me).

 

- You can additionally add another step and blend between the current and last luminance value by ping-ponging between two render-targets for the average luminance, this will produce the effect of adaptation, where if you e.g. come from a dark room it will take some time for your eyes to adapt to the brighter environment. But thats entirely optional.

 

- In the last step, perform tonemapping using the average-luminance-value you got. I don't know for sure if you just use this as the exposure value, I'll just show you the shaders I'm using, I believe I implemented some modification of the reinhard-tonemapping:

vertexShader(SCREEN)

pixelShader
{
	textures
	{
		2D AvgLuminance;
		2D Image;
	}
	
	out
	{
		float4 vColor;
	}
	
	main
	{
		float BarLw = Sample(AvgLuminance, float2(0.5, 0.5));
		float aOverBarLw = 0.18f * (1.0f/exp(BarLw));
		
		float3 hdrPixel = Sample(Image, in.vTex0).rgb;
		float lumi = dot( hdrPixel, float3( 0.2126, 0.7152, 0.0722 ));
		float Lxy = aOverBarLw * lumi;
		
		float numer = (1 + (Lxy * 4.0)) * Lxy;
		float denum = 1 + Lxy;
		float Ld = numer / denum;
		
		float3 ldrPixel = (hdrPixel / lumi) * Ld;
		
		out.vColor = float4(pow(ldrPixel, float3(1/2.2f)), 1.0f);
	}
}

Its in my own shading meta language, though the code in the "main"-block is basically HLSL. There is still a few tunable "magic" numbers like the 4.0f, I don't remember exactly what it does (magic numbers sure ARE evil) but lower value results in overall less bright scene so on top of automatic exposure selection you can still tune the overall look of the scene. This is the tonemapping-shader itself. To convert the scene to geometric luminance, you do:

vertexShader(SCREEN)

pixelShader
{
	textures
	{
		2D Scene;
	}
	
	out
	{
		float4 vColor;
	}
	
	main
	{
		float3 lightTransport = Sample(Scene, in.vTex0).rgb;
	
		//convert to luminance
		float lum = dot(lightTransport, float3( 0.2126, 0.7152, 0.0722 ));

		out.vColor = float4(max(0.0f, log(0.001 + lum)), 0.0f, 0.0f, 1.0f);
	}
}

Also, make sure you account for gamma correction. This basically means doing pow(color, 2.2) before making your lighting calculations on about everything on screen, as you can see when converting the HDR-range to LDR range I undo this by doing pow(pixel, 1/2.2) (though maybe not entirely logical at first, this will produce entirely different (read : better) results, in fact before doing so my HDR looked really crappy and I ended up using a broken version because it looked way better).

 

EDIT: Take high note that with this auto-exposure algorithm your face will look way too bright in the beginning since your screen is entirely black. So eigther fake some semi-bright value for the black pixels in the shader or fill up your background with something (read: do something that your black pixels won't account for average luminance calculation).

 

Also, I got this algorithm (with exception of the tonemapping) from Nvidias 9 SDK, see the "HDR Deferred Shading"-Sample for theory & implementation.

Edited by Juliean
0

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