HL2 to get HDR via steam, link

umm... are we talking about HDR or bloom effect? because they are two seperate things.

 

Just tested there is no transparency support in the demo Apple740 mentioned so basicly anything in the entire HL2 game that you can partly see through would have to be removed. Including the Hud 99% of particles ECT ECT.

Geeze wouldn't that be fun. Now also looking at the demo it also looks as it don't support INT16 framebuffers I thought the ati cards might have so basicly we are stuck with 8bit channels.

 

The HUD wouldn't be a problem: you'd just render that after the post-processing. Similarly with particles. The problem is that you won't get HDR on transparent objects, so explosions may look rather odd with HDR enabled.

 

Just wondering if you are gonna do bloom are you gonna do it before or after you do the non-HDR blend?

Since of course bloom is done in 2d space so you can't really blend it properly with a depth buffer and if you do it post you will be loosing any hotspots through transparent surfaces.

I guess you could do a reasonable 2 pass ( / 2 render targets ) hack to render 16bit int quality channels to two 8bit textures using shaders which wouldn't require higher then a 8bit blender.

You would do this by dividing the image by /256.0 place the fraction portion in one texture and the whole porting in the other. And in your post processing ( which you would like atleast one for exposure control ) value=fraction+whole*(256.0). Or something along those lines.

 

http://www.beyond3d.com/misc/hl2/

No idea what they are going to do, but they did demo Int16 HDR in Sept 2003 as a new addition to the engine then.

Here are some clarifications of what they were looking at back then (obviously things have changed since they were talking about it being included in the final game):

http://www.beyond3d.com/forum/viewtopic.php?t=8389

 

Excuse my ignorance, but what's the difference between a floating point16 render buffer and an integer16 render buffer?

 

One uses float of that take up 16 bits of space and the other uses integers.

Basicly floats are good for working over a Large range such as in High dynamic range image processing.

This is why Microsoft required float processing in pixel shaders. In the interview they say they are going to have a 0-16 range ( Just compressing what I did before from 0-256 to 0-16 which would improve the quality in the 0-1 range ) which isn't really that hdr like I think the r8500 card could do -8+8 or something in shaders so one could claim HDR lighting back then if they really wanted.

 

Or in other words, floating-point allows for many more discrete intermediate steps between the lowest and highest values that can be represented.

 

Er, well, they both allow the same number of intermediate steps (that's just a limiation set by the number of bits). The difference is that floating point has essentially equal-accuracy representation of its entire supported range, whereas fixed point/integer have higher maximal accuracy, but it drops quickly as you go to lower numbers.

 

Floats have the same number of steps BUT the step size scales with the size of the number. Generally when we render things we are most interested in the range 0-1 which floats happly represent but integers don't 0,1,2... So basicly we have to scale the ints down say using 1/256 to give it 8bit accuracy in that range 0/256,1/256... but this makes the maxium representable by a INT16 number as 256. Where as a float trades of some realtive accuracy to allow a much larger range in the case of FP16 I believe the maxium representable is like 65504 and the lowest is 0.000061( using 1/256 as the scaler the minium representation is 0.00390625 for INT16). The range is much more impressive in FP32 vs INT32.

 

Ah yes, same number of bits = same number of steps So, if the number of gradations are equal why is it that very low or high numbers are required for a broader "range" of values - that's the part I don't get. Does it just have to do with how shader math works? I've always (apparent mistakenly) thought that FP gave you more granularity.

 

Franky what it comes down to is if your blending 1 and 10000 with a 50/50 blend i.e. (1+10000)/2 and you cap your maxium value at 16 becuase your using INT16 with a range of 0-16 then your gonna get 16. If you using FP16 your atleast gonna get something in the ballpark of 5000.5.

 

More importantly, imagine you had your INT16 allow numbers up to 16384, so that you could properly do that average. But the problem is that most colors on the screen are between the 0 and 1 range. The only values that INT16 could represent if the max is clamped to 16384 are 0, 0.5, and 1.0. Needless to say, it'd be pointless to attempt something like this.

 

Well that just takes me back to my thinking that FP16 allows for more granularity than INT16 in that 0-1 range. I think I need to see some practical blending examples to fully understand the limitations of INT.

 

Well, no, not exactly. Floating point, in general allows the same granularity from 1.0 to 0.5 as it does from 0.5 to 0.25 as from 0.25 to 0.125, and similarly the same granularity between 4 and 8 and between 8 and 16, etc.

INT16, clamped between 0 and 1, well, just think about it this way: you're representing a number by dividing a number between 0 and (2^16-1) by (2^16-1). If you think about what this means, you'll note that in the larger portion of the 0-1 range, you'll have most of the bits occupied: most of them will be used. But as you approach 0, more and more bits will become insignificant (they'll just be placeholders that tell you the magnitude of the number).

If you look at the actual accuracies, since FP16 has 10 bits of mantissa, with an implied one, once INT16 has 11 or fewer significant bits it'll be less accurate. So, INT16 has more granularity on the range between 1.0 an 1/2^5 or 0.0315. Between 0.0315 and 0.0 FP16 has more granularity. Of course, if you extend the dynamic range of INT16, you'll reduce its granularity. With every factor of two you multiply your base number by, you lose a bit of granularity.