Jump to content
  • Advertisement
Sign in to follow this  
Relfos

Deferred rendering shimmering

This topic is 2831 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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
Advertisement
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.

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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!