On Fri, Apr 28, 2000 at 05:09:18PM +1200, Oliver Batchelor wrote:
> I am looking at writing some 3d landscape code for an opengl game im
> writing :)
> I have had a look at tuxracer and I was wondering what techniqes were
> being used in the tuxracer 3d terrain ?
[Sorry for the delay in replying; I had to get my second (and last!)
school project out of the way over the last couple of weeks. Now I just
have to write a thesis. :)]
I assume you're referring to the adaptive level-of-detail stuff in Tux
Racer. For that, I used Thatcher Ulrich's implementation of the
quadtree-based technique of Lindstrom et al., "Real-Time, Continuous
Level of Detail Rendering of Height Fields" from SIGGRAPH '96. Thatcher
wrote a good article describing the technique; it's at
Apparently games like Starsiege Tribes use an algorithm like this one.
A few weeks later Bryan Turner wrote a Gamasutra article describing the
ROAM algorithm, which has gained a lot of popularity. AFAICT, its main
advantage over the quadtree-based schemes is that it produces an
"optimal" mesh (over the family of meshes that it can generate) for the
chosen error metric. Here's that article:
The original ROAM paper can be found at
Hugues Hoppe has also done a lot of work in this area. I recently
implemented the Progressive Mesh construction algorithm, which works
with arbitrary meshes, not just terrain, and gives excellent results.
Hoppe's web page is
Some of my results with Progressive Meshes are at
Note that I didn't implement the view-dependent extensions to
Progressive Meshes. Also note that PMs are more difficult to implement
than the other algorithms, so if you're just dealing with heightfields
I'd go with ROAM or the quadtree algorithm.
Hope this helps,
Jasmin Patry Master's Student, Dept. of Computer Science
From: Steve Baker <sjbaker1@ai...> - 2000-05-07 04:36:03
Jasmin Patry wrote:
> Note that I didn't implement the view-dependent extensions to
> Progressive Meshes. Also note that PMs are more difficult to implement
> than the other algorithms, so if you're just dealing with heightfields
> I'd go with ROAM or the quadtree algorithm.
Note also, there is a point where it's "good enough" - and when effort
levels are limited (as they always are in OpenSource games) - there is
little point in complexifying the code beyond where it needs to go.
One problem with many of these mesh techniques is how they cope
with things like 3D objects planted onto the terrain. Whilst the
flexing and bending of the terrain as you move towards it can
be pretty invisible, if a tree is progressively covered or
uncovered by the terrain - or if it rides up and down on the
terrain skin - then it can be rather objectionable.
This can also cause problems with collision detection for other
objects far from the player - and causes 'interesting' issues
with network play.
All these things can be resolved - but they sure can complicate
matters if you don't need that complexity in the first place.
K.I.S.S - Keep it simple & stupid.
Steve Baker http://web2.airmail.net/sjbaker1
sjbaker1@... (home) http://www.woodsoup.org/~sbaker
Get latest updates about Open Source Projects, Conferences and News.