Sorry your browser is not supported!

Hey,

I've been using Green Gandalf's amazing advanced terrain shader for texturing my terrains. I'm having an issue with them though. I'm using terrain segments tiled together to form a large terrain. For some reason there seems to be a pixel at the edge of the terrain that remains the default texture, creating a visible seam. Here's a picture:


It's really not that big of a deal but I was wondering if anyone knew how that could be fixed? And if it's even related to GG's shader? The reason I'm assuming it is is because it has to do with layered textures.

Another issue I'm having has to do with the shading when I update the terrain normals. I don't think this has to do with GG's shaders. There is a visible seam if there is an elevation difference between two scenes. Here's a pic of that:


Again, not a big deal, but just wondering if anyone has experienced this and knows how to solve it (hoping it's just a simple command I'm missing). Thanks!

Thanks - but which one?

Your first problem looks like a texture wrapping problem to me and something probably needs to be clamped rather than wrapped. However I can't be sure till I have more details about the shader and the objects. Is that screenshot showing four different terrain objects adjacent to each other? With luck the fix may be simple.



That's a standard problem with limbed or tiled terrain. The built-in DBPro set object normals command (which I assume you're using) knows nothing about what's supposed to happen along the seams between adjacent tiles or limbs. You will need to calculate those manually which is a pain. That's what I do in some of my Advanced Terrain shader demos. [Edit Actually, thinking about it, that's not quite true - I usually precalculate all the normals in an array for the whole terrain then copy those into each tile or limb as required. Then no averaging is needed.]

The simplest solution, which although simple in theory is a bit messy from a coding point of view, is to replace all the normals along the seams by the normalised averages of the normals where points coincide. For example, if tile A has an edge vertex number 1 which is in the same position as edge vertex number 23 of tile B then the corresponding normals should be replaced by a single average figure and so on all along the joins.

I'm using "gg_blend_and_per_pixel.fx", which I think you gave me this thread: http://forum.thegamecreators.com/?m=forum_view&t=174943&b=1


I think it is a texture wrapping problem, because if I look at the other end, it seems that there is a single pixel of the grass painted along the border. So it's almost like I need to shift the texture slightly. Here's some screenshots to show you what I mean.

If I paint one end of the terrain like this:

You can see a single stripe on the other end:


Yep, that screenshot is showing a corner where 4 terrains come together.


Yep, that's what I'm using.


Hmmm, I'm a bit confused at what you mean...how would I go about manually calculate the normals? And the issue with precalculating the normals for all of them is the total size of my terrain is 50x50 mini-terrains, and it could grow larger, so would it be practical? Also, if the terrain is being modified, won't I have to manually recalculate the normal constantly?

Thanks a lot for the help!

Thanks for the link. There's a bug in the shader . The fix should be simple. In the shader change the wrap mode to clamp in these lines, i.e. change to:



The wrap modes for the detail textures should be correct. Let me know how you get on.



In your situation it sounds as if the solution is to loop through each edge shared by two tiles, copy the normals for the shared vertices into two arrays, one for the first tile and one for the second. Then average and renormalize the normals pairwise, next replace the original arrays with the new normals and finally copy those back into the tiles' normals. You'll need to use the vertexdata commands to read and copy back the normals. The details will be a bit messy, but if you are using IanM's high poly plains it shouldn't be too difficult. If you get really stuck I'll put together a simple demo.



Yes - but only for the edges that have changed. I think someone mentioned the need for that on your other thread (Math89?). Also, you only need to do this when you want to see the effect of the lighting so you could delay updating the normals till you need to - and sometimes the averaging won't be necessary anyway.

Ah, perfect, that worked, thanks a lot .


Hmmm, sounds somewhat complicated, but I'll try it out when I get the chance. Thanks for the explanation!

Again, thanks for all the help and the awesome shader, don't know how I'd do this stuff without you!