Hi,
I am currently searching for ways to implement terrain rendering for a specific case. We’re using JMonkey for GeoVisualization (or at least we’re trying to do so). Besides the geometry of buildings, we have terrain data including textures. At the moment I’m working with a 2km x 2km area with textures available for tiles of 100m * 100m. While it’s obviously no issue to load the heightmap for such a terrain at once, dealing with the textures is a whole other topic it seems. I have been using a TerrainQuad so far, which worked well as long as I didn’t have the tiled terrain textures. In the final version, the terrain textures should be dynamically loaded at runtime, depending on what parts of the terrain are currently inside the view frustum.
Searching for solutions to integrate such an approach brought me to TerrainGrid, but it seems to be deprecated and I seem to be a little stuck at this point. Will it be necessary to implement something on my own? Would TerrainGrid even have been the right solution for this? Any other current solutions readily available?
Would be great if anyone could point me in the right direciton. Thanks 
Textures are drawn using UV coordinates (texcoords) - if they are between 0 and 1 - no tiling is needed. If they are not (e.g. world coordinates) they require wrapping. The mesh contains this data, and you can set that data, too, if you prefer. It could be as simple as replacing odd and even numbers for 0 and 1 (a modulo operation would be your friend here).
TerrainGrid is deprecated because it lacked a lot of functionality I guess and was intended to be replaced, but as time went by, the core developers only wanted to keep the core updated, and not 5 million different “plugins” so the engine itself would be given the time it deserved.
There are many terrain pagers around, I wrote one myself, but I’m a little stuck understanding why your current approach doesn’t fit the bill. Could you try to elaborate further?
https://github.com/jayfella/TerrainWorld
Hi jayfella, sorry for the late reply, have been busy with other stuff.
I see that you suggest simply adjusting the texture coordinates if they do not match the necessary range anyway. However, if I see it correctly, using only a TerrainQuad limits the number of textures that can be used because the original idea is using layers of textures that are scaled to the full quad. Is this correct or am I maybe getting it wrong? If I can arbitrarily handle the textures on a terrainquad I totally see how I could implement some kind of paging.
However, I guess I would still run into problems when working with larger terrains and thus an arbitrary amount of large heightmaps that are connected to each other. Is this where TerrainGrid would come into play?
Sorry if my questions are dumb, I’m really just starting with terrain stuff
When you talk about textures, it pretty much comes down to materials and shaders. They are what determines what texture goes where. The terrain quad is just a mesh. It describes a shape and maybe additional data per vertex of that mesh. The material dictates what texture is displayed.
When you have a large height map or many joining height maps you use multiple terrain quads but can use the same material on those quads.
A material would change the texture at a certain height or angle for example. Or change based on some data per vertex. For example you could have a color per vertex and tint the texture with that color.
The point is that you understand each element and the part it plays.
The mesh is the shape. The material is the instruction set to display textures and colors on that mesh.