PDA

View Full Version : Z-buffer and anti-aliasing



vince
06-02-2005, 11:10 AM
I decided to modify my shader so it writes in gl_FragDepth. I was very unhappily surprised to notice my scene now looks like I disabled anti-aliasing.

I tried thinking of any cause that would create such an artifact without any success. I tried in many shaders and always got the same weird results: when I write to gl_FragDepth, my scene is exactly the same as if I disabled AA.

I'm using a GeForce FX 6800 Ultra.

Anybody saw something like that?

ehart
06-02-2005, 04:17 PM
Well, I think that it to be expected to at least some degree. If you are writing a depth value for the fragment, you are replacing the multiple depth values that would normally be used in the multisample depth test. I would however expect that you could still have antialiasing on the coverage mask for the pixels.

-Evan

Overmind
06-03-2005, 12:00 AM
Shouldn't the fragment program be executed once for each sample when multisampling is activated?

Zeross
06-03-2005, 12:52 AM
Originally posted by Overmind:
Shouldn't the fragment program be executed once for each sample when multisampling is activated?No not with multisampling, the program is executed once per fragment and not once per sample. It's the main reason why multisampling is cheaper than supersampling.

vince
06-03-2005, 05:03 AM
Originally posted by ehart:
Well, I think that it to be expected to at least some degree. If you are writing a depth value for the fragment, you are replacing the multiple depth values that would normally be used in the multisample depth test. I would however expect that you could still have antialiasing on the coverage mask for the pixels.

-EvanI though of it too, so I tried disabling the z-buffer. Even though the image is then a little weird, I can clearly see the aliasing artifacts. So it's gotta be something else.

V-man
06-03-2005, 06:00 PM
A simple test would be to write the depth value unmodified, or perhaps manipulate it a bit like multiplying by a uniform which you can set to 1 to fool the driver optimizer.

I guess the trouble comes from the hw duplicating the same depth values for all the samples.

vince
06-06-2005, 04:47 AM
If it was simple a matter of having the same depth value for all samples, don't you think disabling the depth test would hide the problem?

V-man
06-06-2005, 06:14 AM
Possibly yes and possibly no. It would still have to write depth values. I say "possibly" because I have no insider information so the best thing to do is try.