Re: [Algorithms] Terrain Organization

[<Lea...@en...>]

> 1. A terrain with 5-10k polys in the scene is pretty weak. To have good
> detail up close, and have a large view distance (10,000 meters is a goal
> for me, although infinite yon clip with a spherical world would be even
> better) you end up with 100s of thousands of triangles in a single scene at
> full tessellation.

You can have a lot of detail up close, but you can quickly reduce the
amount of geometry sent to the card with things like basic lumigraphs,
reduced quad texture based geometry visualisation, etc... I've had our
terrain engine running at 35 km view distance and it looks nice... but
I haven't done any terrain stuff for a while now.

> 2. Not everyone has TnL capable machines, and it is generally a "good
> thing" if your engine can scale across systems with different geometry
> performance.

This is the difference -- we require TnL HW. I honestly believe that
ROAM is the way to go for CPU transformation engines, but not so for
HW TnL based engines... the best thing for people trying to support
both would be implement both -- but that's a lot more development.

> 3. You _can_ do continuous terrain LOD on a TnL card, but you are bound by
> the LOD calculation itself, and hence, CPU speed as you mention. However,
> things can and are being sped up greatly on this front, both with faster
> CPUs, and better split metrics.

As are expectations with 3D audio, physics, and in our case, AI... :)
 
> Now, that isn't to say that CLOD terrain is for everyone. Far from it. For
> small view areas and rather coarse tessellation of static terrain, just
> drawing a static LOD works quite well.

I agree that both methods have their benefits and audiences... it's a
matter of deciding at the start which suits your particular purpose.

Leathal.