Jump to content

  • Log In with Google      Sign In   
  • Create Account


Small question about Bloom RT formats


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 lipsryme   Members   -  Reputation: 981

Like
0Likes
Like

Posted 06 September 2012 - 08:37 AM

When doing the whole bloom process do the render targets have to be FP16 like the original light accumulation target ?
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 ?

Sponsor:

#2 TiagoCosta   Crossbones+   -  Reputation: 1841

Like
0Likes
Like

Posted 06 September 2012 - 11:55 AM

There's no right way to do Bloom because it's basically an hack, so you do it anyway you want to achieve the result you want ;)

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.

Tiago Costa
Aqua Engine - my DirectX 11 game "engine" - In development

#3 CryZe   Members   -  Reputation: 768

Like
0Likes
Like

Posted 06 September 2012 - 12:43 PM

There's no right way to do Bloom because it's basically an hack

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.
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.


#4 MJP   Moderators   -  Reputation: 10086

Like
1Likes
Like

Posted 06 September 2012 - 04:22 PM

A R10G10B10A2 backbuffer won't give you any extra dynamic range, it will just give you more precision for the standard displayable range. Either way there's no guarantee that the display won't just convert it to something else when it outputs.

Edited by MJP, 06 September 2012 - 04:22 PM.


#5 swiftcoder   Senior Moderators   -  Reputation: 9507

Like
1Likes
Like

Posted 06 September 2012 - 05:29 PM

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.

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).

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]





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS