New HDR demo

[bloodbob]

I was just able to reproduce it myself. It seems to be resolution dependent, but couldn't figure out the exact pattern. Also, it seems to be fixed in recent driver builds, but not yet gone public.

Ahh good to hear not really known any better I believe it is a memory allocation errors as its similar sort of funkyness as I used to get when I stuffed up working with personalised smart shaders.

 

[KimB]

Good point, that's probably it. The skybox has a maximum value of 78600, while MAX_FLOAT16 is 65504 I think. Try changing the last line in skybox.shd to this and see if it goes away:

gl_FragColor.rgb = min(sky.rgb, vec3(60000.0));

That fixes it, thanks. Just note that setting it to:
gl_FragColor.rgb = min(sky.rgb, vec3(65536.0));
...gives the same results as setting the max to 60000.

 

[wireframe]

That fixes it, thanks. Just note that setting it to:
gl_FragColor.rgb = min(sky.rgb, vec3(65536.0));
...gives the same results as setting the max to 60000.

What exactly does this fix? I see no difference whatsoever after changing these values.

 

[bloodbob]

That fixes it, thanks. Just note that setting it to:
gl_FragColor.rgb = min(sky.rgb, vec3(65536.0));
...gives the same results as setting the max to 60000.

Isn't that maximium for fp16 65504 or something?

What exactly does this fix? I see no difference whatsoever after changing these values.

did you try 60000 or 65536? if the latter try with the former.

 

[wireframe]

did you try 60000 or 65536? if the latter try with the former.

I tried both. What exactly is this supposed to fix though? Chalnoth said it did fix something, but what?

 

[bloodbob]

I tried both. What exactly is this supposed to fix though? Chalnoth said it did fix something, but what?

Basicly it caps the maxium value to 60000 or whatever so that it doesn't exceed the maxium value representable ( 65504 I believe but i'd cap it at a bit lower to just make sure there are no errors ) because if the happens it gets stored as infinity. Then if the value is re-read in the next pass and multipling anything by infinity you get infinity so you end up with solid blocks and stuff though if its capped and you multiple 65504 by something small you actually get a real number and basic it works as its intended.

 

[wireframe]

Basicly it caps the maxium value to 60000 or whatever so that it doesn't exceed the maxium value representable ( 65504 I believe but i'd cap it at a bit lower to just make sure there are no errors ) because if the happens it gets stored as infinity. Then if the value is re-read in the next pass and multipling anything by infinity you get infinity so you end up with solid blocks and stuff though if its capped and you multiple 65504 by something small you actually get a real number and basic it works as its intended.

Ok, so it's supposed to cure the remaining blocking like I demonstrated in my last screenshot, where you can still see white and blue squares in the bloom. Well, it doesn't fix that. It still looks exactly the same.

 

[bloodbob]

Ok, so it's supposed to cure the remaining blocking like I demonstrated in my last screenshot, where you can still see white and blue squares in the bloom. Well, it doesn't fix that. It still looks exactly the same.

The well if the blue bloom is still there I dunno what will fix it. The white bloom should be there (problem is it needs a pretty bloom algo is all ).

 

[KimB]

Ok, so it's supposed to cure the remaining blocking like I demonstrated in my last screenshot, where you can still see white and blue squares in the bloom. Well, it doesn't fix that. It still looks exactly the same.

Well, I no longer saw the blue squares in the bloom after applying that change, but now that I look more closely at the program before the change, it may be that I just didn't wait long enough to see the problem (because it doesn't always crop up before making the change to the skybox.shd file).

Edit:
Yes, changing the max value of that color to 65504 fixes the blue blocking problem that occurs when the exposure it set very low, but there is still the issue that the blur gets blocky.

Edit 2:
It looks like I can get rid of the blockiness by setting the maximum value in the skybox to around 100, so this makes it seem like the value 65504 is just too great for the blurring algorithm to properly handle.

 

[Zaphod]

That fixes it, thanks. Just note that setting it to:
gl_FragColor.rgb = min(sky.rgb, vec3(65536.0));
...gives the same results as setting the max to 60000.

That still show some artifacts for me. Lowering the value to 65000 or below fix the discoloration, but still produce some strange rendering around the sun when the castle is supposed to be occluding the outer edges of the light.

Edit: Should have refreshed the thread. Read old version and didn't see that the blue fringing was had already been discussed. Also changed the picture of the second issue to one much better illustrating the problem.

 

[KimB]

I'm willing to bet that the discoloration problem was an issue with storage precision, but the blockiness problem is an algorithmic issue. Specifically, the blurring algorithm only allows the blur to go so far away from the light areas on the screen, and the sun is so bright that it totally saturates the blurrable area.

 

[Humus]

Try changing the last line in convert.shd to this instead of clamping to 100 in skybox.shd:

gl_FragColor.rgb = min(base.rgb * invRange, 1.0);

 

[wireframe]

Try changing the last line in convert.shd to this instead of clamping to 100 in skybox.shd:

gl_FragColor.rgb = min(base.rgb * invRange, 1.0);

That solves it

PS. Can anything be done to smooth out the boxiness in the bloom that seems to simply be a restriction in your choice of affected area? Any way you could round this out as the square box at full saturation looks really unnatural.

 

[KimB]

Try changing the last line in convert.shd to this instead of clamping to 100 in skybox.shd:

gl_FragColor.rgb = min(base.rgb * invRange, 1.0);

Ah, excellent, doesn't require any clamping in skkybox.shd with that instruction.

 

[bloodbob]

That solves it

PS. Can anything be done to smooth out the boxiness in the bloom that seems to simply be a restriction in your choice of affected area? Any way you could round this out as the square box at full saturation looks really unnatural.

Trying a summed area table + guassian would be cool but unfortunatly he would need to use a FP32 texture ( Actually FP32 would possible not be good enough even ) and well he wouldn't be able to filter it on the R3XX cards which was the point of the demo.

 

[Humus]

I've updated the demo again. All issues should be gone now. I also improved the blur slightly by alternating sample pattern between passes, so it looks a bit smoother. I also removed the confusion with the AA settings (which would be disabled anyway) by disabling the AA widget. It's also no longer creating a multisampled framebuffer, which the framework was previously doing when you had AA enabled.

 

[Humus]

Trying a summed area table + guassian would be cool but unfortunatly he would need to use a FP32 texture ( Actually FP32 would possible not be good enough even ) and well he wouldn't be able to filter it on the R3XX cards which was the point of the demo.

FP32 wouldn't filter on any hardware.
Why would a summed area table require FP32 though? And how exactly would one generate a summed area table on the GPU efficiently?

 

[bloodbob]

FP32 wouldn't filter on any hardware.
Why would a summed area table require FP32 though? And how exactly would one generate a summed area table on the GPU efficiently?

( I thought NV might have fp32 filtering I knew it didn't have blending though )
Doesn't your work have white papers on this?
http://mirror.ati.com/developer/SIGGRAPH05/SATsketch-siggraph05.pdf

For a 1024x1024 texture with 16 bit INT you would need a 36bit INT to statisify the precision requirements. So I'd assume for a 16bit float you would need something with 30 bits of precession and an apprioate exponent.

What did you do to fix the corruption on ATI cards?

 

[KimB]

Yeah, summed area tables are pretty horrible on precision. The precision of the output would, at best, be no better than the precision of the mantissa. To look at the precision, just consider that in the worst case, you're going to be subtracting two large numbers to get a small one.

So, if we want 8 bits of accuracy in the output, we're going to need to lose no more than 16 bits of accuracy in that subtraction. Thus, the sum of all numbers in the texture must be less than 2^16 times the dimmest region of the texture, for accurate representation in FP32.

Quite unfortunately, 256x256 = 2^16, so the average must be equal to the dimmest region for accurate representation of a 256x256 FP16 in a FP32 SAT. For each halving of the texture size, we gain a factor of four in allowed dynamic range (i.e. 128x128 allows 4:1 dynamic range).

 

[Humus]

Doesn't your work have white papers on this?
http://mirror.ati.com/developer/SIGGRAPH05/SATsketch-siggraph05.pdf

For a 1024x1024 texture with 16 bit INT you would need a 36bit INT to statisify the precision requirements. So I'd assume for a 16bit float you would need something with 30 bits of precession and an apprioate exponent.

I wasn't aware of that paper. That's interesting stuff though.
As for precision, you'd need 36bit if you don't want to lose a single bit of precision, but I don't think it's much of an issue in this case if I'd lose some bits. Especially not with the bias trick.

What did you do to fix the corruption on ATI cards?

I use the closest power-of-two size for the render targets instead of the screen size for drivers older than the build that has the fix.