I’ve once worked on a terrain editor, several months ago. It worked using the PNMPainter on a GeoMipTerrain, which worked quite well. If you keep your terrain large or make sure you don’t update the entire terrain when painting, the performance would be reasonable.
About minimaps: mavasher wrote a minimap class, which is included in his island demo. I think he also posted it separately in this thread.
…another approach could be using offscreen rendering and a shader, but this would be… kinda inefficient. Using DirectGui to place stuff on a CardMaker card would be better.
I see. Yep, I have downloaded Mavasher’s code. But one question remains: How are blocks indexed in GeoMipTerrain, and what are their coordinates relative to the origin of the node representing the entire terrain?
The blocks are indexed from 0 to ((heightmapsize - 1) / (blocksize - 1) - 1).
Use getBlockFromPos to retrieve a 2D-Vector with the block indices (x, y).
If you have the block indices, you can retrieve the nodepath of those blocks using getBlockNodePath.
The terrain origin is not at the center of the terrain, but at (0,0).
Though, each block does have its origin at the center of the block, for convenience. So, getBlockNodePath(0, 0).getPos() would return Point3(8, 8, 0) with a block size of 17x17 (which is the default).
PS. The function terrain.getRoot().ls() will print out all the terrain blocks with their indices. You will see blocks named like gmm0x0.
In that case, do blocks contain one tile or more than one tile in the terrain, where one tile represents the geometry contained in one quad in the region of the terrain with the highest LOD?
And I thought blocksizes were supposed to be in powers of 2?
I’m not sure what you mean. Can you elaborate this some more?
Righto, sorry. Internally, GeoMipTerrain indeed stores them as powers of two. But it depends if you talk about quads (e.g. 16x16 quads), or about vertices (like 17x17 vertices). In my post I was referring to the block size as vertices.
It doesn’t matter actually. The GeoMipTerrain doesn’t mind whether you pass it powers of two or powers of two plus one, it will automatically correct it to a power of two.
PS. With heightfields, the size does actually matter and really needs to be a power of two plus one (like 129, 257, etc.). If the size of the specified heightfield is not valid, it will resize it using a gaussian filter. This is very slow and might also lead to wrong proportions.
There has been a bug in this heightfield size detection system which has been fixed in 1.5.3.
Depends.
If you do getBlockNodePath(0, 0).getPos(), it will be relative to the block center.
If you do getBlockNodePath(0, 0).getPos(terrainRoot), it will be relative to the terrain.
If you do getBlockNodePath(0, 0).getPos(render), it will be absolute.