3
\$\begingroup\$

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: enter image description here

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ did you try CLAMP_TO_EDGE instead of CLAMP ? \$\endgroup\$ – concept3d Mar 31 '14 at 8:55
  • \$\begingroup\$ I am not familiar with Sobel filtering but how is the original value of texCoord calculated? \$\endgroup\$ – Syntac_ Mar 31 '14 at 10:26
  • \$\begingroup\$ @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. \$\endgroup\$ – pl12 Apr 1 '14 at 0:29
  • \$\begingroup\$ 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. \$\endgroup\$ – GuyRT Jun 30 '14 at 13:56
1
\$\begingroup\$

It may be that you are hitting an edge of the texture when sampling. If so, the GPU will just wrap around and return you a disconnected texel from the other side. You could try messing a bit with the texture filtering options to see if there are any visible changes (on OpenGL glTexParameter() with GL_TEXTURE_MIN_FILTER and GL_TEXTURE_MAG_FILTER), and possibly manually adding a safety border to the textures yourself.

\$\endgroup\$
0
\$\begingroup\$

Any specific reason you're using 258 x 258 pixels heightmap/texture?

Two rows and columns of pixels possibly force the graphics card into making the texture up to four times as big as necessary which might as well cause those black lines, since it might not be able to handle textures that aren't the power of two for their width/height.

The unused pixels might be filled with some other color (like black), which could then cause them to bleed into their neighbours when upscaled.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.