Any (not so obvious) downsides to using a terrain mesh?

[unixfan]

For the past couple weeks, I’ve been contributing to a game engine that uses an Octree for spacial representation.

As I really love the concept (it’s blatantly easy to create caves), I’ve been thinking about creating a small level editor that is basically just a view of the engine with some simple level editing controls embedded and an “export to Panda3d” button.

Upon pressing the button, a number of scripts would be run, first exporting the whole landscape to a mesh (.obj file), then converting it to an egg file and running egg-octree on top of that.

Do you guys think this would be viable? Are there any apparent downsides, aside of LOD issues? Is there anything special about Panda3d’s own terrain system that couldn’t possibly be replicated? As trees aren’t part of the terrain system, I guess I could still use instanced tree geometry and tie them to the terrain mesh, right?

[rdb]

A few off the top of my head:

(1) Inefficient storage of data, since the XYZ positions of the terrain are all stored in 32-bit floats, whereas with terrain you can get away with just one 16-bit number for height it most cases. Both on disk, in memory, and when sending to the GPU (and in video memory).

(2) Hard to apply effective LOD to limit the amount of terrain being rendered at one time, this would all have to be pregenerated, meaning even more bandwidth and memory is used.

(3) Hard to modify on the fly, if dynamic terrain is desired.

(4) Computing collisions is expensive if you don’t have a height map (though this can be improved partially by effectively quadtreeing, but still not perfect. A hybrid solution - using a terrain mesh, but also storing a calculated height map for collisions is an option.). Especially for placing things on the terrain, whether it be trees or the character, looking up the Z position is as easy as calculating the pixel offset and reading the grayscale value at that pixel.

[unixfan]

I was aware of the LOD bit.

However. Can’t this be slightly alleviated by reorganizing the mesh back into an octree, using EggOctree?

Egg Octree

Egg Octree This code allows to split an Egg object and build an octree. What is an Octree ? (from Wikipedia) An octree is a tree data structure in which each internal node has up to eight children. Octrees are most often used to partition a three dimensional space by recursively subdividing it into eight octants. How does this implementation work ? Give it an egg object, with a vertexpool and a list of vertices. You also give a minimum cell size. A new egg object is created, with a tree con…

My main beef with simple, height map based terrains is that one can’t possibly hope to design all of the terrain in it. In our engine, I can first create a terrain from a height map (or any random noise) and then, if I find a spot I’d like to have a cave at, "punch in a few holes.

[wezu]

A mesh in egg format will take 10-100x more disk space then a heightmap (and load that much longer).

Texturing a mesh with a hole/cave can be a pain. Tri-planar texturing can help here, but it’s not free.

Heightmaps are common and can be made and/or edited with third party tools.

One big mesh could be faster to render then one cut in 16 parts or more (depends on how many other meshes you got).

These flaws are not game-stoping big.