Re: [Algorithms] Terrain performance comparrisons

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

I think Charles has the right viewpoint here...

Tony Cox wrote:

> This is all true, but the guy who is working on the renderer wants to
> make the best renderer they can. They're not in a position to fix many
> of the other issues you mention. 
...
> It's definitely true that you should focus your resources on what gives
> you the biggest customer impact, but it's also true that in a reasonably
> sized team there is going to be some partitioning of skills and
> expertise. So, if you can't bring all of your resources to bear on your
> top problem, you do the next best thing, and bring resources to bear on
> the problems you can do something about.

If game development were modular, this would be true.  But game
development isn't like that.  When you tell your graphics guy to go work
on a more complicated LOD algorithm, all of the following things happen;
many of the effects are small, but you put them all together and they
can't be ingored:

* You increase the load on QA
* You increase the number of bugs that slip through QA/code-fixing
    into the final distribution
* You increase the load on your designers, who need to adapt their work
   practices to the character of the LOD algorithm
* You increase build times, thus decreasing productivity for all programmers
* You increase your executable size
* You probably increase your heap memory usage / fragmentation
* You decrease the longevity of your engine prior to re-writes (maybe
   not an issue for console guys)
* You remove the ability of that programmer to perform other graphics 
   speed / quality work.  (i.e. there is an opportunity cost)
* You make the graphics code harder for other graphics programmers to
   understand and modify, creating a dependency bottleneck that will crop up
   later in the development cycle.

These things above (QA load, designer load, runtime memory) are all
finite resources, and they are resources that are inevitably stretched to
their limits during every game development cycle.  These resources are 
definitely contended for by all of the items that Charles listed in his 
"big terrain" example.  So where are you going to spend them?
  
Aside from all this is the basic fact that the technical components in a
game are not orthogonal.  Your LOD system *will* interact with the
rest of your engine, and the more complicated it is, the more problems
you will have.  Once you decide to add some complexity anywhere into
an engine, you end up paying for that complexity every single day until
you ship.

A failure to appreciate these facts is, I think, a big contributor in
why so many developers flounder.  

Let's look at this in a slightly different way: most graphics LOD algorithms
are focused on decreasing the number of triangles/sec needed to display
the scene.  But triangles/sec is the single most abundant,
uncontended-for resource in all of game development.  So WTF are
we putting all this energy there?

    -Jonathan.