i render my scene to FBO1 with multisampled renderbuffers, blit FBO1 to FBO2(with GL_TEXTURE_2D as storage) to downsample, and finally render a fullscreen quad to the framebuffer with FBO2’s texture.
This works nicely on Nvidia 8800Gt. On Ati X3850, it works basically too, but i get random white flimmering pixels at some multisampled edges.
As long as long as the objects remain static, the white pixels stay at the same position. When i change the modelview slighty, they appear at other random locations, but only at the multisampled regions.
Found a solution: Enabling “Adaptive Anti-Aliasing” in the driver settings seems to fix the white flickering artifacts(i have not verfied yet that it really does in all cases).
It’s normally meant to fix aliasing in alpha-test textures like fences in games. I have alpha-blended-textures, but i don’t understand why i need to enabled it though…
The adaptive AA is just hiding the problem by diminishing the contribution from aberrant sub-samples. This looks like a backface vs. frontface zfighting artifact at the silhouette where they can become arbitrarily close; if you can, enable backface culling.
It could also be z invariance if you’re using multiple passes but that’s generally less of an issue on modern hardware.
Thanks for your input, dorbie. I checked the points you mentioned:
It’s 1 pass only
Culling is on
So i don’t think that’s the problem directly.
But while checking, i took a closer look at the scene rendering:
With all simple shaders(decal only, no lighting) there are no artifacts visible
If i use a very simple shader pair to show the “vertex.normal.xyz” as “result.color.rgb”, i see flimmering pixels as black holes.
(Came up with that idea after pointless hours of debugging my shaders They produce white pixels because of those normals)
With that adaptive AA the holes are also closed when rendering the vertex.normal
The whole thing looks like a zfighting artifact, you are right, but i don’t know how to fix it…
Hmm not directly at least. I use the ASM shaders, and just do regular stuff like dot3 bump mapping, shadow mapping etc.
Well, i think i give up finding a solution. :tired:
I just enable “adaptive AA” in the registry and leave it at that. To accomplish that, the key “ASTT” must changed from “0x30,0x00” to “0x31,0x00” (at least for catalyst 8.8 on winXP).
If you have more ideas, i’m still interested in understanding the problem.
Centroid support was introduced in the NV_fragment_program4 extension, but as you want to support ATI you’ll have to switch to GLSL.
Or just switch to Direct3D (seriously)