Re: [Algorithms] Terrain performance comparrisons

[Lucas A. <ack...@ll...>]

I agree, you can't compare the performance of algorithms except in a 
theoretical sense (and we know how well that reflects in practice). 
 What you can compare is the performance of specific implimentations. 
 Even different implimentations of a single algorithm can have hugely 
varying speed and quality differences (as is the case with ROAM for 
example, all the way from unusable crap to better than you could have 
hoped for).  Your particular needs, goals, and preferences will 
obviously have a large impact on what you consider best.  If you could 
outline your problem domain and the constraints on your solution, 
perhaps we could help make some informed recommendations.

-Lucas


Andras Balogh wrote:

>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
>>    
>>
>
>
>  
>