RE: [Algorithms] ROAM

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

Four! Four techniques. Ah ah ah ah ah <thunder+lightning>

(geomipmapping, VIPM, chunks with CPU morph, chunks with GPU morph)


Agreed that in real "large world" apps the paging in and out of data is also
a very interesting problem. Though I can't help thinking the basics of
mipmapping (and swizzling, so that a square region is a single linear
access) heightfields should solve half the problem, and a good async-loading
streamer should solve the other half. Does it need to be any fancier?


Tom Forsyth - Muckyfoot bloke and Microsoft MVP.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Charles Bloom [mailto:cb...@cb...]
> Sent: 28 November 2002 21:09
> To: gda...@li...
> Cc: jo...@te...
> Subject: RE: [Algorithms] ROAM
> 
> 
> 
> At 04:57 PM 11/28/2002 -0000, Tom Forsyth wrote:
> >True, but for a real apples-to-apples comparison it probably 
> needs to be in
> >the same framework/application. Also, Thatcher's chunk-lod 
> is yet _another_
> >separate case because he's doing vertex morphing as well, 
> which again pushes
> >CPU time up but also increases quality-per-triangle.
> 
> The morph can be done in a vshader at the cost of more bandwidth.
> Anyway, with terrain, the problem is not actually rendering, it's
> managing the huge amount of data needed.  You could render the entire
> earth at apparent 1-pixel screenspace error - the speed of the
> algorithms is not the problem - it's the fact that the dataset is
> collosal.
> 
> Clever paging and streaming are much harder than the rendering bits.
> 
> -------------------------------------------------------
> Charles Bloom    cb...@cb...    http://www.cbloom.com