I don't want to seem rude, as everyone is trying to help, but it seems that everyone missed my second post, as I said, I'm not reading the position anymore (I just need it for point lights and specular, and I disable those).
The problem still appears, it is not related to the fp16 position, as for depth testing, I still use a hardware zbuffer.
The only things I read now from the GBuffer are the color and the normals, so increasing the z precision won't change anything, I think...
Deferred rendering shimmering
Author
Thanks, but I'm afraid that one won't also work!
"Cons - Doesn't account for "walking jaggies" (temporal aliasing) and can't compensate for details on a sub-pixel level (like poles or wires in the distance), since that requires creating detail out of thin air"
But this helped, now I know this problem is called 'temporal aliasing', I will try to search for something.
"Cons - Doesn't account for "walking jaggies" (temporal aliasing) and can't compensate for details on a sub-pixel level (like poles or wires in the distance), since that requires creating detail out of thin air"
But this helped, now I know this problem is called 'temporal aliasing', I will try to search for something.
Thought I'd add my two cents as well:
First: It's hard to diagnose the things with just a textual description an image/video would help.
Second: Are we really sure we're talking about a shading problem (artifacts due to g-buffer precision) and not a simple visibility problem (z-fighting due to z-buffer precision).
These comments sound more like a z-buffer problem.
To rule this our you could try push the near clipping plane as far away from the camera as possible and look if it gets better (this is why). Or you could look at your color buffer and see if there are some wrong entries it (in a still image).
First: It's hard to diagnose the things with just a textual description an image/video would help.
Second: Are we really sure we're talking about a shading problem (artifacts due to g-buffer precision) and not a simple visibility problem (z-fighting due to z-buffer precision).
Quote:
... parts that are very thin, when seen from far away ...
... although even increasing it more [resolution] would not solve this ...
These comments sound more like a z-buffer problem.
To rule this our you could try push the near clipping plane as far away from the camera as possible and look if it gets better (this is why). Or you could look at your color buffer and see if there are some wrong entries it (in a still image).
Author
Ok, I tried now changing the near from 0.1 to 1.0, and the zfar to 500, should be an ok range. The problem still persists.
I found some new things about this.
- By visualizing the GBuffer contents, the problem resides in just the color buffer, so, it is not related to lighting at all (this excludes gbuffer precision issues)
- The problem is only found in parts with transparent parts (alpha testing) that are far away.
I found some new things about this.
- By visualizing the GBuffer contents, the problem resides in just the color buffer, so, it is not related to lighting at all (this excludes gbuffer precision issues)
- The problem is only found in parts with transparent parts (alpha testing) that are far away.
MJP
I am curious, how can it hurt z-compression? How is it possible that it can break early z cull? and how can it fail for triangles that cross the near clip plane?
The technique does not appear to do any of what you said, so I am wondering what I am missing?
I am curious, how can it hurt z-compression? How is it possible that it can break early z cull? and how can it fail for triangles that cross the near clip plane?
The technique does not appear to do any of what you said, so I am wondering what I am missing?
Quote:
The problem is only found in parts with transparent parts (alpha testing) that are far away.
If the alpha value is read from a texture it could be the texture filter. Farther away in general means higher mip-levels which can have the alpha channel blurred (which -- I assume -- can be problematic for the alpha-test). On the other hand, if you don't have mip maps you will get pixel flickering from the unfiltered texture read. I'm not sure if there's a solution to this (or if this is really the problem here). Maybe it's just 'pick your poison'.
Author
Quote:Original post by macnihilist
If the alpha value is read from a texture it could be the texture filter. Farther away in general means higher mip-levels which can have the alpha channel blurred (which -- I assume -- can be problematic for the alpha-test). On the other hand, if you don't have mip maps you will get pixel flickering from the unfiltered texture read. I'm not sure if there's a solution to this (or if this is really the problem here). Maybe it's just 'pick your poison'.
Yes, that seems exactly the problem.
What about reating the mipmaps manually, calculating alpha in a different way, to keep consistency with edges where the alpha reaches the alpha test value.
Could this be a possible solution?
I have not thought about it much, but I assume it could at least improve things a bit. But in the end you can only define an edge in the texel raster (plus linear interpolation) and if this raster is very coarse many (color-)texels of the original texture will be on the wrong side of the alpha test. You could also try to let the color bleed over the edges a bit, so even if the edge is wrong you at least don't get a wrong color filtered into the result.
But I'm increasingly skating on thin ice here, as I have never had the `pleasure' to deal with this problem.
But I'm increasingly skating on thin ice here, as I have never had the `pleasure' to deal with this problem.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
