Chunk-like map using heightmaps - chunk edges don't align

[Sme 3]

I have a rather large map, and am therefore loading it in chunks 16x16 units in size. At any given time, there are are a total of 25 chunks loaded in a 5x5 grid.

Each chunk has its own mesh, created using BABYLON.Mesh.createGroundFromHeightMap, and then I position the ground meshes at the appropriate locations.

To create the height maps, I took the original map and cut it into chunks as well, and then pass it to each chunk. However, the edges of the ground meshes do not align, particularly if the edge has a steep slope. I attached a screenshot to better understand what I'm talking about.

 

Whats the best way to fix this? Is using 25 ground meshes at a time a bad idea (should I only have 1 ground mesh at any given time)?

 

Thanks

[TheSkrapper 1]

It could be that your textures are being smoothed before they are used as the height map.  Try some code similar to the following...

var convertToFlat = function () {

for (var index = 0; index < scene.textures.length; index++) {

scene.textures[index].updateSamplingMode(BABYLON.Texture.NEAREST_LINEAR);

}

}

 

scene.executeWhenReady(function() {

convertToFlat();

});

 

return scene;

I had an issue with textures being smoothed and solved it this way.    See lines 21-31 on https://playground.babylonjs.com/#MFTLRX#12

[Wingnut 2301]

Hi guys.

Also remember... when dividing big maps into little ones... the STARTING row and column of ANY "next" section... is an exact COPY of the row and column... from the ENDING row and column of the previous section.

In other words, at any "seam"... the ending/starting row/col of verts, needs to be an exact copy.

To do this, when cutting up the big map, make your ending row and column... be ONE row/col more (longer and wider) than you'd expect.  The ending row and column of any section... must be an exact copy of any beginning row/column.

Wherever a seam happens, there are two identical vertices:  the ending one from previous section, and the beginning one for next section.

https://playground.babylonjs.com/#21TQJT#56   (version #55 closes the gaps, but you can still see the seams, due-to lack-of normals-averaging across the seams.)

See how the seams... have the exact same row and column of verts... on each side of the seam?  That's needed... to make them match at the seams.

Now look at lines 239-251 of my "cutter".  See all the col+1 and row+1 stuff in there?  That's for ending the row/col of PREVIOUS section/cell, with the exact same verts as the starting row/col of the NEXT section/cell.

I also have "showNormals" activated (the white sticks), and as you can see, the lighting normals across seams... can be a challenge.  I was never successful at averaging the two normals on each side of the seams, or with averaging FOUR normals at every 4-way corner.  But, I didn't try too hard.  Most people have gravitated toward "infinite" terrains... instead of tiling.  https://www.babylonjs-playground.com/#FJNR5#218  (use arrow keys)  (see line 48 - BABYLON.DynamicTerrain)

I don't know much about infinite terrains... like if they are a good alternative to tiled terrains.

All in all, I think you have positional mis-match at seams... due-to NOT "going one row/col further-than-expected" when cutting-up your big map... into cells/tiles.  But I could be wrong.  Remember...ONLY end your cell-cut... one row/col longer/wider than expected.  Start your cell-cuts exactly where you would expect.

Threads of interest: 
http://www.html5gamedevs.com/topic/31567-terrain-from-ribbons/?tab=comments#comment-181539
http://www.html5gamedevs.com/topic/34397-solved-mesh-editor-edit-ribbon-vertices/
http://www.html5gamedevs.com/topic/25568-matching-neighboring-geometry/

Rare forum visitor Kostar111 once did some tiled ground work... https://doc.babylonjs.com/resources/offsite_tutorials_list#célian-garcia-kostar111-home-website-unknown

 

[Sme 3]

Thanks for the tips. 

After trying to 'overlap' the edges of each chunk, I too had an issue with shading, particularly areas where the slope was steep.

After some fiddling around, I managed to find another solution. What I did was created another canvas element on the document, as well as an image element to store the entire height map. Then I draw the image onto the canvas, based on which part of the map needs to be loaded https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/drawImage (the canvas' context's API makes this very easy). Once the image is drawn on the canvas, I create the height map using canvas.toDataUrl(), instead of the original heightmap .png URL. Also, this means I only have one ground mesh, instead of 25.

I still don't have code for loading new sections of the map (ie, re-drawing he image on the canvas with the new offset coordinates, then re-creating the ground mesh with the new dataURL.) This shouldn't take too long, once I finish I will test and see how the performance is. (hopefully it is a smooth transition! Perhaps someone who understands babylonJS more than I will already know if this is a good solution or not)

[Nodragem 27]

I guess that there are two things in play:

- the vertices needs to be exactly the same at the seams, and you may have not cut your mesh correctly (but you seem to have resolve this issue?)

- the UVs at the seams also need to be identical, and you may need to set them up manually to be vertical, looking up (which is the simplest solution), that would explain your problem with shading

For your question:

23 hours ago, Sme said:

Whats the best way to fix this? Is using 25 ground meshes at a time a bad idea (should I only have 1 ground mesh at any given time)?

That depends very much on the number of vertices. For simple meshes (small number of vertices), It is good to merge them to one mesh to decrease the number of draw calls (CPU to GPU requests); however, for complex meshes (after a critical number of vertices), it is better to divide the mesh into several meshes. I am not really sure what is the rule of thumbs for the "critical number"; probably depends on the device you target.