Linear tonemapping

Download Code File

The options dialog has had a couple of sliders added to it so you can easily mess around with the values and get instant feedback. To get fullscreen, open the console and type LTMFS(true); To disable fullscreen, open the console and type LTMFS(false); Sorry that's not part of the GUI, I'm not familiar enough with the TGE gui system to make that work.

Console functions added

LTMmin(minValue, correspondingMin);
LTMmax(maxValue, correspondinMax);
LTMFS(bool);

What's up with correspondingMin and correspondingMax? In most cases you'll want those to be 0.0 and 1.0 respectively. If you're adventurous though, those are the values that minValue and maxValue are decreased/increased to. I left that in there simply because it gives you a bit more control over the system.

Oh, and if you've changed SceneGraph.cc, SceneGraph.h, or SceneState.cc, then the LTM changes are noted. They're all in big blocks anyways, so it works out pretty well. Just search for Begin LTM and End LTM in those files to see what has been added.

Here is a writeup on the process. Enjoy.

How It Works
What actually happens is that the contrast of the entire scene is increased; the dark areas get darker, the lighter areas get brighter, and everything inbetween shifts to fill in the gap. This makes the scene look more vibrant and pretty. While it does produce some washing out of colors, this is unavoidable on our target range of computers. Doing spiffy effects without adjusting system requirements isn't easy.

In Depth Explanation
We use a series of quads blended in over the scene to run all the colors through a calculated linear regression. A typical regression would be :

NewColor = 2.5(OldColor) - 0.6.

This regression is applied equally on the entire RGB spectrum. However, we are dealing with a clamped range. If, after a render operation is performed, the value falls out of the 0-1 range, it is clamped to 0 or 1. This requires a very interesting little hack. We take our bias (-0.6) and divide it by our scalar (2.5) to produce a far smaller bias (-0.24). If you take a look at the graph of the equation :

y = 2.5x - 0.6

Here you will notice that all x values below 0.24 create a y value below 0. By applying our scaled bias first, we ensure that the operation runs smoothly, even though we are clamped to the 0-1 range after every calculation. So, we turn NewColor = 2.5(OldColor) - 0.6 into :

NewColor = 2.5(OldColor - 0.24)

Okay, this is great, so we can keep our spiffy calculations within the handy 0-1 range so we don't kill colors. But how exactly are we carrying this out? The first step is a subtractive blend. It is worth noting that many older cards do not support subtractive blending, and there appears to be an issue under Windows that prevents programs from setting the subtractive blending mode. The solution to this is very... interesting. We invert the colors of the entire scene (black is now white, etc.) and then add to that. Then we invert it back. For example, say our color is 0.3 (only one value for simplicity). When we invert, our value is (1-0.3) 0.7. Now we add 0.24 to that to get 0.94. When we invert again, we have 0.06 which is 0.3 - 0.24. Spiffy, no?

From there our scalar is easy. You can find some articles on how to do that with a simple google search, and I highly advise that you do, and read the articles. Older articles on graphics programming are true works of art.

Some notes to be made: You can pass in any value for either LTMmin or LTMmax. I've tested this with LTMmin being 0.9 and LTMmax being 0.9000001, which generates a linear regression of 100,000,000(color) - 90,000,000 and it's worked just fine. Furthermore, LTMmin does not have to be above 0, and LTMmax does not have to be below 1. Feel free to experiment to produce some interesting whiteout and desaturation effects.

Why didn't you just use a different blend equation?
Simple: I don't own a graphics card that supports a different blend equation.

Why not just use GL_COPY_INVERTED and save ourselves a quad?
There is a conflict with cards that support EXT_blend_ and GL_COLOR_LOGIC_OP. Basically, if we have enabled GL_COLOR_LOGIC_OP, and are blending, then it's the equivalent of having called glBlendEquation(GL_LOGIC_OP);. This doesn't work. Therefore, extra quad.

Can I use this with the TLK?
Absolutely! In fact, keep the TLK overbrighting on. It looks amazing running on top of the TLK. Thank you John for your amazing product.

Where did you get the idea for this?
I was talking to Jeff "Reno" Raab while trying to learn some stuff about rendering, and he wondered if we could do HDR in fixed function, or at least fake it. Long story short: not really. But we did get this though.

This is from an article?
Yep. That article actually contains not only this current code (though I modified it a bit, to be fair), but even contains my earlier attempts to do this. Those attempts ran at less than 1FPS. Also, look at the publication date. 1997.

Do you want feedback?
YES! Of course! My favorite kind of feedback is the type that starts with "I liked it, but...". Second favorite would be some variant of "It sucked, because..."

A couple of the screenshots have a totally different looking sky. How did you do that?
I used GL_COLOR_LOGIC_OP to invert the skybox. Give it a try. If anyone wants it, I can post the code for that too.

This kills fog horribly. What's up with that?
Fog is actually pretty bright to begin with, and almost always gets brighter with the LTM stuff. The best way around it might be to adjust the fog color by running it through a reversed set of LTM calcs. This is another area where I was lazy. Just dropping the values in the mission editor works too.

MY RETINA'S BURN! SO MUCH BRIGHT!
You'll want to increase the LTMmax value.

So dark, can't see anything, bad DooM 3 memories...
Decrease your LTMmin value.

Give me screenies!

Screen 1
Screen 2
Screen 3

This one is my personal favorite.
Shiny!

If you want more information, or want to give feedback, or wish to verbally rip my head off, then you can email me at golantrevize AT comcast DOT net.