RE: [Algorithms] Terrain performance comparrisons

[Tom F. <tom...@bl...>]

There was some talk about this ages ago, during the height of the ROAM
vs VIPM wars. I think people decided to adopt the moon surface dataset,
and obviously there would have been some sort of standardised fly
through of it, but we couldn't decide on a good measure of quality,
since just measuring pixel-invariance doesn't work all that well for
most of the algorithms - even if you could find a decent measure (must
be some out there surely?) there's other considerations like "how much
does it pop" and so on.

That said, a common dataset and framework can't hurt - at least then you
can run stuff side by side, put the quality settings at what _you_
consider to be able the same, and check performance.

It also depends if you don't mind using 100% of the CPU just for
rendering, or if you need the CPU for other things and would like to
throw as much stuff onto the GPU as possible (vterrain.org seems to be
pretty cursory about this aspect and the routines that use it, but it's
very important for many projects).

If you have any specific questions, I'm sure we'll be happy to help :-)

TomF.

> -----Original Message-----
> From: gda...@li... 
> [mailto:gda...@li...] On 
> Behalf Of Andras Balogh
> Sent: 24 July 2003 19:24
> To: gda...@li...
> Subject: Re: [Algorithms] Terrain performance comparrisons
> 
> 
> It's very difficult to compare different terrain rendering algorithms
> objectively. Performance depends on so many things that it is very
> hard to do fair comparisons. Quality measurements are also
> troublesome, it's like comparing MP3 with Vorbis... Which one is
> better? The more people you ask, the more answers you will get.
> 
> Every method has its advantages and drawbacks. You have to balance
> tradeoffs and choose wisely, depending on your requirements.
> 
> Well, I know I didn't help much, but I just can't... :(
> 
> 
> Bandi
> 
> 
> Thursday, July 24, 2003, 1:38:59 PM, De Boer wrote:
> 
> > Anyone know of a paper where a number of terrain algorithms 
> are compared
> > objectively in terms of speed/quality? Most of the time I 
> see a paper say on
> > an extension to an algorithm and they state how much extra 
> fps the extension
> > had on the old algorithm. Quality isn't usually even 
> measured. But is there
> > any papers dedicated just to "comparing" terrain algorithms 
> as objectively
> > as possible? Although opinions of "which algorithms are 
> best" would be
> > useful I am really looking for papers with objective 
> measurements (opinions
> > seem to vary way too much).
> 
> > Here is the old original msg from 2000 if you don't remember it:
> 
> >>Concerning the speed of terrain LOD algorithms:
> 
> >>If i made performance claims on my site, people would 
> certainly complain
> > that the results are entire based on context (type of 
> >dataset, amount of
> > camera motion) and that their implementation is really fast 
> if i had only
> > tested it their way :-)
> 
> >>In fact, it's even harder than that to make meaningful 
> comparisons, since
> > some algorithms (e.g. LK, TV) enforce a global error 
> >metric, while others
> > (ROAM, SM) enforce a polygon count target. The first kind will have
> > framerates that will vary widely, while >the second will 
> produce relatively
> > stable performance.
> 
> >>A lot of the discussion on the Algorithms list has been 
> about how many
> > triangles/second each implementation gets through the 
> >rendering pipeline,
> > which seems to me a rather silly metric - it's fps at a 
> level of perceived
> > quality, NOT raw throughput, that >is the value of a LOD algorithm.
> >>-Ben
> >>http://vterrain.org/
> 
> > -Ryan De Boer
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet
> _072303_01/01
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=6188
>