Seams in stiched Terrains

[Onkelpoe]

Ok, latest version crashes at the same point (Duplicate Borders, re-packing tile 2,3 at 88%)
Logfile/debug.dat is in your e-mail inbox

Kind Regards!


edit: I hope there will be a solution in a few days... had to finish this project 2 weeks from now oO

[Aaron]

Hi Onkelpoe,

Thank you for the log file. The log showed the calculation finished, but then crashed during the finalisation stages (the progress bar deliberately lags behind somewhat, so even though it said 88% done, it was finished). In the latest dev build (14.10 build 2) I've added more debugging to the finalisation to help me work out which routine in the finalisation section is breaking. Please download the new build, give it a try, and send me the logs again if problems persist.

Best regards,
Aaron.

PS: I'll do my best to get this fixed ASAP.

[Onkelpoe]

Thanks a ton Aaron ! I see, you put in much effort and your support is great.
I mean it is not that common to have a developer, who actually builds new versions that quick, trying to solve/debug a problem.

Thanks again

[Onkelpoe]

Ok - first of all, the good news: Tested on two different PC´s and L3DT crashes no more, when finalizing "duplicate tile borders"

But there are also bad news. Seams are still there in normal maps... Maybe I do it wrong?

My workflow looks like this:

1. import 8192x8192.ter heightfield
2. generate Normal map (1:1 ratio, no tiling)
3. Export optimized meshes "11" error, "2048" tiling, Y=Up, DX, center=origin
4. With "Terrain Normal" layer selected, I go "Layer->duplicate tile borders" with "2048"
5. Go "Export layer" with "Split" "2048", PNG

Importing into Unity 3D, as usual...

It looks like, there is something broken or some settings were changed in the latest L3DT version.
The meshes are fine, when placed side by side, no visible seams...

But when apply the normal map, it is just a mess (see image "wrong")

On a Unity terrain (generated from a .raw heightfield, not a mesh exported from L3DT) the same normal maps seem to be ok (still having seams, but not messed up)
So maybe there is an issue with the mesh-exporter?!

[Onkelpoe]

Here are the normal maps, the lower Image is after generating terrain normals and export the optimized meshes
, the Upper Image is after calculation of duplicate tile borders...

(Images showing the far right border of a 2048x2048 normal-tile, zoomed far in)

[Onkelpoe]

I´ve some old test project, with meshes calculated in a previous L3DT version, they seem to work with the normals from
the latest build... but - still seams

they look "bigger" than before...

[Onkelpoe]

Meshes are behaving very strange! Scaling is totally off in .DAE ... at least, when import into Unity3D.
Dae I can not even see it in Unity3D

BTW: I saw you made something to export to T3D (an 3D engine, I guess)
Would be awesome to have some export functions for Unity3D or UE4 (like axis, tangentspace, scaling and so on...)

tried to apply the normal map to a "L3DTmesh" in a different programm - but the normalmap shows no effect in it, too.
When appling the normal map to a "non-L3DT-mesh", like a simple 1x1x1 cube, it works 100% (!)

I took a normal map, that I know is working - but it does not, when applied to the meshes, exported from L3DT - no matter, if .obj, dae, 3ds and
whatever settings - what´s wrong here ???

Maybe UV´s informations are missing or somehow broken in the latest build?!

Cheers!

[Telarus]

Hey there. I've run into the same seam problem when working with UE3. The causes are various, but I foudna blog post that seems to address it for Unity. Hope this helps:

http://scrawkblog.com/2013/10/17/terrai ... -in-unity/

Here's a good post on how it worked in UE3, if that helps: https://forums.epicgames.com/threads/95 ... e-textures)

Still haven't run into this in UE4, but I really just got it this month.

[Onkelpoe]

Hey Telarus,

I just read the Blog quickly and do not Understand it Yet.
For example, what does the author mean by "control map"? is it a splat map? normals? colormap?
I will see, if the example project file will give some answers
Guess, I have to take some time.

Another thing is, this article/blog is all about a "unity terrain object" - but what about a mesh / tiling meshes?

My goal is, to provide some tiling unity terrain and meshes, that work in unity out of the box.
So no scripts or additional downloads...

Thanks for pointing me on this one, Telarus!

Seems, it will not work, which is disappointing....

Is it impossible to prepare tiling mesh/normal/texture maps with L3DT to work out of the box in Unity3D engine?

Aaron, any (final?) words on this?



Best regards

[Aaron]

Hi Onkelpoe,

Sorry, I've been a bit unwell for the past few days, and been unable to keep up with happenings the forum. I'll try to answer as much as I can now.

The seams would appear to be caused by the massive changes in gradients at the edges of your bump maps (those pinks vertical stripes). Is there a way you can send me the original heightmap TER file (upload to dropbox/etc, perhaps?) I'd like to know if L3DT is generating the normal wrong, or if the data file has a step in it. By the way, is this Mars/Lunar topography, by any chance?

Meshes are behaving very strange! Scaling is totally off in .DAE ... at least, when import into Unity3D.
Dae I can not even see it in Unity3D

L3DT scales the mesh files to metre units, which may not be what Unity3D is expecting. There is no general convention for the distance units for mesh files, and few explicit state units, so unless the mesh was made specifically for a particular engine, the scaling will be wrong. Either that or I'm just doing it wrong.

BTW: I saw you made something to export to T3D (an 3D engine, I guess)
Would be awesome to have some export functions for Unity3D or UE4

Sure, I'll put it on the to-do list.

I took a normal map, that I know is working - but it does not, when applied to the meshes, exported from L3DT - no matter, if .obj, dae, 3ds and whatever settings - what´s wrong here ???

Hmm...will have to look into this further. I'm not sure bump mapping was explicitly supported for all mesh format exporters (perhaps even 'any'), so you may need to manually edit the mesh materials to add the bump map textures. Definitely the OBJ/MTL exporter doesn't write bump map filenames; not sure about the others yet.

Maybe UV´s informations are missing or somehow broken in the latest build?!

If the UVs are there for the texture, they're there for the bump maps too. However, if the mesh material definitions don't include the bump maps, the UVs aren't going to do very much.

Anyhoo, starting to nod off. Please send the TER file by whatever means practical, and I'll have a look at it tomorrow night.

Cheerio,
Aaron.

[Onkelpoe]

For the "UV-issue":

No, the UV´s are also missing for the "texture map" (as well as for the normals). This is true for all meshes, exported in whatever format from latest build.
When exported from previous L3DT version, they all work.

What do ya mean about "bump mapping"?
I did export normals, like I did before (without any "apply bump option", when gernating the normal map)

My .ter heightfiels is about 130MB in size, 8192x8192, got an 8193x8193 version, too.

This "moon/mars" surface is not from DEM or something like that - it´s hand-crafted and not related to real-world-data.
I want to use this for my first commercial project now (if the tiling finally works...), so if I should upload it into drop-box, I need you word, you do not sell it, hehehehe
(I could provide a normal map, generated from another app, too)

I tested tiles from the "non-L3DT-generated-normal map" and they also look messed up on fresh exported the meshes....but looking good on meshes from same heightfield, created in another app.. So I am prety much sure, there is something wrong with them, when exporting from L3DT


Have a good one

[Aaron]

Hi Onkelpoe,

You have my word that I will not sell, distribute or otherwise make available your data, and I will delete the file once I've verified that the normal map generator is (or is not) working properly. The 8192x8192px heightmap should be fine.

Edit: Thanks for the files. I'll let you know what I discover as soon as possible.

No, the UV´s are also missing for the "texture map" (as well as for the normals). This is true for all meshes, exported in whatever format from latest build.
When exported from previous L3DT version, they all work.

Are you sure you still have the 'Texture coordinates and materials' checkbox checked in the mesh exporter? If not, UVs aren't included. When I test the mesh exporter, UVs are still included when 'Texture coordinates and materials' is checked.

By the way, the mesh decimator plugin (which provides the exporter interface, generates the mesh & UVs, and cuts & exports the texture/normal map tiles) hasn't been changed since October last year, and the 3DS, OBJ, X and DAE plugins haven't been changed since July 2011, so nothing that would (should?) affect the mesh exporter has changed in the latest build.

What do ya mean about "bump mapping"?
I did export normals, like I did before (without any "apply bump option", when gernating the normal map)

I'm sorry for the confusion; I was using the term bump maps interchangeably with normal maps. Anyway, my point was that even though the mesh exporter will export the normals map files, it will not actually include the relevant declarations of the normal map in the material definition in the mesh files. Am I right to presume that you are including the normals maps in the materials yourself in Unity3D?

