Re: [Algorithms] Scalability costs

[Jamie F. <j.f...@re...>]

Jim Offerman wrote:

> > Great idea, does it really happen in practice? We seem to end up starting
> from
> > scratch every time. Or at least taking the old stuff, using it as a base,
> and
> > then rewriting most of it. New consoles don't help, of course :)
>
> I am quite a fanatic reuser... while some parts of my engine are written
> only yesterday, other parts are several years old and have survived many
> generations of my engine.

Impressive :)

> I find myself constantly tweaking the parts of the
> engine which interface with stuff like direct3d (technology side) and such
> all the time,

Us console programmers just get a new console to play with :)

> while my scenegraph (content side) has remained quite constant
> for several years now.
>
> > That definitely makes sense. All our geometry is going through the same
> > pipeline. CLOD does not make sense for us given time constraints, and it
> > doesn't fit the hardware too well either (according to our somewhat
> limited
> > research :). Next generation of games, we may try something a little more
> > procedural, but not for the mo....
>
> Admittedly, I cannot really afford to spend much time on progressive meshes,
> my biggest worry at the moment is getting my game up and running. Still, I
> am always on my toes and looking ahead... Given the architecture of my
> engine, VIPM is the way to go for me, since it can be implemented in my
> engine with quite little effort (the hard part is writing the code that
> generates the VIPM...) and in addition it is _very_ hardware friendly.

Not regardless of hardware. For us, drawing several instances of the same model
saves us DMA bandwidth. CLOD trashes the ability to do that. 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