Re: [Algorithms] VIPM on a machine with DMA :)

[Jim O. <j.o...@in...>]

As I understand it, you not supposed to touch the actual vertex data of a
VIPMed and, if the model is at full detail you will have exactly the same
data as when you render a 'normal' model. However, in addition you have some
'control data' to govern the process of adding/removing detail (which, like
Tom mentions, is all done by manipulating the index list). Since you never
send the control data to the rendering API, it won't even know the
difference...

Jim Offerman

Innovade
- designing the designer
----- Original Message -----
From: "Jamie Fowlston" <j.f...@re...>
To: <gda...@li...>
Sent: Monday, July 31, 2000 8:32 PM
Subject: Re: [Algorithms] VIPM on a machine with DMA :)


> Still have to DMA the vertex data, which is larger for VIPMed models (am I
> right? I've not implemented VIPM, but think I've understood the general
idea).
> So total transfer is larger than it would be for non-VIPMed model. We're
> expecting to be DMA speed constrained rather than draw speed constrained.
>
> Have you actually implemented VIPM on... that machine? :) Some sort of
> algorithms-style section in the support newsgroup would be nice, and I
could
> stop waffling and talk specifics.... :) Talk about LoD would be useful.
I'll
> post something....
>
> I know some stuff about other consoles... but AFAIK, I can't say which or
how
> much. Aren't NDAs fun? :)
>
> Jamie
>
>
> Tom Forsyth wrote:
>
> > > From: Jamie Fowlston [mailto:j.f...@re...]
> >
> > [snip]
> >
> > > Not regardless of hardware. For us, drawing several instances
> > > of the same model
> > > saves us DMA bandwidth. CLOD trashes the ability to do that.
> >
> > VIPM won't. Since you use the same vertex data for all levels of detail,
> > multiple instances are very cheap. All you change is a bunch of indices.
On
> > two of the future consoles I know well enough(*) to comment on, this
will be
> > nice and fast. You'll need to DMA across the new indices, but that's
tiny
> > amounts of memory. You may even be able to do the VIPM expands/collapses
on
> > the ... you know ... thing that does the transforms - the
expand/collapse
> > routine is absurdly simple. Which will make multiple instances awesomely
> > cheap!
> >
> > Oh dear - I'm off again about VIPM. Sorry list :-)
> >
> > > Polygons are very
> > > cheap to draw, so we might as well draw them.... Unless
> > > anyone else knows
> > > better? :)
> > >
> > > Maybe when we've had more experience of the machine we'll
> > > change our minds. :)
> > >
> > > Jamie
> >
> > Tom Forsyth - Muckyfoot bloke.
> > Whizzing and pasting and pooting through the day.
> >
> > (*) The one I don't know about, I knew exactly one hard fact about it -
its
> > name. And then they changed it, and I can't remember what to. So I now
know
> > precisely zero about it :-)
> >
> > _______________________________________________
> > 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
>