I tested tiles from the "non-L3DT-generated-normal map" and they also look messed up on fresh exported the meshes....but looking good on meshes from same hieghtfield, created in another app.. So I am prety much sure, there is something wrong with them, when exporting from L3DT

I would guess that's because we're using different coordinate systems. L3DT puts the origin (0,0) coordinate at the bottom-left / southwest corner of the map, whereas many applications put (0,0) at the top-left / northwest. You may need to flip the normals map image vertically, and, if you're working on a sub-region of the map, also re-calculate the sub-region's Y coordinates to be from the bottom rather than the top so that you capture the right area of the normals map.

Best regards,
Aaron.

[Aaron]

Hi Onkelpoe,

Interesting. You may wish to have a close look at the normals map. To do this, select the 'terrain normals' tab, then select the 'View->Set view area...' menu item. Enter the X coordinates from 2972 to 3172, and the Y coordinates from 7068 to 7268. This will centre the view on the seams at x = 3072, y = 7168. This is what I find:

If I pan around, I find another set of seams crossing at x = 2048, y = 7168:

What this means is that the normal map has seams repeating at intervals of 1024 pixels. Assuming there's no bug in L3DT's normal map generator (which I don't immediately discount), this suggests there are subtle steps in your heightmap every 1024 pixels. Let's have a look in the heightmap (back at the first field of view, centred at x = 3072, y = 7168):

Nothing to see here, but then again, greyscale palettes aren't particularly good at showing subtle differences. What if we select the generally overlooked 'View->Display effects->Show gradient colouring' menu option? This calculates the difference from one pixel to the next, and overlays the magnitude of the changes as a colour using a rainbow palette:

Lo and behold, there are the subtle seams.

Has this heightfield ever been separate 1024x1024 pixel tiles? If so, what file format was used, and how were they joined together? If not, do you mind telling me which application was used to make the 8192 dataset?

I don't have a great solution for removing these seams, but you can try the 'Operations->Heightfeld->Edge blending->Blend tile edges' menu item. Set the X and Y tile size to 1024, and the blend depth to something small (e.g. 8 ). This will remove the step, but I just noticed it has the unfortunate side-effect of making the pixels on either side of the seam equal, so you trade steps into little flat strips. Hmmm....will have to think about it further.

Best regards,
Aaron.

[Onkelpoe]

Hey Aaron,

it´s all been done in WM2.3 / 3.01 I have also extracted a normla map from WM, that shows no seams.
The heightfield wasn´t tiles 1024x1024 before.. no clue, why this is showing up.

The 8193x8193 does not have these, right?!

The meshes do not work with the normals and there are still seams, when placing meshes or terrains, generated from heightfields side-by-side in unity...
Before the latest build, there was no need to compute the normals - just assing to a material/shader in Unity, let Unity "Fix" them automatically.
I am useing the same Unity version, like before... So I guess, it´s the UV export thing, maybe I got that wrong

UVs: I did not checked "Export Texutre UV option" - because I just selected 1 Aux. map (the normal map) and L3DT says "Can not export UV, when no Texture map present"
(not exactly these words, but likewise)

I will check again tomorrow



Cheers!

[Aaron]

Hi Onkelpoe,

The 8193x8193 file has no seams (phew!) Which file was the original, and which was resized? How did you do the resizing? [ducks, and hopes the answer is not L3DT]

Have you succeeded in exporting the 8193 mesh from L3DT?

UVs: I did not checked "Export Texutre UV option" - because I just selected 1 Aux. map (the normal map) and L3DT says "Can not export UV, when no Texture map present"
(not exactly these words, but likewise)

Okay, this means you have to generate the texture map before the mesh export. That's a bit of a design flaw, where I originally assumed the UVs would be used for textures, not for normal maps without textures. I'll pencil this in for a fix. Anyway, once you've got a texture map, check that option in the exporter, and you should have your UVs back. Again, this hasn't changed in at least a year.

By the way, could I impose on you to test the mesh exporter using a map generated entirely in L3DT? (say a random 4096x4096 heightfield should do, with 2x2 tiles of 2048, and don't bother with duplicating tile borders). If you still get seams in Unity3D, then the mesh exporter has a problem. If not, well, let's see.

Cheerio,
Aaron.