Re: [Algorithms] Terrain performance comparisons

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

>   We use temporal coherence successfully in lots of ways in Halo 2, but
> not for anything view-dependent. For example all of your simulation
> tasks can take great advantage of temporal coherence, as can certain
> rendering tasks as well, like recomputing lighting coefficients for
> objects. But visibility from frame-to-frame clearly must be computed
> from scratch.

Well there are two different levels to this.  The visibility aspect definitely
is more severe, and I agree with you on the "clearly" part there, and it
annoys me that e.g. a lot of people working on terrain algorithms don't
even think about this.

The reason why I say "avoid frame coherence whenever possible"
goes probably a lot like the viewpoint-specific case, but I figure hey,
I am here typing, I will explain it for anyone on the list who is wondering
what we are talking about.  Effectiveness of frame coherence in general 
depends on how close the two frames are, in whatever state space some 
specific\ algorithm cares about.  Since a game is a simulation, these states
almost always diverge over time.  (For a viewpoint moving around,
it's just that you have some velocity that you multiply by dt, so you
have moved further; but for physics it might be that all your objects
have moved, or that your points of contact are more likely to be
different, or whatever).

So there is a dependency between the frame time and the effectiveness
of all frame-coherent algorithms.  If there is a hiccup that causes one
frame to go more slowly, the next frame is going to suffer and go
more slowly as well (and this will keep propagating, through n frames).
In the worst case, your dependency is so strong that the frame after
the glitch is even *slower* than the glitch frame, in which case you
get a sort of downward spiral effect and your frame rate plummets
for a while.  

This is pretty severe though, and much more common is just that
these dependencies react to small changes in your frame rate, amplifying
them.  So the upshot is, you increase the variance of your frame rate.
That is still a very bad thing, because we like level, solid-feeling frame
rates.  Frame-coherent algorithms, by definition, work against that.


In general, I characterize frame-coherent algorithms as having
"interactive volatility" -- because of the realtime nature of the sim, they
behave badly.  Whereas for something like an offline batch renderer,
they're fine; there is no constraint between realtime dt and simulation
dt, so frame coherent algorithms are a 100% win there.  And that's
the area in which the tradition of frame-coherent stuff arose: offline
simulation and rendering, back before we had computers that would
even do this stuff realtime.  But the problem is that people working
on new algorithms today follow in this blind tradition of "frame 
coherence is 100% good".  In fact it's one of the first weapons they
pull from their holster when coming up with a new algorithm to do
whatever.  And that's a bad thing.

I'm not saying frame coherence is 100% bad, because the fact is
that we don't have viable non-coherent alternatives for a lot of
tasks.  Physics is a good example.  I just think people need to look
carefully at their options and understand what they're doing.

   -Jonathan.