// 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);
[SOLVED] Deferred lighting artifacts (depth, specular)
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:
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]
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.
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.
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.
See here for a comparison of several options.
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?
Still, I had heard that RGBA8 was sufficient for view-space normals. Was that info incorrect?
Quote:Original post by n00bodySure, as long as you convert to a 2-element representation, and spread it out across all four 8-bit fields [smile]
Still, I had heard that RGBA8 was sufficient for view-space normals.
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement