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

[Aaron D. <ri...@ho...>]

Just thinking out loud a bit here... I havn't tried this as yet.

Ignoring increased data on the bus, sending a roughly strip-order triangle
mesh to a GeForce 2 is just as fast as sending an explicit strip. For strips
in general, the total transforms required is 2+n transforms per strip (where
n is the number of triangles).

Since the GeForce (and presumably future T&L cards) have a cache of 16
vertices, a 4x4 heightmap (32
triangles when at full detail) could effectively require the same 2+n
transforms with no stripification.

Now back to VIPM (in the context of terrain only here) - Couldn't a rough
sort be done on a (say) 8x8 heighmap array to split its triangles into one
of four quadrants (or strips) and render them in these one by one? Wouldn't
this have the same effect? (ie. 2+n transforms per section) In a fully
connected heightfield, the edges of each set would be entirely cached from
the previous set.

Obviously after some VIPM merges you won't be able to exactly split the map
into segments evenly but a rough division should get close to the ideal 2+n
transforms.

The biggest problem I see is organising your index list. The traditional
split-order style list wouldn't work this way. You'd need a list for each of
your sets. I'm not sure if the hit in issuing multiple API calls outweighs
the benefits. (But there may even be solutions to this as well).

Thoughts?

- Aaron


> -----Original Message-----
> From: gda...@li...
> [mailto:gda...@li...]On Behalf Of Tom
> Forsyth
> Sent: Wednesday, September 13, 2000 7:53 PM
> To: gda...@li...
> Subject: RE: [Algorithms] VIPM With T&L - what about roam
>
>
>
> 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
> >
> >
> > The Atlantis Project
> > http://www.theatlantisproject.com
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> >
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>