Sign in to follow this  
Qatal

HDR done cheap?

Recommended Posts

Hi Just been working on some HDR code, and I reckon you can reduce the fillrate hit of HDR to almost nothing. Instead of using a floating-point framebuffer and then tone-mapping that, why don't we just make use of the TC between frames, and use last frame's tonemapping multiplier, premultiplying the output color of a shader, before you write it to the framebuffer. I know you lose some of the bloom capability this way, but you do get pretty decent HDR itself.... -Chris

Share this post


Link to post
Share on other sites
Quote:
Original post by Qatal
Instead of using a floating-point framebuffer and then tone-mapping that, why don't we just make use of the TC between frames, and use last frame's tonemapping multiplier, premultiplying the output color of a shader, before you write it to the framebuffer.

"the TC between frames" - TC?

I'm not sure I get it entirely, but this sounds a bit like the "hacked" way of doing HDRI with a simple 32bit render target and using Alpha as luminance.

You got any screenshots or performance statistics as comparisons?

Share this post


Link to post
Share on other sites
Yeah, it's a bit of a hack, but my r9600pro doesnt quite have the juice to do true HDR along with all the other stuff my renderer needs.

TC = temporal coherence

So you tonemap each frame using the last frame's data

I will upload some performance measurements and screenshots in the next few days, once i have tweaked it a bit more, although at present, i've got something like a 3x framerate boost on this card. big-format RTs just eat up the fillrate.

(i have one of the 'crippled' r9600pro cards with 256mb of really slow RAM...)


-Chris

Share this post


Link to post
Share on other sites
Quote:
TC = temporal coherence

So you tonemap each frame using the last frame's data

Ah right, I'm with you now.

Sounds like a perfectly reasonable approximation/optimization for the hardware that can't do it "properly".

Quote:
I will upload some performance measurements and screenshots in the next few days, once i have tweaked it a bit more, although at present, i've got something like a 3x framerate boost on this card. big-format RTs just eat up the fillrate.

I'd like to see this.

I'm doing the groundwork for some HDRI stuff, and whilst I have the beefy Gf6800's to handle my requirements, its always interesting to write up/discuss any possible ways that it could be downgraded for more common hardware.

Cheers,
Jack

Share this post


Link to post
Share on other sites
Eh? A 9600 Pro doesn't have the oomph? Surely there isn't that much difference between that, and my 9600 XT? Mine takes anything I throw at it and spits it back at 1280x960x32 no problem... just how much strain are you putting yours under?

Edit: (nevermind, just saw your parens; definitely a difference between what is essentially ATI's GeForce4 MX (really a GeFr2 in disguise) and my High-End-GeForce4-equivalent).

Share this post


Link to post
Share on other sites
Yeah it's just the RAM on this thing that sucks. TSOPs, no cooling, won't clock above 400 MHz (ddr), wheras my *other* 9600, (which died a horrible death due to overheating), had the RAM ticking along at 650MHz fine.

Will get you guys some pictures in the next couple days hopefully :)

Share this post


Link to post
Share on other sites
Quote:
Original post by jollyjeffers
I'm not sure I get it entirely, but this sounds a bit like the "hacked" way of doing HDRI with a simple 32bit render target and using Alpha as luminance.
Are you referring to the glow effect? The glow effect isn't the same thing as HDR, it's just the most noticable aspect of it. Unless there's some other way of doing full tone mapping &c without using floating point render targets...

Share this post


Link to post
Share on other sites
Qatal,
How are you going to compute the tonemapping multiplier without using floating point buffers? I mean how is last frames result computed in the first place?
It sounds a little like your would do the computation of the tonemapping multiplier over several frames instead of just one, but maybe that's not the case. Anyway I don't think your technique would work with mutltipass rendering.

Share this post


Link to post
Share on other sites
Quote:
Original post by superpig
Quote:
Original post by jollyjeffers
I'm not sure I get it entirely, but this sounds a bit like the "hacked" way of doing HDRI with a simple 32bit render target and using Alpha as luminance.
Are you referring to the glow effect? The glow effect isn't the same thing as HDR, it's just the most noticable aspect of it. Unless there's some other way of doing full tone mapping &c without using floating point render targets...

Yes, thats the thing I was thinking of - I thought you could "fake" more than just the bloom/glow HDRI effects. In particular, I thought it was also popular with this method do luminance map based in a similar way.

I've only read about it, never actually tried it, so it's quite possible I'm wrong [embarrass]

Share this post


Link to post
Share on other sites
Hi

The tonemapping multiplier is obtained from the luminance of the last frame.

The luminance is currently being encoded in an [unscaled] alpha channel.
I may end up using MRT support on the r9500+ to render the luminance into a single 32bit float channel.

It works fine for multipass, why would you think it wouldnt?

Share this post


Link to post
Share on other sites
OK bare with me cause I haven't implemented HDR myself so I'm just speculating here. My main concern is with algorithms that require some post processing of the framebuffer (bloom as you mentioned) which is what is was thinking of wrt to multipass.

In case of the standard multipass lighting technique where each pass adds some light contributions and the last pass modultes the albedo with the framebuffer. Now if lighting values are saturated this result in errors since you will always be modulating with 255 instead of what the HDR value should have been.

As I'm writing this I see that you could actually modulate each light contribution with the albedo texture in the shader, but I'm not sure how that would work out performance wise. It seems like there could be other cases where saturation in the framebuffer would be a problem?

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