RE: [Algorithms] vipm instancing

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

The only memory that needs to be replicated is index memory - that's what
we're talking about, right? The vertex memory can be shared between all
instances, since you never change the vertex data when collapsing/expanding
edges.

I did have a vague outline of a scheme to get better vertex cache coherency
(which normal VIPM lacks), and which, almost as a side-effect, allows you to
share much more index data between instances. Here's a quick brain-dump. One
day I'll write it up properly.

This could be improved by having several versions of the index buffer, but
pre-optimised for polygon number ranges:

For the range 100-200 triangles, I stripify the first 100 tris in the index
buffer, and then the rest are in collapse order. Over 200, I switch to the
200-400 range, which has the first 200 indices stripified, and the next 200
in collapse order. So this just involves switching index lists every power
of two triangles. Note that I haven't actually tried this yet!

You could also make the switches more often, i.e. every 100 tris. Also note
that some of the non-vanishing tris need to be modified during
expands/collapses, so they need to be in the un-optimised chunk as well.

I did write this all down properly somewhere - I've lost it now.

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

> -----Original Message-----
> From: Paul Firth [mailto:pa...@ar...]
> Sent: 03 August 2000 11:30
> To: gda...@li...
> Subject: [Algorithms] vipm instancing
> 
> 
> Hi,
> 
> I was wondering if anyone can offer any advice about how to
> save memory when instancing multiple vipm models in a scene.
> 
> Ideally what I'd like to have is each instance only taking enough
> memory for as many tris as it currently has in its LoD, but I can't
> see any way to neatly increase this amount without some kind of
> crazy slow memory re-organisation.
> 
> I could use buckets but I really don't want to waste all that 
> luvly ram,
> does anyone have any ideas?
> 
> Cheers, Paul.
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>