Broken seems on terrain painting

Troubleshooting terramonkey
1

Hi all.
In my game editor which I am working on I have this weird behaviour when painting a terrain.
I have been struggling for months now to find the problem.
I am wondering if anyone in the forum has come across something similar?
I am using version 3.6.0-stable of jme3.

I am creating the terrain with a FlatHeightMap and the size is as follow:

        terrain = new TerrainQuad("terrain", 65, 1025, heightmap.getHeightMap());
        TerrainLodControl control = new TerrainLodControl(terrain, camera);
        control.setLodCalculator(new DistanceLodCalculator(65, 2.7f)); // patch size, and a multiplier
        terrain.addControl(control);
        terrain.setLocalScale(1f, 0.25f, 1f);

This is a screenshot of the problem:

image
image1920Ă—1108 385 KB

3 Likes
2

I noticed this issue a while ago, and now that I’m looking into it more, I am noticing that the issue only happens on my older maps and those terrains have only 1 noticeable difference:

I used to set up my terrains with 16 patches per terrain (with a terrain size of 512, and patch size of 128) but now I usually do terrains with only 4 patches per terrain, for less object count (512 size terrain and 256 patch size) and it seems that the broken seems no longer appear on all my newer maps with just 4 patches.

So I suspect the issue may go away if you change your 1024 size terrain to have a patch size of 512 (so it should only have 4 patches per terrain), in which case that would confirm my suspicion that its related to patch count, and if so then that could hopefully help point us closer to the source of the bug.

2 Likes
3

Awesome, let me try that and see from my side if it fixes the problem for now.
I will get back to you.

2 Likes
4

Okay I gave this a test on my editor. It however did not work.
I am even getting this problem with only 4 patches on my terrain.

image
image1920Ă—1108 431 KB

3 Likes
5

Hi @ndebruyn ,
can you show the code of how you are creating the FlatHeightMap?

It should be something like this:

public class FlatHeightmap extends AbstractHeightMap {

    public FlatHeightmap(int size) {
        this.size = size;
        load();
    }

    @Override
    public boolean load() {
        heightData = new float[size * size];
        for (int i = 0; i < heightData.length; i++) {
            heightData[i] = 0;
        }
        return true;
    }

}
2 Likes
6

You can also initialize a terrain with a null heightMap and that will create a default heightMap for a flat terrain.

new TerrainQuad(newName, newPatchSize, newTerrainSize, null);

That’s how I create new terrains in my editor where new terrains are okay, and it looks like all of my old maps that have the the issue with the seams were created in JmonkeyBuilder a few years ago.

2 Likes
8

Let me try this first and see if it fixes the problem.

9

Passing null it feels even worst:

image
image1920Ă—1108 463 KB

1 Like
10

That is strange, it looks like some code is messing with the TerrainPatchs’ locations somehow, based on that screenshot. So I think the issue I was experiencing in the past may actually have been something different.

A null heightmap should usually work. If its null then the TerrainQuad constructor calls this method:

And that should do the same as looping through and putting 0 at every index, since its a primitive float array where the default value at each index will already be 0 rather than null.

Another thing to try is removing the LODControls, and also making sure that the terrain doesn’t have multiple LOD or mulitple NormalRecalcControls attached at the same time. I don’t think those would be likely to be the cause but its still worth checking.

Otherwise It seems like something may be happening to modify the localTranslation of your terrainPatches, potentially some other code that is treating TerrainPatches like normal geometries and could be accidentally moving them by a few units and is creating those gaps between them as a result. Unlike normal geoemtires, a terrainPatch should never have its scale/rotation/size changed since they are internally managed by the terrain and things like the lodControl that expects patches to centered in their quadrants. So I would maybe also try checking the localTranslation of each terrainPatch and see if its an unusual value (i.e. a non-zero y value, or a x/z value that is non-divisible by half of your patch size)

When I first made my terrain editor, I had this issue with moving terrainPatches a lot when I had click-to-drag enabled on everything. I would frequently accidentally click on a terrainPatch in the scene and move it by just a few units when i was clicking on the terrain to paint with the brush, which completely broke the terrain because I also didn’t have an undo button at the time (and still don’t) :sweat_smile:

11

Okay cool I will check this out.
I think as a solution I can maybe after each paint re-adjust the transform of the terrain patches.
Let me see if I can.

1 Like