Sign in to follow this  
Relfos

Deferred rendering shimmering

Recommended Posts

In my implementation of deferred rendering, there is an anoying shimmering when the camera moves, that only occurs in specific parts of the geometry (parts that are very thin, when seen from far away, eg: window borders in buildings)

The resolution of the FBOs is already very big (4096x1080), altough even increasing it more would not solve this.

I think is it mainly caused by the lack of antia-alising when using FBOs?
What solutions there are for this problem?

Share this post


Link to post
Share on other sites
Quote:
Original post by belfegor
I think this is due to your depth buffer precision and i don't think
it can be avoided unless you use some blur + edge detection shader
(fake AA) on your deferred engine.


My position vector is stored in 16bit float format, so it should not have a problem with precision right?
Could you (or someone else) provide some pointers to fake AA in a deferred engine?

Share this post


Link to post
Share on other sites
Quote:
Original post by Relfos
My position vector is stored in 16bit float format, so it should not have a problem with precision right?
That may be the exact problem. A half-precision float has 11 bits of precision (10 bits stored) only.

Which means if "far away" is 200 meters, then everything smaller than 10 cm will be the same. Which is probably ok for some things, but may not be ok for "touchy" things like specular highlights.

Have you considered applying LOD to your specular term, i.e. scaling it down with distance? This is a common hack to avoid "funny sparkles" when rendering oceans and such.

Share this post


Link to post
Share on other sites
I was thinking about this, well, I am actually not using the depth buffer nor the position for calculating the lighting (I've removed all point lights and specular calculations now for testing)

This still happens with just one directional light, but I can somehow understand why, when some thin objects are far away, their size on the screen is one pixel or less, so this causes a 'fight'. Is implementing AA the only solution?
If so, any link with information about a implementation?

Share this post


Link to post
Share on other sites
Quote:
Original post by Relfos
Quote:
Original post by belfegor
I think this is due to your depth buffer precision and i don't think
it can be avoided unless you use some blur + edge detection shader
(fake AA) on your deferred engine.


My position vector is stored in 16bit float format, so it should not have a problem with precision right?
Could you (or someone else) provide some pointers to fake AA in a deferred engine?


Storing position in an fp16 texture is pretty awful, precision-wise. I did some tests a while ago on my blog, if you want to see for yourself.

Share this post


Link to post
Share on other sites
Quote:
Original post by smasherprog
try checking this link out


http://www.mvps.org/directx/articles/linear_z/linearz.htm


This will explain how to make your depth work for you!


No it won't. What he does in that article can totally break things like z-compression and early-z cull. It also totally fails for triangles that cross the near-clip plane.

Share this post


Link to post
Share on other sites
In my engine I use only 16 fp RGBA render targets(like SCII) and store the linear depth value into two channels (in the other two channels of the corresponding texture I write the encoded normal). Using a single 16 fp value for depth was not enough, but using two delivers an artifact free representation.


Thought I keep a standard 24 z + 8 stencil buffer for fast z- and stencil tests.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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'.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this