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

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

Tom,

As a ROAM crusader I must respond ;-)...

ROAM works just fine on arbitrary geometry.  We mentioned it in the
ROAM paper (but didn't implement it).  Since then I've implemented
that and it works great using a forest of triangle bintrees.  Cover your
surface with "patches" that are 2^n + 1 verts on a side, where adjacent
patches match vertices on their mutual edge, and you are set to go.
The trick is to convert your geometry to "patches" like this.  There
is the MAPS algorithm from SIGGRAPH (Lee et al, 98), plus a new
shrink wrap technique for really wild geometry like turbulent CFD
isosurfaces by Bertram et al in Vis 00.  Go to
http://graphics.cs.ucdavis.edu/Publications-2000.html
and look for "Bicubic Subdivision-Surface Wavelets for Large-Scale
Isosurface Representation and Visualization."

The ROAM dual-queue idea works great on Directed Acyclic
Graph (DAG) style hierarchies, a special case of which
is VDPM.  This was shown in a paper by Bernadini and Schikore
"Dynamic viewpoint-dependent level of detail of large triangle meshes"
presented at The IASTED International Conference on Computer
Graphics and Imaging, Halifax, Canada, June 1-4, 1998.  An online
preprint is here: http://www.llnl.gov/tid/lof/ (type Schikore as the
name to search on, then click on the last item that comes up).
Additionally, the priority deferral and incremental stripping ideas
work fine for DAGs.  The one thing that needs a small re-work is
the frustum culling using halfplane labels and recursion.  DAGs
don't have the simple nesting relationship that triangle bintrees do.

VIPM I see as okay for large collections of little objects, if you ignore
the fact that you are roughly doubling the transform and download
work for back-facing sections of the object (VD methods can
easily eliminate those from ever hitting the graphics hardware).
If your "little" object isn't, like a ship you decide to walk into, then you
really need to do view-dependent processing on finer-grained units
than whole objects.  Further, you need Yet Another Hierarchy (YAH)
to do frustum culling, and other macroscopic logic to decide how
to balance the LODs on all the objects.  So the simlicity of the
VIPM vertex selection for a single object isn't buying you all that
much in overall system simplicity.

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?  You can
"precompute" in a coarse-grained way only if you keep something like
power-of-two static LODs, in which case VIPM isn't all that different
from traditional static LODs circa 1976, except that you cut the vertex
storage in half in some cases.  If you use skip-strips or other techniques
you end up doing work on a fine-grained level, and at that point
you might as well put some VD smarts in.

All that said, it is certainly worth exploring *somewhat* coarser-grained
view dependence.  Fine-grained view-dependent techniques using ANY
algorithm just can't keep up with graphics hardware (unless
you move veeeery slowly ;-).  Hoppe's 1998 IEEE Vis paper is
a step in the right direction, but has a lot of problems and only works
with terrain.  See:
http://www.research.microsoft.com/~hoppe/#svdlod

--Mark D.

Tom Forsyth wrote:

> I think what Jim is saying is "VIPM works for anything, including landscapes
> - but ROAM only works for landscapes". Which I, as a true Crusader on the
> Path of VIPM Righteousness, agree with of course. Code the VIPM stuff once,
> and you can use it for just about everything in your scene. Landscapes take
> a fairly simple bit of code to be converted to VIPM-friendly chunks. What
> might take a bit more time is doing the hierarchial VIPM thing, where the
> chunks can be coalesced into bigger chunks as they get further away.
>
> Tom Forsyth - Muckyfoot bloke.
> Whizzing and pasting and pooting through the day.
>
> > -----Original Message-----
> > From: Jim Offerman [mailto:j.o...@in...]
> > Sent: 12 September 2000 13:10
> > To: gda...@li...
> > Subject: Re: [Algorithms] VIPM With T&L - what about roam
> >
> >
> > > It's all swings and roundabouts, there are cruder LOD techniques for
> > > ...
> > > draw more polys. Any thoughts?
> >
> > These days, with hardware evolving so fast, it may very well be more
> > rewarding to spend your time writing something which will increase the
> > overall speed of your (rendering) engine than to spend time working on
> > something which will only speed up rendering of a certain
> > type of geometry.
> >
> > Jim Offerman
> > Innovade