RE: [Algorithms] vipm instancing

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

That's pretty much the one I suggested, but you lose the whole
continuousness, which is rather the point of VIPM - if you wanted discrete
levels, just precompute them and use static LoD, which is even faster. I was
suggesting you have some precompiled "base" triangle counts (e.g. a 300 tri
one), and then just the extra few replicated for each instance to work up to
the desired precise tri count (i.e. another 23 to get to 323 tris, which is
what the error metric says you should have).

It's a little more complex than that (because existing tris get modified by
adding new tris, so those can't actually be in the precompiled chunk), but
that's the essence.

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

> -----Original Message-----
> From: Thatcher Ulrich [mailto:tu...@tu...]
> Sent: 04 August 2000 15:04
> To: gda...@li...
> Subject: Re: [Algorithms] vipm instancing
> 
> 
> 
> On Fri, 4 Aug 2000, Paul Firth wrote:
> 
> > > You can do it by having a list of faces per object (faces 
> can't be shared).
> > > Each object will use the same vertex buffer and the same 
> vsplit list, but
> > > each object is in a different state, with different VB_Len and
> > > CurrentVsplit.
> > > This needs memory but if you have a 64k polys object you 
> only need 64K*2
> > > bytes per object, which isn't very much.
> > 
> > This is how I'm doing it currently, the trouble is that 
> every instance uses
> > the same amount of memory which is a huge waste if I have many
> > instances at a high distance.
> > 
> > Its annoying because if this idea worked and you could have 
> instances with
> > almost 0 memory waste you could have crazy numbers of polys in your
> > scene.
> 
> How about: have a table of (say) ten vipm instances, which 
> are then shared
> by all visible instances of that model.  You'd have some kind 
> of voting or
> averaging scheme for deciding what the poly count should be 
> for each of
> the ten actual vipm instances.  This would hurt the 
> continousness of the
> LOD scheme when more than 10 instances are visible, but then you could
> make whole giant forests of vipm'd trees without killing memory.
> 
> -Thatcher
> tulrich.com
> 
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>