Well that’s a darned good question. Likely, once mesh-merged, there will be no seam/gap, and then apply the texture to the merged mesh.
Without the mesh-merge… you would likely need to add the same texture to ALL (each of) the patches… and then “slide around” the textures on the patches… to match the adjacent patches.
Sliding, offsetting, scaling… textures… is done with some fancy texture properties, and with the UV’s on the mesh that the texture is applied-to. “U, V, W” are seen often in texture adjusting… and they are exactly the same as X, Y, and Z for mesh. For textures, the inventors simply used the 3 alphabet letters BEFORE XYZ.
So, do a little playground search… you will find many uAng, vScale, uOffset, wrapV <— (notice the naming convention change on “wrap” items). They are all properties on BJS rawTexture. U - V - W === X Y Z, but for textures.
Any UV on a mesh vertex… is a 2-value thing, and is like a percentage. The values are always between 0-1 inclusive. A UV of 0.2, 0.6… means the texture gets “stapled” (clamped) there… at a point that is 20% rightward from lower-left corner of texture, and 60% upward from lower left corner of texture. Not all mesh include UV’s, but they can be added to any mesh except empty/blanks.
Sorry for TMI… you probably know all that, already.
IF you could set ALL UV-kind data ON your patches PROPERLY, you would see NO texture seams, even though each patch uses an exact copy of the same FULL GROUND texture that every other patch uses. (they each use the very same Babylon.Texture object). IF you use uOffset/vScale, etc, each patch might need a COPY of the main Babylon.Texture.
To get this done sanely… it might be wise to ONLY add/start a new mesh patch… at 5% increments. In other words, always start/end patches at 5%, 10%, 15%, 20%, etc… distance from the terrain’s lower left (near-left) corner. When it comes time to set the UV’s on each patch… (or use texture vAng, uOffset, etc)… the 5% increment policy… might help to keep you from going insane.
One more miserable item: Normals. Terrain from ribbons - Questions & Answers - HTML5 Game Devs Forum
Yep, a seam. It happens because the direction of the lighting normal on ONE side of the seam… is not “averaged” with the normal on the other side of the seam. AND, with mesh patches of differing resolutions, there might not even BE a vertex across the seam from another vertex… because of a resolution diff. YIKES!
SO, all in all, half’n’half. I once did some tiled-ground experiments… and I definitely needed the “lighting normals sewing machine” to average my cross-seam normals. We/I never got it done.
This all happened about the same time in my life… when I switched from ditch weed… to kush. Although “BJS Terrain Quilter v1.0” would be NICE, and could do lots of things “automatically” for us, it’s certainly not something that my Algebra-free pee-brain could ever code-up.
https://playground.babylonjs.com/#21TQJT#55 #54, separation-gap version, too
(Control-drag active to “dolly”, “ped”, or “truck” the arcCam target. Do ya like my TV cameraman lingo? Also notice my “near-left” corner was somehow “far left”… because of some bad layout-math by Mr. Wingleberry.)
We’re only talking 2-way intersections. There ARE 4-way intersections, and at all 4-way intersections, FOUR normals need to be averaged, and that value written-to the normalKind data of all 4 verts that intersect there.
Phew. Getting a brain tumor yet, AF? (sorry)