Small question about Bloom RT formats
Members - Reputation: 985
Posted 06 September 2012 - 08:37 AM
Do I perform the brightpass and gaussian blur with FP16 format buffer ?
I realize I need to keep it in HDR until the tonemapping is performed, right ?
Crossbones+ - Reputation: 1864
Posted 06 September 2012 - 11:55 AM
In my opinion using FP16 render targets in the bright/blur passes produces better results because you might get some color information during the blur that would be clipped in the bright pass if you used 8-bit render targets.
Edited by TiagoCosta, 06 September 2012 - 11:57 AM.
Aqua Engine - my DirectX 11 game "engine" - In development
Members - Reputation: 768
Posted 06 September 2012 - 12:43 PM
Bloom is no hack. It's actually just a part of the flares lenses produce. Because no glass is perfect a really small amount of light always gets refracted onto nearby pixels. Normal distribution (aka gaussian filter) doesn't produce the most physically correct results though. An exponential distribution is better suited for Bloom, but it's not separable thus being not well suited for a realtime application. You can approximate an exponential distribution by using multiple gaussians though which is what they are doing in CryEngine 3 and Unreal Engine 4.
There's no right way to do Bloom because it's basically an hack
Also it doesn't really make any sense to implement a bright pass to subtract a certain amount of light so that only the bright light gets blurred. That's often a sign that the engine is not actually High Dynamic Range. Light always scatters onto surrounding pixels, just a tiny amount of it, but it's completely independent of its brightness. So a proper exponential filter and maybe a multiplicative factor should be about it.
BTT: If you want to have High Dynamic Range Rendering, you should keep the Bloom in High Dynamic Range and later perform Tone Mapping to resolve it to Low Dynamic Range. Also there's no need for an actual bright pass. Just do that in the Bloom Pass to save Bandwidth.
Also a cool trick is to use a R10G10B10A2 resource as a backbuffer. Most monitors can actually display this when the application runs in full screen. So you can actually have a higher dynamic range than the usual B8G8R8A8 backbuffer.
Edited by CryZe, 06 September 2012 - 12:59 PM.
Moderators - Reputation: 10223
Posted 06 September 2012 - 04:22 PM
Edited by MJP, 06 September 2012 - 04:22 PM.
Senior Moderators - Reputation: 9584
Posted 06 September 2012 - 05:29 PM
Most consumer monitors (cheap TN and IPS panels) have 6-bit colour depth, and achieve 8-bit equivalence via dithering. Even mid-range IPS panels are only 8-bit (plus 2-bit dither).
Also a cool trick is to use a R10G10B10A2 resource as a backbuffer. Most monitors can actually display this when the application runs in full screen.
Basically, if you are spending less than $1,000 per monitor, you aren't getting a truly 10-bit panel. And even in the over $1,000 range, you have to be pretty selective to find the panels specifically aimed at graphics professionals.
And that's ignoring the fact that a DVI cable only carries 8-bit colour, so you are limited to monitors that offer DisplayPort or full HDMI 1.3 support (and a graphics card to match)...
Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]