HDR Issues and fixes (Log problems here)

#21 Yeah, I figured you 'got it'. Sometimes I add stuff to posts just so it's public and EVERYONE get the right ideas. I mean besides a HUGE lack of documentation, the lack of CORRECT information is a problem :-). Anyway, I too will get back to this issue in time. You have my email. Keep in touch.

Oh yeah, I feel your pain, my main 'development engine' has VERY little to do with T3D at this point. LOL!

Ron

#22 Just a note to everyone following along. HDR In the engine currently works by selecting the smallest format available to the hardware that will support it. Example: R10G10B10A2, R16G16B16A16F, R16G16B16A16. So if your hardware supports the first mode, it's selected and never gets to the full 64bit mode.

I'm assuming it's setup this way to handle other platforms, quickly as not all platforms are created equal nor can support full 64bit texture modes to do this effect in. Which isn't a bad thing, it's just a decision that was made.

Honestly, I want to hear input from the community here.. I've reordered these in my build (since I only care about PC at the moment), but for the stock engine, this should at least be able to be overridden in the base client configuration scripts.

#23 Hey smally,

Check this out: www.garagegames.com/community/blogs/view/22349

Seems SSDO is actually a far more efficient and viable solution (based on my testing.) Thoughts?

Ron

#24 SSDO Is something I was looking at, though it seriously depends on the implementation. Examples:

This one is sort of based on SSDO and their calling it DSSDO
kayru.org/articles/dssdo/

and www.mpi-inf.mpg.de/~ritschel/Papers/SSDO.pdf
The latter being the best implementation I've ever seen for this, though it is also the slowest but also looks the best.

The reason I didn't settle on this one completely is because it's view dependent. I do like it though, a lot. It still looks good and as long as optimization occurs it's definitely more than enough.

[Update]
I just checked your entry on that. I guess you already have the link to that paper, lol. Looks very decent! Quite a bit more than acceptable bud!

#25 Okay this will be sort of lengthy, but if anyone has input PLEASE INPUT. I don't care if you can do any of the implementation, just leave input. The shader effect for HDR deals with luminance, exposure correction, tonemapping, bloom, color correction, gamma correction, blue shift (I may be leaving one more out).

Current Actual issues on the HDR in the engine:

• Bloom happens AFTER lens flare effects are rendered. This needs to be fixed. This is a rather large change in the way lens effects are rendered. Instead of every light immediately rendering their flare, they would be collected into a bin to render to their own full screen buffer. Anyone have any objections to this? Reason I'm choosing a full screen buffer for this is for post process flare effects can be added to this target and then it's all applied after bloom.
• Specular suffers because of a few issues which, when combined cause a larger issue.
• Some may want to see HDR Texture support (not sure if this is there already and can't seem to find it if it is at the moment)

The Actual portion of the engine that sets up the buffer for HDR is more than fine. Nothing wrong there. Could be customized but the formats there are fine, and the ordering was most likely for mass hardware support and performance. As in less people had the ability to render A16FR16FG16FB16F than A2R10G10B10. As of today A16FR16FG16FB16F is fine, but that truly depends on the market segment of the players your going after. Also depends on if you want to sacrifice some performance for that format or not as well.

If anyone is interested, this is what the process generally looks like in games:

• Sample Luminance of scene
• Extract bloom areas
• Perform Exposure Correction, get current exposure and use on current frame
• Perform blue shift
• Tonemap
• Perform Bloom
• Render Effects (Light flares, stars, horizontal glares, etc)
• Perform color correction
• Perform gamma correction

Most of these are ordered as a matter of taste. Some games do tonemapping first, others do bloom first and some save tonemapping for after the render effects. There seriously isn't really a right answer.

The goal is to get an attractive image, doesn't have to be physically accurate, and it's not. So this is usually something that is generally up to the game developer / artists to decide.

There are a lot of effects that get stuffed into the HDR Bag, when in reality HDR is just the process of setting up the relevant image format and maths required to output according to the high light range desired.
So simply, the actual HDR of the engine is actually Ok. It's everything else on top of that, that has it's own issues here and there.

I know there is an open ticket for the engine not seeing the sun as bright but, that's a function of your exposure control. This should at most be a flag for the algorithm to make the control understand the user wants the scene to darken around the bright object. Some games will not want that functionality.

I've already implemented filmic tonemapping, and it makes a complete difference but you almost have to redo your lights to make it worth it. Not hard just time consuming making sure it's correct and it's not something you probably want to use all the time. Just an additional form of tonemapping. I'll post some pics of that here soon once I get a good demo level going for this. Right now I'm just working on a couple of larger, somewhat barren scenes.

If your interested in seeing fixes, let me know what it is your looking for or at.. Otherwise I have nothing else to go on besides what I think should be there. So please, speak up now.