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

[Sam K. <sa...@ip...>]

Yeah, but surely the roam algorithm isn't much slower than vipm's.. I mean
roam and vipm are very similar. They both use frame-frame index list
coherency and both use splits and merges. My index calculation time is tiny
compared to the software D3D tranform time.
Anyway, if one was going to implement roam, using T&L would be much faster
than not. and free up much cpu time for the roam calculations. Same as using
T&L for vipm.

This leads me to another question:

In VIPM, using T&L hardware you evidently can have a huge VB and supply a
small index list. and thing will run swell because the card only transforms
and lights the indexed vertices.
Using software transforms i.e. D3DHAL, this isn't the case (why not?) D3D
tranforms all the vertices in the VB regardless of the passed index list. So
to get round this in you store the verts in first-last split order and pass
in a vertex range. D3D Tranforms the needed verts and using the index list
to render them. O.K. Fine.

BUT, what about software transforms in situations where the split order is
not known, i.e. VDPM or ROAM where polygons are denser towards the camera?
you cant specify a range of verts for the software transform because it
quite literally could be any of them. HT&L is fine because of the only
transform indexed verts thing.

Is there a solution to this?

sam





-----Original Message-----
From: Tom Forsyth <to...@mu...>
To: gda...@li...
<gda...@li...>
Date: 11 September 2000 3:59 PM
Subject: RE: [Algorithms] VIPM With T&L - what about roam


>Yes. Though ROAM, in other peoples' experience, is limited by the ROAM
>algorithm running on the CPU, not by a T&L graphics card. So your real
>bottleneck is the CPU.
>
>Tom Forsyth - Muckyfoot bloke.
>Whizzing and pasting and pooting through the day.
>
>> -----Original Message-----
>> From: Sam Kuhn [mailto:sa...@ip...]
>> Sent: 06 September 2000 21:48
>> To: gda...@li...
>> Subject: RE: [Algorithms] VIPM With T&L - what about roam
>>
>>
>>
>>
>> Ok cool, thats what I hoped.
>>
>> This brings me to another thought...
>>
>> Say you had a roam implementation that subdivided down
>> (ignoring camera
>> distance, just using landscape variance) to a fixed level say 500,000
>> vertices or so and stored them on card for T&L. *then* on
>> subsequent passes
>> of the roam bintree, generate indexed lists into that
>> hardware vertex pool
>> based on the camera distance. This means you get true
>> distance based roam
>> LOD and cached t&l of the used verticies right?
>>
>> sam
>_______________________________________________
>GDAlgorithms-list mailing list
>GDA...@li...
>http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list