Re: [Algorithms] Terrain performance comparisons

[Jonathan B. <jo...@nu...>]

LUCAS Ackerman wrote:

> LOD is not about quantity, it's about quality.

Scene quality is not just about number of triangles.  As Thatcher
mentioned, shaders are very important for the user experience.
An LOD algorithm that's truly about quality will care a lot about
shaders, and will provide some answer regarding how to combine 
shaders in the distance (so we can render efficiently), without
popping.  

Also, such an algorithm will support the use of other quality-
enhancing techniques that games have been doing lately,
like the use of normal maps to approximate high-res geometry
with lower-res meshes.  This technique was popularized by
Doom 3, but serveral games are doing it (and the capability
is in Granny now, and Casey surely had the goal of making
it as good a general-use tool as possible).  

So far as I know, current CLOD algorithms don't even consider
the shader amalgamation problem.  Also, they make the normal
map technique largely infeasible.  (It's possible, but very painful,
and it uses a much larger amount of texture space, and so
it's basically a quagmire).  

With static meshes, we can use the normal map technique just
fine.  Also, in recent articles I discussed the use of color blending
to morph between static LODs.  I certainly didn't invent this idea, 
but I do like it, since it provides a way to solve the shader popping
problem (and it becomes a lot more attractive on DX9+ 
hardware).

So if I we are not content just to render a bunch of Lambert-shaded
triangles, CLOD algorithms have some questions they need to
answer.  I'm not saying there's no answer, but I am saying
there's a suspicious lack of CLOD authors asking these
questions.  

Maybe in the future we'll just use one shader for everything anyway,
and have the shader parameters driven by data in a texture map.
I fantasize about this.  But until (if) that happens, CLOD needs
to supply an answer if it wants to be an attractive solution.


About the quantity issue...

> LOD is not about quantity, it's about quality.  Quantity can increase 
> with hardware speed and software efficiency, but quality improves by 
> increasing the intellignece with which you allocate your limited 
> quantity.  If triangles/sec were the fundamental measure of game 
> quality, LOD would be pointless.

I must confess I still don't understand the point you're trying to make here.
"Quantity", when it comes to triangle meshes, is all about achieving
quality.  Right?  The whole point I want to render 100 million triangles
per second is so that the scene looks better than it does at 1 million.

Yes, intelligently allocating those triangles is a good idea.  But it's not
like we live in a world where the only choices are CLOD or NO LOD.
We have VIPM, we have static meshes.  We have other stuff like
geomipmapping.  All of these things do the task of intelligently
allocating triangles; they just have differing costs and benefits.  When
putting together a game, you want the most benefit at the least cost.

Nobody is denying that CLOD algorithms like ROAM do provide
benefits.  What I am just saying is, we really do need to take an
honest look at the cost.

Suppose a CLOD algorithm would make my graphics code 100 times more
complicated, and would provide a 1% increase in scene quality/speed.
Is it a good idea for me to adopt that algorithm?  No way!  Okay,
well suppose a CLOD algorithm would make my code 1% more
complicated, and would provide a 100x increase in scene quality/speed.
Would I adopt that?  Hell yes, I would jump at the opportunity.

Well, the Intermediate Value Theorem says that there's somewhere in
between those two extremes that's a breakeven point.  If some 
algorithm is K times more complicated, and makes my scene B times
better, then it's a wash -- I could do it, or not, it doesn't matter.

This breakeven point divides algorithms into two classes.
So one important question is, on which side of that 
point does any particular algorithm lie?  And then, once I have used
that question to cull a lot of possibilities, I can study the remaining
ones and ask: which one is closest to the ideal of infinite simplicity
and infinite benefit?

That's what I'm talking about here.  I don't deny that CLOD provides
benefits.  I'm saying don't just look at the benefits, look also at the
cost.  I am reminded of the Adbusters campaign "Economists Must
Learn To Subtract".  

None of my comments, by the way, applies to ROAM 2, since I know 
nothing about ROAM 2.  From what Mark has mentioned, it's chunking 
and it handles arbitrary 3D topologies, which makes it different enough
from ROAM 1 that no assumptions really carry across.

Lucas wrote:

> IMHO, the big win for CLOD is scalability

and Adam Paul Coates wrote:

> even better, a nice CLOD algorithm can scale
> with hardware -- fast users get lots of detail, slow users still get good
> detail, but can trade it for visibility. 

Yes, CLOD can scale, but it is not necessary for scaling.  VIPM
scales (you adjust the sliders to a different point!)  Static mesh 
algorithms scale (you just pick higher-res static meshes!)

   -Jonathan.