Well, no help on the beginner board. I have combined heightmapping and octrees to do terrain. However I am unhappy with the way I am storing the vertices for each leaf, currently just storing each triangle seperately. This is redundant and not as memory efficient as I would like. How have others tackled this problem? Perhaps just store an index array in each leaf? Compile the data in each leaf into a display list? Its more of a preference thing, but I want to hear what others have experienced please. Just need some sound advice.
Old GLman
Hi,
Somebody must have some experience in this area. This is all new ground for me. Any good advice at all?
Old GLman
In the past I’ve done the following:
Use heightmap to generate terrain tiles, each tile being something like 64x64 triangles. Those are compiled into a display list and the display list id goes into a quadtree node. Note quadtree, not octree. Since a heightmap can’t overlap itself, why bother with an octree? Somewhere I had a paper describing octree/quadtree implementations where the nodes were pointerless, using linear maths to calculate node locations in memory. But the memory requirements for a linear quadtree left me unsatisified, so I stayed with a pointer branched quadtree. Later I dumped that in favor of simple nested AABBox trees. But these projects that I’ve been doing have not been the huge world type of projects, more like Mario or OddWorld where there is a constrained space that a single character is screwing around within…
Hi, thanks for your input. Can you elaborate a bit more on the part where you said a heightmap can not overlap itself? Im using an octree because when I build the terrain from the heightmap it becomes fully spatial, not planer. Unless there is some other difference between an octree and quadtree I dont know about?
Old GLman
Hi, yes, thats a great site. I visit it quite frequently. Just wondering how that answers my original question?
Old GLman
A heightmap is a 2D array of height values. It is not possible to for a single heightmap to represent data that overhangs or overlaps any data within itself.
Ah, ok, makes more sense now, thanks.