From: =?iso-8859-1?Q?Niklas_H=F6glund?= <niklas@canit.se>
  To  : ggi-develop@eskimo.com
  Date: Thu, 4 Feb 1999 13:12:00 +0100

Re: libggi3d

If I have understood things correctly libggi3d is a very small toolkit
that is meant to link modules together.  These modules all take one
struct as input, and returns another (possibly identical) struct as
output.  Two modules can be linked together if the first one returns
the struct the other one wants as input.

What is being discussed right now is how to name the modules, and how
to identify which modules can be connected to a module.

I don't see a reason for why the names should be computer readable.
It seems reasonable to me to let the module authors name their modules
however they want.

For how to decide if two modules can connect, ints and strings as
identifiers have been suggested. The disadvantage of ints is that with
them one have to be careful so that two different game companies, for
example, don't use the same value for two different structs.  As
pipeline construction always is done during program initialization,
the slightly higher cost of a string compare is extremely small
compared to the actual loading of the module from disk.


I like the idea of a benchmarker that can automatically choose the
most efficient pipeline.  It's a neat idea.  I see some problems with
it, though.  The efficiency of different pipelines may highly depend
on factors that are difficult to measure, such as:

1. System load
   
   - May affects weather to use a slow hardware-accelrated modules or
     faster software algorithms.  (Probably not a very common one, but
     with slow hardware on a multiprocessor machine it would
     certainly, and also when doing strange things with very
     specialized software modules where hardware accelration have to
     be made in a very inefficient way.)


2. Scene complexity

   - Different algorithms are good for different cases.


3. Visual quality of the result.


The optimizer isn't neccessary to use libggi3d, though.  It's nice if
someone makes it.  A demo where one can switch pipelines on the fly to
see the difference in framerates would probably do just as fine.  With
that one could also easily see how some modules that make the result
look better slow down the rendering.

-- 
						Niklas