UV bleeding / tearing

[JuhaKiili]

UV bleeding / tearing

[Bloodyaugust]

The "No Bugs" test produces bleed on the far right for me.

The "Diagonal Bug + Bleed" test produces no diagonal bug, but bleeds through on top.

Using Win7/ATI Mobility Radeon HD 4200

[JuhaKiili]

I haven't seen anyone bleed with the "No Bugs" before. What kind of hardware/os?

[Bloodyaugust]

Sorry, I updated the previous comment as you typed that one. Don't know why they aren't dynamically updating these comments...

[JuhaKiili]

DISCLAIMER: What I'm explaining here might be really painful to understand without supporting pictures. I'm mostly writing this as note to myself.

I just had a little revelation. I could get the bleeding in OSX too. Didn't remember the half pixel difference between OpenGL/D3D anymore (thanks to Dinesh Kumar, creator of 2D toolkit, for pointing it out earlier).

If your mesh, UV coordinates and screen space location align in a certain way, you are going to sample between texel borders and get undefined behavior on either side of the quad. If you assume arbitrary position for camera or arbitrary position for sprite, you will always have possibility to hit this situation.

Like said, this is usually no problem with single sprite. Sampling over the border is fine, because the neighboring texel is always just transparent. It is only when we start stacking meshes side by side (repeating the sprite), that the transparent bleed starts to bug us.

Option A: force positions

If we would force the camera and sprites in even pixel positions, and take account the difference between D3D/OpenGL, then we could make sure that we never sample from the border of two texels.

Trying to force some transform.positions is a bad idea IMO. People want to use decimal positions to do cumulative stuff like transform.Translate(up * deltaTime), which wouldn't work anymore.

Option B: shift the UV's inward

If we try to move the UV coordinates just a little teeny weeny amount away from the texel border, we would still get artifacts in the middle of the sprite, because now the pixel width of the mesh wouldn't match the width of the sprite on the texture. We would just move the problem from the edges to the middle. It would be less bad, but still crap.

Option C: shift both the UV's and the mesh vertices inward

If we try to move both the UV coords and the vertices to maintain the pixel scale, we would not bleed in sampling, but instead we wouldn't even be sampling at all. There would be a single empty one pixel line on the border of the mesh.

Option D: check for the possible edge condition between every sprite and camera every frame

This is pretty darn inefficient, but I think it's something like two floating point modulo operations per check. It can be optimized to just check the sprites that are stretched and use repeating.

[JuhaKiili]

Option E

Make some kind of vertex shader that always snaps the meshes aligned with pixels in the GPU. This way the transform.Translate stuff would work normally. I have no idea if that can be done. Shaders are not my cup of tea.

EDIT: Hard some very promising early results with option E. Using this method would need some changes to the way the camera and sprite pixel sizes are handled.

[Bloodyaugust]

@JuhaKiili: My current approach is to avoid using tiling. On Option C, this is essentially what I used to do with Unity3D with planes for 2D. They had a similar problem, even without tiling. The solution was to leave the outer pixels empty in the actual image.

[JuhaKangas]

Just wanted to mention that I'm having this problem, I can't help you guys figure it out but I can provide specs and do testing if you want to.

I'm on Windows 7 and have a GeForce GT 230M

[JuhaKiili]

Already at Unity and not really time to look at RagePixel for a while now, but just to make clear: This is not limited to certain hw afterall. It's just reproduced differently on different hw, but you can repro on everything I think.

[ericraue]

@JuhaKiili Would you mind sharing your in progress code for Option E? It's related to the PhysX addition I'm working on so I should have some time to work on it.

[JuhaKiili]

Sorry I have it at home only and it's not much code anyways. I can send it on 28th earliest.

[JuhaKiili]

Recently people smarter than me showed me how to fix this. So I did. Better late than never :)