Hi Onkelpoe,
Thanks for running that test. I think we're nearly at the bottom of this, but I need to ask for a little more of your help to confirm my suspicions, if that's OK.
Onkelpoe wrote:But: When apply the “TX” Texture maps, seams occure.
...
In Unity3D I exchanged the old “TX” with the new “duplicate borders” ones – but still seams in the texture map…
Before I go on, I don't think you need to bother with the duplicate tile borders feature any more. The seams you're seeing aren't of the sort that can be fixed by that function.
I've seen those sorts of seams before when originally developing Sapphire (fixed nearly a decade ago). I've also seen them in other game engines I shan't name. What's going on here is that the texture coordinate wrapping mode in Unity3D is set to 'repeat' instead of 'clamp', so that when the U or V coordinates reach 1 at the tile edge, they wrap around to 0 and sample the opposite side of the texture map. If you set the coordinate mapping mode to clamp, the problem will go away. How you do this in Unity3D I have no idea, but in Sapphire I had to do this:
- Code: Select all
glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
(Yes, that's oldschool OpenGL. Not using OpenGL 3/4 yet.)
Of course, that's assuming there are no seams in the texture map as exported from L3DT, which I'm prepared to believe but you may want more convincing. To test this you could paste two or three of the mesh's texture tiles together in an image editor, to see whether there are seams at the join (and I mean those really strong one-pixel wide seams that you saw in Unity3D). If there are no seams, then the problem is not the data, but the code that renders it.
Onkelpoe wrote:3. Why there is a (normal map) seam problem with my project???
I'd appreciate it if you could run a little test using World Machine. I know that the normal map of the 8192x98192px map that you already generated with WM was clear of seams, but I'd like to test whether WM will show seams when working only with the heightmap file, not with the rest of the generator network. Could I ask you to create a little WM graph where you use a file input device in WM to load that 8192x8192 heightmap TER file, then generate the normals from that, then save, with no other filters? If WM also produces seams in the normal map when generating straight from that TER file, then the problem is not in the normal map generators or file exporters of L3DT (or WM), but in the TER file itself. If this is the case, then we can tackle how the TER file came to have seams in the next installment of this saga.
Onkelpoe wrote:One thing to mention: I had to set the “pixel error” to “250” to get around 3k tris. When
targeting the same number of tris from my 8192x8192 heightfield, I have to set the
“error factor” to “12”. Seems a bit weird to me, that a 4096x4096 heightfield produces
a higher resolution, than a 8192 one… or do I misinterpret this? (When setting error
to “12” for the 4096k heightfield, I get Millions of tris)
That's nothing to worry about. This just means that the map you made in L3DT was rougher and/or steeper than the WM map. If it's a rough, steep map, then the tessellation error will need to be higher to keep the same triangle count. Or, put the other way, if you use the same tessellation error on a smooth map and a rough map, then the triangle count will be larger on the rough map and smaller on the smooth map.
Onkelpoe wrote:I want to import this normal map in L3DT as" Terrain Normals" - but could not find a way... When choosing "Import custom map layer", there
is no choice for "Terrain normals" (all other kinds of maps are present)...
Some magic here. Use the "Import new map layer" option as you were, set the layer name to 'TN', and the layer type to 'normals map'. This will overwrite the terrain normals (
documented here).
Anyway, thank you for your patience, and if you have time to run those tests, thank you doubly so.
Best regards,
Aaron.