I'm drawing my terrain in chunks and there is a seam between the chunks, even though i'm including neighbour chunk vertices when calculating edge normals. I was thinking maybe it's because my normals are being interpolated when sampling the chunk normal map in the pixel shader?

"Spending your life waiting for the messiah to come save the world is like waiting around for the straight piece to come in Tetris...even if it comes, by that time you've accumulated a mountain of shit so high that you're fucked no matter what you do. "

non-seamless normal map perhaps? or pehaps some out-of-phase type error ? notice how it looks like the shadows would line up better if they were shifted a bit along the seam.

it would seem to me that all types of maps (texture, normal, specular, bump, bakelite, etc) would need to be "seamless" at chunk edges. if all laid out together they'd make one huge seamless map. then everything should match up, whether you're drawing things straight out or sampling across seams.

i use chunks that are 300x300 in size. chunks are generated on the fly as needed. the ground mesh for a chunk is generated from a procedurally heightmapped 10x10 quad, one mesh per ground texture used (currently 4 tiles). but all normals are pointing straight up. i adjust the y values of the 4 corners of a quad, translate it to its proper location in the chunk, and add it to the ground mesh vb and ib. but i dont recompute the normals. i suppose i ought to do that eh?

I was thinking maybe it's because my normals are being interpolated when sampling the chunk normal map in the pixel shader?

Sounds reasonable. If you're using REPEAT texture access you're set up for surprises. Real thing is, you don't assemble chunks to make a big terrain. We slice big terrains into chunks instead. All bounduary samples must use inter-chunk fetch. Seamless chunks hide the problem at an extreme authoring cost and limitation, don't do that.

I was thinking maybe it's because my normals are being interpolated when sampling the chunk normal map in the pixel shader?

Sounds reasonable. If you're using REPEAT texture access you're set up for surprises. Real thing is, you don't assemble chunks to make a big terrain. We slice big terrains into chunks instead. All bounduary samples must use inter-chunk fetch. Seamless chunks hide the problem at an extreme authoring cost and limitation, don't do that.

I already use neighbour chunk vertices for border cases if that's what you mean

Is this seam there if you just go by normals, no normal maps?

What do your texture coordinates look like?

(Your normal map isn't in a texture atlas, is it?)

Yes, i just tested and the normals look fine when passed with the vertex. I guess it is a problem with the texture sampling... Any idea how to fix it? Or rather, why not just pass the normals instead of using normal maps? Does bump mapping even work when the texture resolution is the same as the vertex resolution?

And no i'm not using an atlas; a separate texture per chunk

If you are using bezier patches, make sure you are joining your patches with at least C1 continuity.

I don't even know what that means

Edited by Waaayoff, 28 June 2013 - 02:23 AM.

"Spending your life waiting for the messiah to come save the world is like waiting around for the straight piece to come in Tetris...even if it comes, by that time you've accumulated a mountain of shit so high that you're fucked no matter what you do. "

Does bump mapping even work when the texture resolution is the same as the vertex resolution?

Normal mapping has nothing at all to do with how many vertices there are. Normal mapping is a per-pixel operation, the best normal map resolution is the one that most closely matches how many pixels the model takes up on the screen. If your screen size is 1024x1024 and your model takes up 1/4 of the screen, then you should use a normal map that is 512x512. If the normal map is heavily blurred then you can use a smaller resolution with out much noticeable decrease in apparent detail.

The idea of normal mapping is to fill in the space between vertices, with the illusion of detail. This makes a low-poly model look like a high-poly model. This illusion breaks down at the silhouette of a model and also at steep angles.

If you use very small textures then those textures will be sampled up in size for models that take up a lot of screen space, this will result in blocky artifacts.

To clear up those seam edges you will likely have to make the textures seamless.

I Googled -> how to make seamless textures and chose a couple to get you started.

Also, I suppose I should also mention. The PhotoShop tutorial and the GIMP tutorial are using two very different methods to achieve seamless-ness.

The GIMP method is more of an optical illusion created by a plugin. However, the method used on the PhotoShop page will work in GIMP as well, both have the offset function. It's just that GIMP also has a quick and dirty plugin trick that may work for many circumstances.

Consider it pure joy, my brothers and sisters, whenever you face trials of many kinds,3 because you know that the testing of your faith produces perseverance.4 Let perseverance finish its work so that you may be mature and complete, not lacking anything.

I'm having a similar problem. Wish I knew how to fix it. I figured my over coordinates were off but they are correct. The chunks are also perfectly aligned. Nonetheless there is a visible seam on the x and zaxis where chunks meet. They also have exactly the same amount of vertices no lod here just bruteforce 64x64 terrain quads. I've basically moved onto other things can't figure it out even tried skirts didn't help sigh

I'm having a similar problem. Wish I knew how to fix it. I figured my over coordinates were off but they are correct. The chunks are also perfectly aligned. Nonetheless there is a visible seam on the x and zaxis where chunks meet. They also have exactly the same amount of vertices no lod here just bruteforce 64x64 terrain quads. I've basically moved onto other things can't figure it out even tried skirts didn't help sigh

Are you using neighbour vertices to calculate the edge normals? Because if you are, if you send the normals with the vertex the problem goes away. Even if you don't and choose to sample them from a texture, the seams are not noticeable in the slightest when you texture the terrain.

"Spending your life waiting for the messiah to come save the world is like waiting around for the straight piece to come in Tetris...even if it comes, by that time you've accumulated a mountain of shit so high that you're fucked no matter what you do. "

If your terrain is flat, there shouldn't be any seams even if you aren't using neighbour patches. Are you sure you're calculating your normals correctly? (i have no experience with the sobel operator). Try visualizing the normals with the pixel or geometry shader.

Also, i think you're overcomplicating your calculations. The way i do it is to simply store the neighbour vertices with the patches. So if my chunk is 65x65, i store a border around it so that it's 67x67 and use the extra vertices to calculate the normals. This way you won't have to consider each case (top, left, etc..) explicitly. Here's how the final code turns out:

Edit: I just realized that you are hardcoding your normal to (0, 1, 0). This only leaves the texture... Did you try rendering with lighting only?

Edited by Waaayoff, 17 August 2013 - 03:25 AM.

"Spending your life waiting for the messiah to come save the world is like waiting around for the straight piece to come in Tetris...even if it comes, by that time you've accumulated a mountain of shit so high that you're fucked no matter what you do. "

Haha a border so simple. Will implement and get back to you. Also will see if I can verify the normals. I added sobel calculation as it gives a noticeable enhancement with normal mapping. It is based purely off the height map. The tangent and binomial are calculated differently with the y axis now factored in with is important for surfaces that are not flat. The normal from this final calculation is then averaged with the sobel calc to give a good enough, visually, result.

Well I ran into some problems implementing the border vertices for sampling normals actually became quite complex. So I reverted it and now I'm back to where I was before. I'll have to tackle this bug again. I have to move onto some important features and mechanics.