# Sampling Heightmap Edges for Normal map

I use a Sobel filter to generate normal maps from procedural height maps. The heightmaps are 258x258 pixels. I scale my texture coordinates like so:

texCoord = (texCoord * (256/258)) + (1/258)


Yet even with this I am left with the following problem:

As you can see the edges of the normal map still proves to be problematic. Putting the texture wrap mode to "clamp" also proved no help. EDIT: The Sobel Filter function by sampling the 8 surrounding pixels around a given pixel so that a derivative can be calculated in order to find the "normal" of the given pixel.

The texture coordinates are instanced once per quad (for the quadtree that makes up the world) and are created as follows (it is quite possible that the problem results from the way I scale and offset the texCoords as seen above):

Java:

for(int i = 0; i<vertices.length; i++){
Vector2f coord = new Vector2f((vertices[i].x)/(worldSize), (vertices[i].z)/( worldSize));
texCoords[i] = coord;

}


the quad used for input here rests on the X0Z plane. 'worldSize' is the diameter of the planet. No negative texCoords are seen as the quad used for input for this method is not centered around the origin.

Is there something I am missing here? Thanks.

• did you try CLAMP_TO_EDGE instead of CLAMP ? – concept3d Mar 31 '14 at 8:55
• I am not familiar with Sobel filtering but how is the original value of texCoord calculated? – Syntac_ Mar 31 '14 at 10:26
• @concept3d Yes, that did not alleviate the issue. Sytnac,The sobel filter works by sampling the 8 surrounding pixels of one pixel on the heightmap. These samples are then convolved with a matrix to determine the rate of change of the "color" so a normal can be computed. This pixel sampling is what causes the bad edge problem. I will add the texcoord generation code above. – pl12 Apr 1 '14 at 0:29
• How are you generating the heightmaps? If you are doing it in shader, you can use the derivative functions to calculate the normals at the same time. – GuyRT Jun 30 '14 at 13:56