Re: [Algorithms] VIPM With T&L - what about roam

[Mark D. <duc...@ll...>]

Charles,

Okay, I think I got the main points right, and we agree
in our AGP bandwidth estimates that we are right at
the limit of AGP4x for current top-end T&L cards.
Also it looks like strips just aren't worth the trouble
of bothering with, given the hardware trends.  It is very
interesting that the index updates are write only and
you can expect on some hardware (all?) that the CPU
doesn't stall.  So I'll take all that as agreed, more or
less.

The two remaining issues I'll mention for now are:

a) I was hoping when I first heard about the "just move the
array limit" idea that no work per tri changed was needed,
and that is not the case.  Even though the CPU/memory
usage is small per tri changed per frame, it is there.  I'm
woried about how this maps to technology trends.  GPUs
are getting faster in per-vert and per-pixel/frag *operations*
faster than CPUs are getting faster at *operations*,
(operations meaning if you are measuring only the compute
time and not the associated memory-access time), and
CPUs are getting faster at a higher rate than bus bandwidth,
and bus bandwith is going up faster than memory speeds.
So if I got the sequence straight, it is shortsighted to do
work per changed vert that involves the CPU touching mem.
I think you will have to move to the model you mentioned
where you pre-optimize completely opaque (to the CPU)
static chunks of geometry, and have the CPU just decide
which ones to turn on and off (these chunks become the
new atomic primitives from the CPU's point of view).  If
you are in a particularly coherent situation, or have some
particularly local modifications to LOD priority (like getting
object placement or line-of-sight right), then you can
judiciously split up these black boxes and do more fine-
grained optimization as time allows during a frame.

b) I don't see why you want to use per-vert lighting with
geometry LOD.  In my experience this gives horrible
artifacts.  Again the technology trend is to get enough
processing power post texture lookup to allow all the lighting
effects to happen there with no lighting control needed at
all at the verts.  Right now you can get a complete
dynamic lighting environment (i.e. equivalent to an
infinite number of light sources on an infinite sphere)
for diffuse-only shading using a color and normal
texture with cube environment maps and multitextures.
With a second cube lookup after the first you can get
specular for the infinite number of light sources (right now
no hardware that I know of allows this second lookup
on the results of the first--paletted textures are a
total hack as a substitute). You would need some
blending to approximate local lighting as you
move from one region of geometry to the next,
but I think that could work fairly well.  I just don't see
why the L in T&L is at all useful in the long run.  Another
nice thing about putting all your lighting data in the
textures is that you don't have to send it over the
saturated AGP bus.

Still, I think the idea is great: getting really fast updates
as you slide from low- to high-res and back in a chunk
for progressive streams, with a handful of cheap index
tweeks that are write-only ops.  I will add that to my
bag of tricks...

--Mark D.