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

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

Hi Charles,

Charles Bloom wrote:

> Hi Mark,
>
> At 10:18 AM 9/13/2000 -0700, you wrote:
> >Correct me if I'm wrong, but in your VIPM code you still need to compute
> >the actual strips or indexing on the fly each frame?  [snip]

> VIPM requires very minimal CPU work to update the triangle list.  It is
> not rebuilt from scratch each frame.  Instead, you just do some small
> updates to keep it valid all the time.  The work is O(N) in the number
> of triangle changes per frame (eg. very very low).  There's a write-up
> and pseudo-code on my web page.  Also note that memory touches are O(N)
> in the number of triangle changes per frame, and ZERO triangles or verts
> that aren't modified are touched.

Hmmm...I just skimmed your web page on VIPM and that explains a lot.
I am concerned about the three indices per tri rather than what you get
with strips (for infinitely long strips this gets down to 1).  We are talking
dynamic loads to graphics-card memory in general, as you swap in and
out chunks, and taking up room on the limited graphics memory, and depending
on the chip taking additional bandwidth to access those indices.  In short,
I think in general you need to minimize the number of indices that you send to

the hardware or store there (same for vert coords and texture coords etc).
The O(number of new verts) applies mainly to PC memory unless you have
really fine-grained ways to send a few more verts/indices here and there to
the graphics card.  Unless you are assuming that the indices are all getting
shipped over the AGP bus every frame?  Also, how do you manage to
keep the array continguous in graphics card memory if you don't allocate
enough space there to ship the whole thing?  But these are a quibbles.

The term VIPM is misleading and restrictive--the concept deserves better.
The idea really has to do with sending things *within* chunks in a "static"
progressive order, taking advantage of caching effects to allow only
an array-range update or trickle of geometry each frame, and relying on some
other VD processing at the macro level.  The PM is the restrictive
part--you can do this with *any* progressive stream that doesn't move
vertices.  The results of doing a split-only ROAM without screen-projecting
the error produces such a progressive sequence, as does the more general
queue-based refinement of a DAG style hierarcy.  VIPM is misleading in
that it makes one think "view independent" for the big picture, which is
not the intention.  It is a progressive vertex array, really, and you would
like to have a few thousand of them active, with a few hundred verts each.
Ideally.  I'd be curious what current graphics hardware can handle.

>
>
> I think some kind of chunked ROAM or VDPM is perhaps the future; it would
> be nice to find an algorithm which can be seamlessly blended from VIPM
> (large chunks) to ROAM (small chunks) so that a parameter can be tweaked
> which controls the CPU vs GPU loading.  The brilliant step in this
> direction is still missing; all attempts at it are way too bulky to compete
> with VIPM or the minimalist versions of ROAM (ala Treadmarks).
>

ROAM the chunks, and VIPM within the chunks.  Need to solve the seam
problem.  Also the issues I raised above, if they are real issues...

--Mark D.