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

## 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: 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 on other sites
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 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 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 on other sites
Quote:
 Original post by n00bodyStill, 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 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.

1. 1
2. 2
3. 3
Rutin
16
4. 4
5. 5

• 10
• 11
• 14
• 10
• 25
• ### Forum Statistics

• Total Topics
632652
• Total Posts
3007650
• ### Who's Online (See full list)

There are no registered users currently online

×