oeLangOetan
Newcomer
any proof to back that up?bigz said:I believe they are using a 16-bit integer buffer for the primary render target.
any proof to back that up?bigz said:I believe they are using a 16-bit integer buffer for the primary render target.
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).arrrse said:Rthdribl, ATI HDR demos & HL2 Lost Coast all use 16bit int.
Good enough?
But it renders to an int16 buffer though doesn't it?RTHDRIBL will only use INT16 format if FP ones aren't available.
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.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.
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.
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.
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.
tEd said:read his sig.
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.
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.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.
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.
tEd said:read his sig.