I’m trying to create some large scale (4-10 kilometer-ish) sized terrain’s from real terrain data. The raw terrain data (heightmap and texture) I am working with is at a native resolution of 4 pixels per meter. In the experience I am working on users are able to zoom out to a birds-eye view but also spend a lot of time wandering around on the surface of the terrain. Just to make things even more difficult, my experience will be streamed over the web, so users need to start with a low quality version of the terrain and dynamically download higher levels of detail for only those areas that are necessary. I’m wondering if anyone has suggestions as to the best approach to build such a terrain.
So far, the approach that has worked best for me is to section the terrain up into 6 or so giant tiles. These tiles are crated from a reduced resolution version of the raw heightmap, but I have found that even at this reduced resolution things still look pretty okay, so I don’t do any dynamic updates of terrain geometry. The 6 tiles also have a reduced version of the terrain texture. As one would expect, this looks decent from a far enough distance, but at close range is nothing but a giant blur. To compensate for this, I download high resolution image tiles at native resolution and strategically splat them onto the terrain nearest the camera. This looks pretty good, but I still get seams where the splats meet (these are especially bad at the borders of terrain tiles). I have used the SetNeighbors function to match LODs between tiles and also ran a script to match the vertices of neighboring terrains exactly to prevent tearing between the meshes. I think the splat seams I am seeing may be due to one of the following: aliasing at the edges of textures due to compression, aliasing due to splat blending, a misunderstanding/bug in the way I am applying the splats to the terrain.
A couple of other challenges with this approach are:
- My raw terrain heightmap and texture are not square or easy multiples of 1024. This means that I have to crop and resize segments in order to coerce them into 1025 pixel squares for the unity terrain engine.
- Since the user can see large expanses of terrain, all of the terrain tiles must be viewable at all times. I’m sure the built in LOD system helps reduce the poly and texture load of tiles off in the distance quite a bit, but I still worry about performance costs of having so many terrain tiles/textures active at once.
The following paper presents what could be an awesome technique for handling large scale terrains, but it’s implementation in Unity may be beyond my current resources. I really like how vertices merge smoothly between different detail levels. In an ideal world I would love to use something similar to this and dynamically stream in different segments of the Quad tree over the web as required. There are also some cool video’s linked at the end of the paper.
http://www.vertexasylum.com/downloads/cdlod/cdlod_latest.pdf
And a cool playable demo