Re: [Algorithms] Terrain performance comparisons

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

Jonathan Blow wrote:

>My recent email about software complexity issues touches on the
>subject that Luis brought up about algorithm adoption ostensibly
>being a social issue.  I think there are definite technical issues here
>as well, so I wanted to bring those up.
>

Naturally.  Social limitations don't imply that technical issues don't 
exist.

>Luis Ackerman wrote:
>  
>

And now I'm being mischaracterized ^_^
No hard feelings.

>It's important to remember this: ideally, we don't want to LOD at all.
>Any graphics LOD indicates a mismatch between what is being
>rendered, and what actually exists, in the game world.  That mismatch
>*will* show up sometimes in gameplay.  If the mismatch causes
>big enough problems, which it often will regardless of the algorithm
>in use, we need to deal with those.
>  
>

Well, pulling ideals out of a hat doesn't solve anything.  Ideally I'd 
like an infinitely fast computer.  Lacking that, LOD is a practical 
approach to the problems at hand.  It does have drawbacks, and 
workarounds, but like anything there's a cost/benefit decision.

This leads to an interesting point though, which is that the triangle 
isn't a perfect graphics primitive and we're pretty rapidly reaching the 
point where they become a big bottleneck.  You can draw your own 
conclusions about what future non-triangle-centric systems will do, but 
I think all the approaches that scale well will tend to do LOD under the 
hood, pretty much for free.

>Right, and this is my big problem with CLOD.    CLOD 
>algorithms spend all this software complexity -- a finite and highly-contended
>resource, as mentioned earlier -- and what do we get?  In such an algorihtm's
>raw form, we get a guarantee that the spatial error for every vertex on the
>screen is bounded.  Okay; it's unclear whether that's worth all the effort, 
>but at least it's something solid that can be said about what these algorithms 
>achieve.  But wait!  In order for the system to run smoothly, we need 
>to give up this guarantee.  So now what can we say about the
>algorithm's achievement?  It "generally makes it so that vertices are within
>the error threshold most of the time as long as you're not stressing the
>system too hard".  Is that all?  I can do that with a static mesh algorithm,
>so why all the fuss?  
>ROAM handles morphing surfaces better than static mesh LOD, but
>in those cases I can just use geomipmapping.  So I'm just not sure what
>ROAM buys me for all that effort.  That's all.  If someone convinces me
>that there is a large, clear payoff, I will happily go back to using CLOD
>algorithms.
>  
>

Cheap, fast, good - pick any 2.  This really just wraps back to the 
original discussion about what requirements you have.  Some things are 
going to be more appropriate for some problem domains.  

IMHO, the big win for CLOD is scalability, which most games just aren't 
going to take advantage of.  They could eventually though, when someone 
writes a game to escape all artificial limitations and creates an 
unbounded content domain.  Memory will remain a limiting factor, but 
scales of interaction don't have to.

>Now as people keep optimizing CLOD algorithms, they are becoming
>more like static mesh algorithms, so maybe the two will meet at some point.
>
>   -Jonathan.
>  
>

Seeing all the approaches have different deficiencies that people are 
trying to overcome, some amount of convergence can be expected.

-Lucas