Cascaded shadow mapping seams

I have implemented cascaded shadow mapping a while ago and I am mostly very happy with my results.
Now trying to improve them further, I am stuck with removing a seam I already had from the beginning:
(using a shadow map resolution of 64*64 * 4 splits)
The seam is a lot smaller than an actual shadow map texel and appears at the borders between the different cascades. Texture wrapping is set to CLAMP_TO_EDGE and filtering is NEAREST. The depth maps are all within the same 2D array texture.
Also I am using COMPARE_REF_TO_TEXTURE as TEXTURE_COMPARE_MODE, allowing me to use hardware filtering for the shadows, but I have the same issue without.
The depth textures do not have those seams, also using only one split the seam disappears.

This is what my shaders shadow function currently looks like:

uniform sampler2DArrayShadow lightDirectionalDepth;
in vec4 vertDirLightProj[RN_DIRECTIONAL_SHADOWS];

float rn_ShadowDirectional()
	for(int i = 0; i < RN_DIRECTIONAL_SHADOWS; i++)
		proj[i] = vertDirLightProj[i].xyz/vertDirLightProj[i].w;
	for(int i = 0; i < RN_DIRECTIONAL_SHADOWS-1; i++)
		inMap[i] = lessThan(proj[i]*proj[i], vec3(1.0));
	for(int i = RN_DIRECTIONAL_SHADOWS-2; i >= 0; i--)
		if(inMap[i].x && inMap[i].y && inMap[i].z)
			mapToUse = i;
	return texture(lightDirectionalDepth, vec4(proj[mapToUse].xy*0.5+0.5, float(mapToUse), proj[mapToUse].z*0.5+0.5));

My guess is, that it has got something to do with this vector:

vec4(proj[mapToUse].xy*0.5+0.5, float(mapToUse), proj[mapToUse].z*0.5+0.5)

because if for some precision reasons the mapToUse used as index, indices the texcoords for another split than the one referred to by float(mapToUse) for some pixels at the borders, it could produce such seams. But the glsl specification specifies that the float to index the array texture is indexed using floor(float(mapToUse)+0.5) which pretty much removes any possibilities for this to break.

Any ideas on what causes those seams and how to remove them are very much appreciated :slight_smile:

I finally found a post about it:
And it turned out that I actually had anisotropic filtering active for the depth maps which was responsible for those seams.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.