[ZZ] Deferred Rendering and HDR

Except that it means that you need to ping-pong your texture for every light that you render... and you can‘t batch up lights into one DP... and you need to worry about copying at least the affected part of the texture into the second ping-ponged texture every time you render a light...

In short it‘s rather impractical to do it manually for a scene with complex lighting. If you mean to target GPUs without fp16 blending, you‘re going to want to look at an alternate HDR representation, such as Valve‘s post-tone-mapped RT stuff (sacrifices a lot of flexibility in your tone mapping unfortunately), or potentially some of the alternate colour space stuff like LogLUV or similar.

lol that‘s some hack tastic HDR there valve :P

Damn XNA+XBOX 360 not having FP alpha!!!

EDIT: It does support 10.10.10.2 with alpha though. I was looking through HDR_The_Bungie_Way.ppt and they found that the 360‘s 10.10.10.2, which is 7e3, doesn‘t give enough exposure:

Quote:

10-bit floating point formats.

The XBOX 360 has full support for the 7e3 format (7 bits mantissa, 3 bits exponent), which is the dark purple curve.
7e3 has more than enough precision, but only gives you about 3 stops of exposure range – it’s well into the banding region with the 5 stop headroom here.

Another alternative, not supported by XBOX 360 but possibly showing up on PC hardware soon, is 6e4.
This format has just enough precision, as it is barely poking above the visual curve. But it gives you a full 10 stops of exposure range.

DX10 will support 6e5 I believe, with 5e5 for the blue channel. It is difficult to say if 5 bits is enough for the blue channel – this visual curve I measured was monochrome values, for which 5 bits will exhibit some banding. The blue channel, however, might require less precision.

I might just try it for the hell of it to see if my scene has banding.

EDIT AGAIN:

Oh and I was looking into the other techniques where you store a brightness in the alpha channel: http://www.daionet.gr.jp/~masa/archives/GDC2003_DSTEAL.ppt

but of course you can‘t alpha blend that :P

So it seems like 10.10.10.2 is the only option I can find for deferred with tons of lights on the 360.

0Likes1Likes

Posted 06 June 2008 - 09:32 AM

Quote:

Original post by jstroh
Damn XNA+XBOX 360 not having FP alpha!!!

EDIT: It does support 10.10.10.2 with alpha though. I was looking through HDR_The_Bungie_Way.ppt and they found that the 360‘s 10.10.10.2, which is 7e3, doesn‘t give enough exposure:

Be careful: you‘re talking about 2 different surface formats here. XNA supports regular A2R10G10B10, which is a fixed-point format with some extra precision (everything will still be normalized to the range [0,1]). The format Bungie is talking about, which uses floating-point components, is not accessible through XNA. The reason why is because this format is unique to the 360, and has some interesting quirks about it‘s usage (the format only exists in the 360‘s eDRAM backbuffer, when it‘s resolved it‘s copied out to main memory as full fp16).

Because of that, the HDR situation on 360 through XNA basically sucks. You can use fp16, but you get two wonderful problems along with it:

-Backbuffer size is doubled, which means you have to tile even without MSAA
-No alpha-blending

So you‘re stuck with those problems, doing something with alternate color spaces, or using the Valve method. Not great options, IMO. I‘ve been wrestling with these issues myself over the past few weeks, and I think I‘m just going to bite the bullet and go with fp16 on both 360 and PC. I‘m using a forward renderer so at least I don‘t have to worry about batching lights, but any alpha-blended geometry is going to be a pain.

I actually brought up the issue over at Connect, and they basically said they‘re not looking into giving access to the fp10 format. I understand it creates some inconsistency they don‘t want across the PC and 360 platforms, but it‘s really frustating not having access to one of the 360‘s unique advantages.

- 11:02 AM

Quote:

Original post by jstroh
Do you think removing light batching would eliminate the speed benefit of deferred? hmmm

Depends how many lights you have, but if you have enough lights that deferred is faster than forward for you, you‘ll probably have trouble with the number of ping-pongs and copies you have to do to implement the manual blending. Feel free to try it out though and see.