HDR Method used in Splinter Cell: Chaos Theory

RTHDRIBL will only use INT16 format if FP ones aren't available.
 
Last edited by a moderator:
arrrse said:
Rthdribl, ATI HDR demos & HL2 Lost Coast all use 16bit int.
Good enough?
No. 16-bit int gives an HDR range of 256-1 at 8-bit precision. FP16 gives an HDR range of approximately 2 billion to one at 10-bit precision (note: could be a little bit off on the dynamic range depending on the exact specifications of the format, but 2 billion-1 is an absolute minimum it could be).

If you want to model real-world situations, you'll frequently be working with dynamic ranges of thousands or tens of thousands to one.
 
Sure but only if FP ones aren't available - IIRC, this means only the NV3x range will do this; everything else will be rendering into 16-bit FP surfaces.
 
Well ok then I guess I'm completely wrong.
I thought ATI needed to be using int in there (somewhere) because NV40 was the first hardware to do FP blending?
 
You can simulate blending by using two rendertargets and swapping between them every time you need to blend. This is probably fine for limited tech demos, but I doubt it's a viable alternative for gaming.
 
Last time I spoke to the author of RTHDRIBL was a good while back, so my memory isn't 100% clear on this but the rendering went along the lines of render to a FP surface, next pass sample this surface for appropriate effect; if necessary render to a new FP surface and repeat. He had mentioned that with all the effects running, the demo is taking up to 40 passes per frame.
 
Chalnoth said:
You can simulate blending by using two rendertargets and swapping between them every time you need to blend. This is probably fine for limited tech demos, but I doubt it's a viable alternative for gaming.
IMO the easiest thing to do is just do all blending after tonemapping into an 8-bit per channel buffer. It's not perfect, but it's very easy and should give 90% of the HDR look. You may want to tweak the textures of all blended objects, but it's not necessary.

This method fails most noticeably for transparent things reflecting bright light, e.g. windows and water. I guess implementing the ping-pong method for a special case like water won't be that annoying.

Man, ATI would have been so much better off if they tackled blending like NVidia. For their 16-pipe cards, knock off 8 blend units since you don't have the bandwidth anyway, and add FP blending to 4 of the remaining pipes.
 
Chalnoth said:
No. 16-bit int gives an HDR range of 256-1 at 8-bit precision. FP16 gives an HDR range of approximately 2 billion to one at 10-bit precision (note: could be a little bit off on the dynamic range depending on the exact specifications of the format, but 2 billion-1 is an absolute minimum it could be).

If you want to model real-world situations, you'll frequently be working with dynamic ranges of thousands or tens of thousands to one.

In the context of games you're unlikely to see a dynamic range anywhere near that. 256 will be more than enough for most situations. In fact, MDR (medium dynamic range) is probably enough most of the time, letting the range go up to 4 or 8 or so.
Also, by storing a range in alpha you can get pretty darn good results with RGBA16 even with extreme values.
 
Humus said:
In the context of games you're unlikely to see a dynamic range anywhere near that. 256 will be more than enough for most situations. In fact, MDR (medium dynamic range) is probably enough most of the time, letting the range go up to 4 or 8 or so.
Also, by storing a range in alpha you can get pretty darn good results with RGBA16 even with extreme values.

Can we consider that a hint as to what ATi considers necessary for "HDR" ? I get the ominous feeling of a whole new round of FP24/32 type shenanigans.
 
trinibwoy said:
Can we consider that a hint as to what ATi considers necessary for "HDR" ? I get the ominous feeling of a whole new round of FP24/32 type shenanigans.

read his sig. ;)
 
What's neccesary is up to developers. Not everyone will find that FP16 is the ultimate tool. Some will be fine with Int16, others will even settle for RGBA8 MRTs, some will go for FP32. There's more than one solution to HDR, that's all I'm saying.
 
tEd said:
read his sig.

Oh, I wish more people did. Some of you may have noticed that I'm not posting as frequently in this forum as I used to. I think most of my posts are in the General and Politics forums these days. Not because I prefer to, but because I've been misinterpreted a number of times, even after being extremely careful about how I word things.
 
Humus said:
Oh, I wish more people did. Some of you may have noticed that I'm not posting as frequently in this forum as I used to. I think most of my posts are in the General and Politics forums these days. Not because I prefer to, but because I've been misinterpreted a number of times, even after being extremely careful about how I word things.

Oh come on... that's why this forum is so much fun.

(Which is another way of saying I don't think IHV personnels need to correct (mis)interpretations by the public.)
 
Humus said:
What's neccesary is up to developers. Not everyone will find that FP16 is the ultimate tool. Some will be fine with Int16, others will even settle for RGBA8 MRTs, some will go for FP32. There's more than one solution to HDR, that's all I'm saying.

Looking at the few games that support HDR, developpers choose FP16. If the R520 will support FP16/32, ATI more or less recognises FP16/32 is the way to go for HDR.
Which is a bit in contrast to your own opinion, or is ATI forced by Nv's PR about HDR and SM3?
 
Humus said:
What's neccesary is up to developers. Not everyone will find that FP16 is the ultimate tool. Some will be fine with Int16, others will even settle for RGBA8 MRTs, some will go for FP32. There's more than one solution to HDR, that's all I'm saying.
Well, the thing is, you can get away with lower dynamic range if you're tuning your rendering algorithm for a single scene. But true HDR allows you to not have to worry about the overall light level, and just let the tonemapping pass take care of it.

For example, one of the most fantastic places in FarCry for HDR was when I was exiting a cave. I thought it caught the effect of moving from a dark area to a very bright area quite well. That's something you just can't do without either true HDR, or hardcoding the effect. I don't think it makes much sense to hardcode that sort of thing, because it'll lead to spotty implementations.
 
Humus said:
What's neccesary is up to developers. Not everyone will find that FP16 is the ultimate tool. Some will be fine with Int16, others will even settle for RGBA8 MRTs, some will go for FP32. There's more than one solution to HDR, that's all I'm saying.

A mini comparision (benchmark/ I.Q.) in my system.

HDR SM3 (16-bit floating point, openEXR format) vs HDR SM2 (16-bit integer?? 8-bit integer??)


http://www.adrenaline.com.br/forum/showpost.php?p=794117&postcount=1650


1024x768+SS+PM+HDR SM3 ->6800gt
1024x768+SS+PM+HDR SM2 (3d-Analyse 2.36b) ->6800gt


ps: See brazilian threads about you, Humus: ;)

http://www.adrenaline.com.br/forum/search.php?searchid=294532
 
Last edited by a moderator:
tEd said:
read his sig. ;)

I know he's not speaking for ATi :p But no matter what's in his sig, one can't simply completely ignore the fact that he does work at ATi and there may be influences there in both directions. Nevertheless, his comments do point to the possibility of ATi doing only what's "necessary" with respect to HDR - just like they did with FP24 shader precision for the past few generations. Can't say I'd be surprised either.
 
Back
Top