Jump to content
  • Advertisement
Sign in to follow this  
n00body

OpenGL [SOLVED] Deferred lighting artifacts (depth, specular)

This topic is 3258 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

Background: Okay, I have been trying to write a deferred lighting renderer in OpenGL 2.0, in an attempt to get deferred shading with far less VRAM usage. Recently, I've reached the point where I have only RGBA8 targets, no MRT, and using native depth data for position recovery. For the depth, I do an FBO Blit from the prepass FBO with a renderbuffer, to an FBO with a depth texture. Then in my lighting shader I convert the depth samples to linear eye depth using the following code:
// CPP
scale = 1.0f / (1.0f - zNear / zFar);
zParams.x = zNear * scale * (1.0 / zFar);
zParams.y = scale;

// Cg
depth = TEX2DLOD(depthBuffer, screenPosition).r;
depth = zParams.x / (zParams.y - depth);

From this, I just use the eye depth for the Crysis position recovery trick, and perform all my lighting calculations in view-space. Problem: The problem I encountered recently is that my specular lighting has a really nasty flickering/diagonal line artifact as the camera/objects move: (Specular Artifacts) 1 (Specular Artifacts) 2 My ultimate question is whether or not anyone else has encountered similar problems when using native depth data the same way? Is there a way to eliminate or minimize these unsightly artifacts? Any help would be most appreciated. ;) Further Info I strongly suspect that the origin of the problem is the low-precision depth buffer, since I encountered similar issues when trying to store the raw linear eye depth in an RGBA8 RT with bit-packing. I've also observed that the visual artifact takes a banding appearance that follows the bands in the eye depth buffer. [Edited by - n00body on October 24, 2009 7:00:05 PM]

Share this post


Link to post
Share on other sites
Advertisement
Yes, many people have this problem. The solution is usually to use a high-precision floating point texture.

Due to my limited hardware, I have never used deferred shading, but it occurs to me that if you're going to implement bloom down the line, you might as well blur your specular buffer anyway, especially if it comes out hard-edged and flickering otherwise. So all you have to do is take what you have now, run it through a simple blur filter (not even a large blur, just one small enough to smooth out the sharp discontinuities), and none will be the wiser.

Share this post


Link to post
Share on other sites
Have you considered storing normals in a different coordinate space? There are several choices which might improve your quality while keeping a low memory footprint.

See here for a comparison of several options.

Share this post


Link to post
Share on other sites
Apparently it was the normals, as I tried giving it a higher precision buffer for testing, and that eliminated the artifact. I guess I will have to explore those packing options, if I want to keep the storage cost low, but the quality decent.

Still, I had heard that RGBA8 was sufficient for view-space normals. Was that info incorrect?

Share this post


Link to post
Share on other sites
Quote:
Original post by n00body
Still, I had heard that RGBA8 was sufficient for view-space normals.
Sure, as long as you convert to a 2-element representation, and spread it out across all four 8-bit fields [smile]

TBH though, you may be able to get entirely acceptable quality by following JDS0's advice, and lightly blurring the normal buffer. I ended up just using an RGBA16F buffer for simplicity.

Share this post


Link to post
Share on other sites
Actually, I found the real problem. I re-examined my normal sampling shader code, and noticed I had forgotten to add a normalize() on the sample after I switched to the RGBA8 storage. Having corrected that omission, the artifact has been eliminated.

So thanks for helping me spot my own error. I might consider those packing options for quality improvement. However, I will probably opt to keep instruction counts low for now.

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!