• entries
232
1463
• views
961894

# Fixing seams

334 views

I've spent a couple of hours this week end to try to fix the seams problem. You see, when doing texturing, i'm using a normal map in order to correctly texture and light a terrain patch. Each terrain patch has got a local heightfield ( basically, a square area covereing a part of the planet ), and some "links" to the adjacent patches ( this is a part of the algorithm to avoid cracks between patches ). For example, look at this diagram:

In black, a patch at level N, and in orange and green, the two right adjacent patches to the black one, in orange and green, both at level N+1.

Now, to generate the normal map of a patch, i'm using the most simple technique ever: differencing the heightfield. For a given texel, i just take the 4 adjacent heights ( left, right, top, bottom ), and generate a normal from that.

The seams problem occurs for all the texels that are on the boundary: for example, all the texels that are at coordinate x = 0 in the patch. The left adjacent height is undefined for those. So, before, i was simply taking the current height, rather than the adjacent one.

You can see in the following shot, the typical problem when showing off the normal map. In red, the horizontal seams. In blue, the vertical ones.

How to fix that ? I choose the most logical solution: taking the height directly from the adjacent patch. Since i've got the links to the adjacent patches, you're probably thinking it's surely only a matter of sampling the heightfield from the adjacent patch, isn't it ? Well, unfortunately, no, it isn't so easy. You have to remember that the adjacent patches can be at a different tesselation level. You have to list all of the possible situations ( left = level - 1, left = level, left = level + 1), and also handle the case where the sampled height doesn't exist.. yet. Just think about it: if the current patch is at level N and the left one is at level N-1, half the height values in the left patch are "missing", and have to be generated on-the-fly when computing the normal. I'll save the details here, but believe me: sometimes it's mind-boggling.

Anyway, i've finished to fix the horizontal seams. Fixing the vertical seams is only a matter of hours now ( hopefully it should be finished tomorrow ). Here is a screenshot after the fix. If you compare with the previous screen, notice that the horizontal seams ( red arrows ) have disappeared, and that the transition for these normals is now smooth:

Mind-boggling is right... I ran into the same problem on my terrain, but I was not able to find a solution that looks entirely correct, I always ended up with a seam of some sort. I haven't worked on it in a while, but I expect I'll be working on this in the near future. I also need to fix the cracks that form between different tessellation levels, I know what needs to be done, I just have to spend the time doing it ;)

Nice work =)

Interesting entry [smile]

I still mean, time permitting, to have another go at solving those seams that I was getting in my UVAtlas tester. I'm thinking that something similar to what you've done might work.

Provided I can compute the pixel density along a border then it should be possible to make the higher-density side match the lower-density side. I think.

Jack

Ok, it's now fixed. There are still a few seams problems, but these only happen when two adjacent terrain patches are at a different LOD level, which starts only at a certain distance from the camera, so it's not that bad. I don't think anybody will complain.

## Create an account

Register a new account