RE: [Algorithms] ROAM

[Tom F. <to...@mu...>]

You haven't mentioned the hybrid of geomipmapping and VIPM, i.e. you do
(non-morphing) geomipmapping, but the transitions between levels of detail
are done with VIPM, so there's less popping.

Definately search through the archives - there's been tons of wide-ranging
discussions about this. I think the current consensus is:

ROAM: excellent quality for a given number of triangles, but speed is hard
to achieve with the standard algorithm. Good for changing landscapes (i.e.
blowing up hills, etc)

ROAM meets VIPM: I'm not sure about the status or details on this - it's the
ROAM principles, but with far more precalculation. Sounds promising.

Geomipmapping: very fast, works with changing landscape with minor work,
otherwise data can be completely static.

Geomipmapping with VIPM: transitions between LOD levels are done with VIPM,
rather than just swapping in different index blocks. Reduced popping means
fewer triangles can be used for equivalent quality (or higher quality for
the same tri count). Works with changing landscape.

Quadtree VIPM: similar to geomipmapping with VIPM, but each chunk in the
landscape has custom tesselation, rather than the generic geomipmapping one.
Seams are fixed up with flanges or ribbons (flanges are usually quicker), so
there's no changing LoD according to what a block's neighbour does, which
can improve speed. Custom tesselation means even fewer tris / more detail
for given tri budget, but lots of precalculation required, and each area of
landscape has its own VIPM index list, so there's a lot more memory. Does
not work well with changing landscape, because the geometry affects which
tesselations are used.

And finally: just draw everything. Works just fine for games with a low
viewpoint that don't need to draw very far, e.g. FPS games.


Did I forget anyone?


Tom Forsyth - purely hypothetical Muckyfoot bloke.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Trent Polack [mailto:tr...@vo...]
> Sent: 30 July 2002 02:40
> To: gda...@li...
> Subject: [Algorithms] ROAM
> 
> 
> I was just sitting here, in the middle of coding the ROAM 
> implementation for
> my "Focus on 3D Terrain Programming" book for Premier Press. 
> Now, the book
> is all about terrain, but focuses more on its applications to game
> development than anything else... Which leads me into my 
> question. I have
> three main algorithm chapters in the book:
> 
> Chapter 5: Geomipmapping. The algorithm is very GPU-friendly, 
> simple to
> implement, and just generally a very good CLOD algorithm.
> 
> Chapter 6: Stefan Roetgger's Quadtree algorithm. While it is far more
> CPU-intensive than geomipmapping, this algorithm is a bit 
> more balanced and
> "powerful" than geomipmapping. What it lacks in speed, it 
> makes up for in
> mesh consistancy and detail.
> 
> Now, chapter 7 is where the dilemma is. I could teach the 
> reader all about
> ROAM, but I'm wondering if I should really bother. Its a 
> great algorithm,
> and I do not doubt its power, but I really do think its 
> lacking in speed, at
> least compared to the previously mentioned algorithms.
> 
> Now, what I was thinking, was that in Chapter 7 I could write 
> about several
> different approaches to making a very fast and stable terrain 
> engine, such
> as some variations on the geomipmapping algorithm discussed 
> in Chapter 5.
> But, I really need some opinions here (Plus, I've been writing almost
> constantly for the last three days, and my thought process seems to be
> rather broken.), what do you guys think?
> 
> -------
> Trent Polack
> tr...@vo...
> Thought of a lifetime: "NARF!"
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Dice - The leading online job board
> for high-tech professionals. Search and apply for tech jobs today!
> http://seeker.dice.com/seeker.epl?rel_code=31
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=6188
>