Three Terrain Questions


i´m currently focus on terrain programming, and i have three questions:

  1. I want to have convincing collision detection / and response in my terrain.
    How could i realize that? It is a good idea to use a decimated mesh of my terrain to represent the collision data? And what kind of space partition technique is recommended? I thought about a quadtree.

  2. I want to incorporate my radiosity processor for terrain lighting. But i´m afraid that the lighting looks faceted (since the normals for radiosty are calculated per surface and not per vertex (which procduces smoother lighting)).
    How could i arrange my radiosity processor to achieve good and smooth terrain lighting?

  3. For rendering, which kind of partitioning tree ist better: Octree, Quadtree, or yet another tree?

Would be nice if i get some ideas and input,

Thanks in advance

  1. Not related to this forum.
  2. Don’t know.
  3. This actually depends on what algorithm you are implementing. Old quad tree based algorithms are not much good. If you want a progressive mesh based algorithm, then ROAM/ROAM2 (M.Duchianeu et. al.) will suffice your needs pretty well. But beware, its a CPU intensive algorithm and as yet there has been no effort (to my knowledge) to incorporate GPU based calculations in it. Another algorithm that has gained popularity recently is geometry clipmaps by H.Hoppe and A.Losasso. Also remember that quad trees are essentially two dimensional. That is okay if your simulation is ground based. But can pose problems in other scenarios. But that can be handled by designing a heuristic, suitable to one’s implementation, to extend the quad-tree in three dimensions. A poor heuristic, can however, lead to poor culling, in which case a octree might be more feasible. If you plan to use these for mere space partitioning than you have to use some other algorithm for mesh refinement and tessellation, like the ones i mentioned above.

based on your question, I think this would be a good place to start:

  1. i use newton for this and use a “newton collision tree”
  2. i would find a new lighting technique
  3. i like the original Geometrical Mip Mapping, it still runs fast on current hardware and is well suited to games (e.g FarCry used GeoMipMapping) and it is fairly easy to code. Quadtree based frustum culling is also recommended by the original author Willem H. de Boer

Originally posted by bulldogs:

2) i would find a new lighting technique

How about you average out the face normals per vertex and use them for smooth shading?

Originally posted by Fastian:
[quote]Originally posted by bulldogs:

2) i would find a new lighting technique

How about you average out the face normals per vertex and use them for smooth shading?
[/QUOTE]That would mean using “per vertex” normals - which is what he can’t do.

Malakai2007 perhaps you can subdivide your terrain (even if it’s just a relatively small/localised area) to smooth out the actual geometry while doing your lighting calculations.

If he is using a height map, then sub-division is limited by the resolution of the height map. Further sub-division is futile and also produces geometry aliasing artifacts.

I think what rgpc meant was to subdivide the terrain further just for the radiosity processor, store the result in a lightmap and apply this to the original heightmap.