Tiling textures using mod() in shader causes stripes on textures

Started by
2 comments, last by tanzanite7 10 years, 3 months ago

Hi!

In my Unity project I want to apply various textures to my voxel terrain. I'm using a texture atlas. In some cases I needed to repeate the texture, so I found out mod() function to be the solution, but it produces nasty one-pixel wide stripes on my textures, which appears to be the first stripe of the neighbouring texture. I turned all the filtering off (apart from point, which cannot be turned off (which is logical) and I think this is the problem), but it did not solve the problem. And here's the question:

How to get rid of this stripe?

Possible solution (but i'd rather a simpler one):

Create an alghorytm that from an array of individual textures creates a single texture atlas, but it adds additional one-pixel padding to each texture (repeating the bordering pixels) - if sampler just takes that one pixel from the neighbouring texture due to point filtering (which cannot be turned off) it will fix the problem, but as I wrote - if you know a simpler solution, it is better for me.

Below I place the source of my shader:

I also attach some screenshots.

Input.color contains texture offset in atlas.

Thanks in advance for your help!


Shader "Custom/WorldShader" {
	    Properties {
	    	_MainTex ("Base (RGB)", 2D) = "white" {}
	    	_TileScale ("Texture size in atlas", float) = 1
	    }
	    
	    SubShader {
		    Lighting Off
		    pass {
			    CGPROGRAM
			    #pragma vertex vShader
			    #pragma fragment pShader
			    #include "UnityCG.cginc"
			      
				sampler2D _MainTex;
				float _TileScale;
			       			     
			    struct VertIn {
				    float4 vertex : POSITION;
				    float4 color : COLOR;
				    float2 texcoord : TEXCOORD0;
			    }; 
			     
			    struct VertOut {
				    float4 position : POSITION;
				    float4 color : COLOR;
				    float2 texcoord : TEXCOORD0;
			    };
			     
			    VertOut vShader(VertIn input) {
				    VertOut output;
				    output.position = mul(UNITY_MATRIX_MVP,input.vertex);
				    output.color = input.color;
				    output.texcoord = input.texcoord;
				    return output;
			    }
			     
			    float4 pShader(VertOut input) : COLOR0 {
				    float2 newUVs = float2(fmod(input.texcoord.x, _TileScale) + input.color.r, fmod(input.texcoord.y, _TileScale) + input.color.g);
				    return tex2D(_MainTex, newUVs) * (UNITY_LIGHTMODEL_AMBIENT * 1.5);
			    }
			    ENDCG
		    }
	    }
    }
Advertisement

My immediate thought was also that it was a bilinear filtering issue, but you say that point sampling doesn't fix it. Adding a little padding around atlas textures is something that's pretty commonly done and sounds like a decent solution.

The only other thing that occurred to me is that maybe it's a floating point precision thing. Your UV coordinates are being passed to the GPU as floating point numbers, which are incredibly accurate, but the further away from zero they are, the less precision they'll have after the decimal point. A floating point number has no problem accurately specifying a single texel in a 1024x1024 texture if the UV is near zero, but you'll find that if your UVs are up beyond 1000 or so, then the amount of precision after the decimal point becomes too small and you could expect precision artifacts.

If I understand the issue correctly, that's an old, well-known problem. You will need to calculate (and specify in your texture lookup) the mip level or the gradient (whichever is supported by your hardware). Mip-mapping is still turned on, right? (also check driver settings to avoid surprise, driver may force it on even if you don't)

The problem with functions like modulo is that the hardware calculates the mip level from the gradient, and the modulo function being discontinuous causes big "jumps" in the gradient. Which, of course, causes the hardware to pick the wrong mip level at the discontinuous locations.

What surprises me a bit is that you think you're getting vaues from a neighbouring texture atlas piece. That isn't normally the case and it doesn't really look like that to me in the screenshot either (but who knows for sure -- you could extend each tile with its border pixel value as padding to "work around" if nothing else helps, or make a "control color" border around each tile to be sure, that is a color you would not normally expect to see).

creating a gap between sprites would work, but your texture coordinate calculations will need to account for the pixel gap.

You might have bad mipmap selection as mentioned, however that would generate only 2x2 spots of garbage - that clearly does not match the picture.

Would guess it is the half texel issue (depending on whether Direct3D or OpenGL is used - (0,0) is either corner [OGL] or middle [D3D? - or have they changed that?] of texel) - however, the error seems to cover more texels that one would expect on such a case (might be just my eyes - the error should be about 1, rarely 2 texels worth).

My guess is that your texture coordinates are just wrong. Take pencil and paper and check that the final coordinates are exactly what they should be.

This topic is closed to new replies.

Advertisement