RE: [Algorithms] Terrain performance comparisons

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

Slightly off on a tangent.

Shader LOD is less compelling to me than geometry LOD. If you have
pretty much any sort of LOD - even static levels - then you're going to
be drawing (very) roughly constant-area triangles. So your
vertex-processing load per pixel is roughly constant. And obviously your
pixel load per pixel is constant (excepting overdraw, which you can't do
much about using LOD - you need occlusion algos, which is orthogonal to
the problem).

So using geometric LOD has already brought stuff down by an order of
magnitude or something. You don't need shader LOD to do that.

If you do use shader LOD, then you can get back even more performance by
reducing quality in the distance, but it's not the sort of dramatic
speedup you get with geometry LOD. My guess is that you get somewhere
from 50% more to 100% speedup. Now that's still a whole bunch of cool -
I know I've sometimes spent days getting an extra 1% out of my engine -
but it can be a lot of work all the way down the art pipeline, and
that's continual work of "debugging" artists and so on, not just a
one-off of writing the code.

Unlike geometric LOD, it doesn't make stuff possible that wasn't
possible before, it just makes existing stuff faster. Of course if
you're smart you can write your engine with shader LOD in mind and it
works without too much pain, but retrofitting it to an engine is
moderately evil.

I had a point around here somewhere :-) Oh yes, shader LOD is good, but
it's not nearly as vital as geometric LOD. It's good to have it, but if
you don't and it's hard to retro-fit, don't worry too much about it.

TomF.

> -----Original Message-----
> From: gda...@li... 
> [mailto:gda...@li...] On 
> Behalf Of Jonathan Blow
> Sent: 30 July 2003 04:17
> To: gda...@li...
> Subject: Re: [Algorithms] Terrain performance comparisons
> 
> 
> 
> 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.