Some new interesting information about valve's HDR implementation
- Thread starter tEd
- Start date
I was more thinking along the lines of encoding a monochrome high-range/low-precision version of the rgb-value in the alpha-channel and using it only for bloom. The range aspects besides bloom would be taken care of by scaling brightness in the shader depending on the desired exposure. Well it isn't perfect, but then again it would be quite suprising if valve's solution were.
I've read the Valve/HDR article over at DH: http://www.driverheaven.net/articles/ValveHDR/index.htm (it's really a nice read)
In one of the presentations slides it says using fp16 texture when filtering is supported and 4.12 otherwise as already mentioned in this thread.
R520 won't support fp16 filtering that means it won't be using the fp16 path in valves implementation right? That would of course be a little unforunate as r520 supports fp16 blending and even AA with fp16 render targets and still couldn't use the fp16 path because of the lack of fp16 filtering.
In one of the presentations slides it says using fp16 texture when filtering is supported and 4.12 otherwise as already mentioned in this thread.
R520 won't support fp16 filtering that means it won't be using the fp16 path in valves implementation right? That would of course be a little unforunate as r520 supports fp16 blending and even AA with fp16 render targets and still couldn't use the fp16 path because of the lack of fp16 filtering.
sRGB is "single" RGB, some sort of standard
http://www.w3.org/Graphics/Color/sRGB
But actually, RGB really doesn't present linear color space as light frequences behave non-linearly. Of course, such definition is a bit missleading.
http://www.w3.org/Graphics/Color/sRGB
But actually, RGB really doesn't present linear color space as light frequences behave non-linearly. Of course, such definition is a bit missleading.
Last edited by a moderator:
Chalnoth said:
Actually such rendertarget is exposed on X800's. I don't have any R3xx around to check out, but I have some vague memories of it being present in there, too. More correct statement here is that you cannot use 10:10:10:2 as backbuffer format.
Edit: forget it, missed the reply above
Why not just do:
It'd be slow, and you couldn't ever use simple blending (you'd have to decode the framebuffer for every blend), but you would get full HDR. If your pixel shaders are typically long, it might not be so bad, though you'd get pretty poor performance for simple operations that require many blends, like particle effects and foliage.
edit:
Heh, looks like bloodbob deleted the post this is in reply to
Code:
float4 output; // what would be the output of the old pixel shader
float4 outputs[2];
float4 exp;
........ // old code goes here
exp = int(log2(output));
outputs[0]=(exp + 128)/256;
outputs[1]=frac(output/pow(2,exp);
return outputs;It'd be slow, and you couldn't ever use simple blending (you'd have to decode the framebuffer for every blend), but you would get full HDR. If your pixel shaders are typically long, it might not be so bad, though you'd get pretty poor performance for simple operations that require many blends, like particle effects and foliage.
edit:
Heh, looks like bloodbob deleted the post this is in reply to
Chalnoth said:It'd be slow, and you couldn't ever use simple blending (you'd have to decode the framebuffer for every blend), but you would get full HDR.
Heh, looks like bloodbob deleted the post this is in reply to
Yeah cause you might as well do FP16.
Obivously Valves 2nd implementation wasn't HDR. Frankly looking at the implementation notes I have no idea what they are doing as there is still all this carry on about MRT yet valve says they aren't using over-bright data so what are they doing with MRT?
I'll repost the best idea I can come up with.
Code:
// its a bit different cause I'm ignore the 4.12 stuff if your tone maping
// linearly on the fly low values generally don't matter that much as your
// most likely only interested in very bright values for alphas < 1.0 and bloom
float4 tonemappingconstant=somevalue; // a pre pass is done to get a tone mapping estimate
output=oldshaderoutput;
float4 outputs[2];
outputs[0]=frac( (output/tonemappingconstant)*256.0 );
outputs[1]=output-outputs[0]/256.0;
return outputs;
Last edited by a moderator:
Oh, and it seems like any solution that uses MRT's would require blending support for MRT's. Does current hardware support blending with MRT's? Doesn't seem like a trivial thing to support.
On the other hand, Valve could just be rendering the scene twice, first storing the normal component, then storing an overbright component in a separate texture, combining the two for the final pass.
Edit:
And storing the framebuffer in two parts like that would likely have huge problems with blending for values just above 1, unless you also decoded the framebuffer just like you'd have to do with the soft-FP thing I put up above. After all, a value of 1.01 blended with 0.99 would blend to 0.5 if you just do a straight blend with that encoding.
On the other hand, Valve could just be rendering the scene twice, first storing the normal component, then storing an overbright component in a separate texture, combining the two for the final pass.
Edit:
And storing the framebuffer in two parts like that would likely have huge problems with blending for values just above 1, unless you also decoded the framebuffer just like you'd have to do with the soft-FP thing I put up above. After all, a value of 1.01 blended with 0.99 would blend to 0.5 if you just do a straight blend with that encoding.
It can be worked around by lower the over-bright buffer. So your over bright buffer only worked between 16 and 1/16 that way if you blend 1.01 and 0.99 you get 0.5 ( [0.01+0.99]/2 ) in the LDR buffer and 0.5 ( [1.0 + 0.0]/2 ) in the Over bright buffer and on your final pass you add them to getter and get 1.0.Chalnoth said:
But yeah there is no good proper way without hacks ect to get real HDR quickly using INT buffers whatever valve is doing ain't HDR. Overlapping frame buffers really isn't a good solution.
Last edited by a moderator:
Well as many bits as you want ( I actually said 4 bits in the post just above ) so you get proper trunaction. Yeah it would drop the dynamic range then again we are only using 0.0-16.0 range with the texture in the first place and we don't really particularly care about the lower end of the range if your pre tone mapping. But yeah frankly I can't really see anyone using this. ( you could always use a 3rd MRT though this would hurt fillrate and mem bandwidth and memory )Chalnoth said:
Yeah but if your encoding data in the alpha channel how are you supposed to do alpha blends. In importance I rank things in the following Alpha Blend > texture filtering ( you can emulate blinear easily enough using shaders ) > HDR > AA.vember said:
Last edited by a moderator:
bloodbob said:
By setting the blend operation flags differently depending on if your alpha-blending or not. The limitation is that you cant have surfaces that are both alpha-blended and bloom sources at the same time. The alpha-blended surfaces does obstruct blooms just fine however. I do however do my exposure-scaling in the pixelshader, so the alpha channel is only used for bloom.
I've got a working implementation now btw so it's no longer hypothetical unlike my previous posts.
Ehh the alpha blend surfaces aren't supposed to obstruct a bloom (well not in HDR). I could be wrong but when you alphablend with an alpha value of say 0.9 isn't 0.9 written to the frame buffer? If so then when you read the alpha value out of the frame buffer isn't it going to be 0.9? Won't such a high number bloom even if the pixel are a really low value ( such as blending black box with 10% transparency ).vember said:
Last edited by a moderator: