Comments on: Another day, another HDR rendering trick and some hope for the future. http://pixelstoomany.wordpress.com/2008/07/05/another-day-another-hdr-rendering-trick-and-some-hope-for-the-future/ Mon, 12 Oct 2009 22:17:15 +0000 http://wordpress.com/ hourly 1 By: chris green http://pixelstoomany.wordpress.com/2008/07/05/another-day-another-hdr-rendering-trick-and-some-hope-for-the-future/#comment-144 chris green Sat, 12 Jul 2008 22:08:59 +0000 http://pixelstoomany.wordpress.com/?p=19#comment-144 .. and yet another thing we tried in lost coast was using two eight bit render targets as MRT's. All shaders would write both (r,g,b) and (1/16)*(r,g,b) into the two render targets. A final shader would combine the two frame buffers at a target exposure value, including hdr blooming. This would work on hardware which supported mrts but didn't fully support high-bit render targets (ATI at the time). Of course, MSAA was also the drawback with this approach. .. and yet another thing we tried in lost coast was using two eight bit render targets as MRT’s. All shaders would write both (r,g,b) and (1/16)*(r,g,b) into the two render targets. A final shader would combine the two frame buffers at a target exposure value, including hdr blooming.

This would work on hardware which supported mrts but didn’t fully support high-bit render targets (ATI at the time). Of course, MSAA was also the drawback with this approach.

]]> By: Marco Salvi http://pixelstoomany.wordpress.com/2008/07/05/another-day-another-hdr-rendering-trick-and-some-hope-for-the-future/#comment-143 Marco Salvi Wed, 09 Jul 2008 14:20:08 +0000 http://pixelstoomany.wordpress.com/?p=19#comment-143 Hi Gary, Thanks for your post! Ultimately we had the same concerns for Heavenly Sword, it wasn't possible to adopt the idea I came up with because it was clashing with other 'creative' uses of various render targets and obscure hardware features. It's a kind of route one has to take in early development stages. I found myself in this situation so many times, it's definitely a recurring pattern according my personal experience. That's why I'm looking forward to the second (or the third?) coming of software renderers that should allows us to develop more creative and exotic solutions that are also more robust and less hacky.. Hi Gary,
Thanks for your post!

Ultimately we had the same concerns for Heavenly Sword, it wasn’t possible to adopt the idea I came up with because it was clashing with other ‘creative’ uses of various render targets and obscure hardware features. It’s a kind of route one has to take in early development stages.

I found myself in this situation so many times, it’s definitely a recurring pattern according my personal experience. That’s why I’m looking forward to the second (or the third?) coming of software renderers that should allows us to develop more creative and exotic solutions that are also more robust and less hacky..

]]> By: Gary McTaggart http://pixelstoomany.wordpress.com/2008/07/05/another-day-another-hdr-rendering-trick-and-some-hope-for-the-future/#comment-142 Gary McTaggart Tue, 08 Jul 2008 06:47:38 +0000 http://pixelstoomany.wordpress.com/?p=19#comment-142 One of the things that we tried before settling on what we have for Lost Coast is to store another range in another render target via MRT. Worked well, except for killing MSAA. We couldn't afford to render again to get the other range, which is what I beieve Halo 3 ended up doing. We also tried storing various flavors of luminance in dest alpha, but aborted on that due to problems with alpha-blending. If the blend units were a bit more general with respect to what happens with alpha, it would have been a nice solution. It also didn't help that we were already using dest alpha for refraction factors for water, etc. I wish we had been able to end up with HDR data for blooming when using LDR render targets, but we thought what we ended up with wa a reasonable compromise. One of the things that we tried before settling on what we have for Lost Coast is to store another range in another render target via MRT. Worked well, except for killing MSAA. We couldn’t afford to render again to get the other range, which is what I beieve Halo 3 ended up doing.

We also tried storing various flavors of luminance in dest alpha, but aborted on that due to problems with alpha-blending. If the blend units were a bit more general with respect to what happens with alpha, it would have been a nice solution. It also didn’t help that we were already using dest alpha for refraction factors for water, etc.

I wish we had been able to end up with HDR data for blooming when using LDR render targets, but we thought what we ended up with wa a reasonable compromise.

]]> By: Marco Salvi http://pixelstoomany.wordpress.com/2008/07/05/another-day-another-hdr-rendering-trick-and-some-hope-for-the-future/#comment-141 Marco Salvi Sun, 06 Jul 2008 16:44:03 +0000 http://pixelstoomany.wordpress.com/?p=19#comment-141 Thanks Vincent! I also tried to use this approach in the late Heavenly Sword development stages and well, it was simply too late to make it work properly with the rest of our pipeline, I battled with a few days and then I had to abandon it (though it was only 2-3% faster than my logluv framebuffer encoding technique, it had the advantage of resolving our 4x MSAA HDR frame buffer in the proper order giving to the image an outstanding quality in high contrast areas) My other major problem with Valve's HDR technique is that if your renderer is gamma aware (and if it's not it's better go back to the drawing board!) and it performs shading in a linear RGB space you also need to apply gamma correction before writing out your tone mapped pixels. This is not a big problem per se (and some next gen console out there does it for free) but it might be a problem if you need to composite your opaque pixels with other layers or special effects. In theory your single pass material should also perform tone mapping, colour correction, DOF, motion blur, lens flares, gamma writes and all sort of stuff. DOF and motion blur can't be obviously done at that stage so you have to sacrifice again some correctness. Trying to add some full screen passes for special effects and to move gamma correction at the end of the rendering pipeline won't work as you already tone mapped your fragments out to a 4 bytes per pixel render target which doesn't have enough dynamic range to avoid awful banding introduced by gamma correction (well, that's the reason why some clever clog invented gamma encoding in the first place!). Thanks Vincent!
I also tried to use this approach in the late Heavenly Sword development stages and well, it was simply too late to make it work properly with the rest of our pipeline, I battled with a few days and then I had to abandon it (though it was only 2-3% faster than my logluv framebuffer encoding technique, it had the advantage of resolving our 4x MSAA HDR frame buffer in the proper order giving to the image an outstanding quality in high contrast areas)
My other major problem with Valve’s HDR technique is that if your renderer is gamma aware (and if it’s not it’s better go back to the drawing board!) and it performs shading in a linear RGB space you also need to apply gamma correction before writing out your tone mapped pixels. This is not a big problem per se (and some next gen console out there does it for free) but it might be a problem if you need to composite your opaque pixels with other layers or special effects.
In theory your single pass material should also perform tone mapping, colour correction, DOF, motion blur, lens flares, gamma writes and all sort of stuff. DOF and motion blur can’t be obviously done at that stage so you have to sacrifice again some correctness. Trying to add some full screen passes for special effects and to move gamma correction at the end of the rendering pipeline won’t work as you already tone mapped your fragments out to a 4 bytes per pixel render target which doesn’t have enough dynamic range to avoid awful banding introduced by gamma correction (well, that’s the reason why some clever clog invented gamma encoding in the first place!).

]]> By: Vincent Scheib http://pixelstoomany.wordpress.com/2008/07/05/another-day-another-hdr-rendering-trick-and-some-hope-for-the-future/#comment-140 Vincent Scheib Sun, 06 Jul 2008 13:38:56 +0000 http://pixelstoomany.wordpress.com/?p=19#comment-140 Marco, this is a great idea. I've been considering giving the Valve technique a try and was lamenting the more involved process of exposure measuring. I'd like to experiement with this approach. Marco, this is a great idea. I’ve been considering giving the Valve technique a try and was lamenting the more involved process of exposure measuring. I’d like to experiement with this approach.

]]>