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

[Tom F. <to...@mu...>]

Yes, for things that like strips (though I'm still hopeful that I can
persuade the bit of hardware to do something other than strips, maybe by
switching to fans half way through or something funky - it's a pain because
the rasteriser is basically just a fast Permedia2, but it doesn't have the
nice exposed front-end interface of the P2), the original skipstrips is
probably good. Though there's no reason you can't use indexed strips to get
better DMA throughput - I have a cunning scheme to get pretty good indexing
working on this hardware, even though it can't do _real_ demand-loaded
caching itself.

Using something like indexed skipstrips and power-of-two precalculated
models seems like it should be a good thing to try.

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

> -----Original Message-----
> From: Brian Marshall [mailto:bma...@ra...]
> Sent: 13 September 2000 07:45
> To: gda...@li...
> Subject: RE: [Algorithms] VIPM With T&L - what about roam
> 
> 
> 	I've been thinking about this more. The requirements 
> for the hardware I'm
> working with are somewhat different - I get maximum benefit 
> from very long
> strips, since the hardware has a very different caching 
> scheme to G-Force
> etc.
> 
> 	I'm currently edging towards trying a combination of 
> skip strips and your
> suggestion Tom, of precomputed strips for various levels. The 
> idea would be
> to precompute good sets of strips at reasonable values, and 
> use skip strips
> to maintain the strips during edge collapses.
> 	During PM computation you start with doing a full 
> stripification of the
> model. Then as you do each collapse you rate the current set 
> of strips - how
> many degeneracies, how long etc. So when the strip quality 
> reaches a user
> set threshold you regenerate the strips. That way the user can set the
> trade-off between memory usage (for extra sets of strips.) 
> and rendering
> efficiency. For an ultimate version you could recompute a new 
> set of strips
> for each edge collapse to compare the efficiency of the 
> current skip-strips
> against. Then you can decide exactly when to issue new 
> strips. Not something
> to do when the art team are working on the model, but should 
> work great
> overnight.
> 
> 	There are a couple of problems I can see:
> 1. The edge collapse records get more complex - you need to 
> issue sets of
> strips as well.
> 2. The runtime memory state required is somewhat larger - you 
> may need 2
> sets of strips (the second having excess degenerate tri's removed for
> efficiency), as well as more complex collapse records and 
> extra data for the
> sets of strips to restart things.
> 
> -Brian.
> 
> > Cool. I'll have a look at the second one of those. The first one
> > (skipstrips) was discussed here a while back, and led to me 
> burbling this,
> > which bears repeating for those who recently joined us 
> (especially as
> > someone asked for it):