Pixel/Texel offset problem (deferred composition)

Started by
5 comments, last by csisy 11 years, 9 months ago
First let me show you what the problem looks like:

http://cl.ly/2G0X1G36232L110l2H0l

As you can see every mesh I render has this (in this case white) border around it.
This border is color leaking from the lightmap (I've confirmed that it is exactly the color of the lightmap at that pixel position).
Now if I only output the Albedo or the Lighting itself there's nothing wrong. Only when combining both of them in the compose shader I get this leaking issue. Please tell me if I'm doing something wrong with the half-pixel offset correction.

Here's how I correct it in the VS on both the lighting and compose shader:

// Pass UV (pay attention to half pixel offset)
output.UV = input.UV - (0.5f / GBufferTextureSize);

GBufferTextureSize is a float2(screenWidth, screenHeight)


I've also tried (1.0f / GBufferTextureSize), like my tutorial wrote, which gives me even thicker borders.
Sampling albedo as point clamp also does not change anything.
MSAA is also turned off.

Update: I think outputting transparent black around the objects in the lighting shader seems to fix this...still experimenting....

Update2: Ok so if the object has nothing behind it having a different shading than the one in front it works but as soon as there's shaded pixels behind it the light leaks through again so it must be something else...
Advertisement
Try using tex2dlod with 0 as the MIP level. You may be getting screwed-up derivatives at the borders due to texture coordinate discontinuities.
clb: At the end of 2012, the positions of jupiter, saturn, mercury, and deimos are aligned so as to cause a denormalized flush-to-zero bug when computing earth's gravitational force, slinging it to the sun.
Which API are you using? AFAIK, only DX9 requires the half-pixel fix-up shenanigans.
I'm pretty sure that you have to add 0.5 texel size instead of subtracting it.
I'm using XNA which is using DX9.0c.
I know it's horrible for the stuff I'm trying to do but it gets me results pretty fast and easy.

@Ohfof sake It works !
This half pixel offset is pretty confusing to me especially since every code sample seems to write it different (or wrong in my case).
There's lots of different ways to write a solution, and you should be able to come up with your own once you understand it. It is confusing though, and is something that trips you up a thousand times in DX9...

The problem is that when drawing a full-screen quad, DX9 places your vertices at the middle of pixels (left side), whereas everyone else places them at the corners of pixels (right side).
+-+-+-+-+ A-+-+-+-B
|A| | | |B | | | | |
+-+-+-+-+ +-+-+-+-+
| | | | | | | | | |
+-+-+-+-+ +-+-+-+-+
| | | | | | | | | |
+-+-+-+-+ +-+-+-+-+
| | | | | | | | | |
+-+-+-+-+ C-+-+-+-D
C D
When the pixel-shader runs (or fixed-function texturing), the texture-coordinates that it uses are calculated by interpolating the vertices based on how close the current pixel is to each vertex. You can see that in the DX9 version, the top-left pixel lines up perfectly with vertex "A", so when interpolating for that pixel, it uses 100% of tex-coord A and 0% of tex-coord B.
This is a problem because when sampling textures, the coordinate you're supposed to use it the centre of the texel that you want to sample, not the top-left corner of the texel!
If A has u=0 and B has u=1 and your texture is 4px wide, then the u value for the center of the top-left pixel is 0.125 (i.e. half a pixel across out of 4 wide, 0.5/4, or 12.5% of B + 87.5% of A).
I have to add the half pixel. Why shouldn't I substract it from the texcoord?
Like Hodgman wrote, the top left pixel is "0,125", so I should substract the half pixel to get the 0 value. Or am i wrong somewhere?
sorry for my bad english

This topic is closed to new replies.

Advertisement