L3DT Users' Community

Edit: hopefully maybe solved, enabling "stichtileborders" in the extensions > sapphire > terrain > texture seems to have helped.

Hello, I just started using L3DT so forgive me for my noobishness. I'm using L3DT to edit a heightmap for a ArmA 3-modification (a terrain obviously).
I've encountered a problem though, when viewing the terrain in the 3D-editor in L3DT the textures have weird edges here and there and seem to be in the wrong place, like this (seems to be in a grid-shape):



Now, this "clipping" or whatever I should call it is not there on the actual texture-file. Furthermore, just as I switch to viewing the texture-layer in the 3D editor it seems to be correct for a split second before changing to what you see in the picture (switching back and forth again doesn't make this happen again though).
Is there any way to counter this? Thanks

Alright, I believe I solved it. For anyone with the same problem, the problem seemed to be the generation of MipMaps. I edited the texture file and saved it as a .dds and generated mipmaps and then imported it (it ended up upside down though, so I had to flip it and save it again) and now I don't see those seams anymore.

Hm, after getting the pro trial version and resizing the map to be 6144x6144px (and getting a new texture map the same size) the problem is back even when saving the texture map as .dds.

Please someone let me know if you have any solution for this I find it strange that it worked at a smaller resolution and now suddently doesn't. What am I doing wrong here? Is it related to terrain/texture resolution or something perhaps? or DDS-settings?

Hi McNools,

I apologise for the delay in my reply. The seams in the texture are a rendering artefact that occurs when displaying tiled textures. To properly render tiled textures, each tile has to contain an extra row and column of data from the neighbouring tiles so that the border colours exactly match. L3DT doesn't do this by default because it's inefficient when you're generating or modifying the texture to keep having to check if the calculation is near the edge of a tile, and if so, write the same value to the neighbouring pixel in the next tile also. It's far easier to add the extra row/column of values if or when they are required. For example, the 'File->Export->Export overlapped tiles' menu option allows you to export a copy of any map as a tiled map, with the required duplicate values in each tile (see user guide). Similarly, Sapphire has an option to do this (as you found), but it's off by default because it adds some lag when loading texture tiles (e.g. moving around the map). Also, since Sapphire is just a part of the toolchain and not the final 'target' renderer for any users, I considered it more important for Sapphire to be faster than it is to be free of all rendering artefacts. Both of those options leave the original texture map in the project unchanged, so no data is modified or corrupted by the addition of the duplicates values in the tile borders.

I hope this has helped to explain what's going on. Please let me know if you have any further questions.

Best regards,
Aaron.

Thanks for the excellent and detailed reply! fortunatly my computer can handle the extra lag pretty good (and right now I'm mostly sticking to smaller areas for fine-tuning), but thanks!

So, I haven't had time to work on my map for a while, so this reply is a bit late. Using the stitchtileborders-setting was indeed pretty slow, so I would like to be able to bypass that. I can't seem to figure out how to export/import the tiled texture properly though. If I export the overlapped tiles I get a bunch of files (one for each tile, as expected), so.. how do I import these again so that the texture map ends up properly with no stitch-problems?