From: Bryan Meredith <bryan@bear-mountain.demon.co.uk>
  To  : ggi-develop@eskimo.com
  Date: Tue, 02 Feb 1999 22:00:08 +0000

Re: libggi3d non-clarity

Xavier Bouchoux wrote:
> 
> Hi!
> 
> I do agree with you.
> So let's get this straight:
> 
> Libggi3D has to provide: (and THAT should be standardised)
> - a way to know what fonctionalities are present
>       (in a usefuil way..  not just a unstandardised string telling
> nothing to the application.)
> - a way to know which modules are hardware accelerated
>       (actually, that doesn't means a lot.  The actual thing is more a
> way of knowing wich module is faster, and how fast they are. In order
> for the app to decide if it can use them or not.)
> - a way for the app to build new pipelines, to tweak them, and to insert
> its own modules in the pipeline.
> - what are the standard modules.
>       Because we speak of "yes that could be standardised", "yes that's
> possible.." .... So let's decide! (a first draft of course...)
> 
> I think that the pipeline should be built dynamically at run time (It
> can be computationally expensive: it is run only once!)  because that's
> one advandage of libggi3D when not using high level API (only).
> With (as an option) configuration files, to skip this step for usual API
> (openGL has its pipeline built only once).
> 
> I think this further design step (what does that modularity design mean,
> concretly) is not easy, but must be started as soon as possible to avoid
> spending time on the module implemtentation if the concept is not
> usable.
> Because it still a bit fuzzy...  (for me at least...)
> 

----- big snip ----

So what are we looking at then??

(I expect this to be ripped apart but if it gets us going, I dont mind)

Plan A:

An integer interface descriptor and an integer module descriptor.

The interface descriptor does just what it says.
i.e.
interface one takes a single 2d coordinate,
interface two takes a single 3d coordinate
and so on. Using an integer should allow us to grow to support whatever.
By querying a module for its input and output interface descriptors it
should be easy for some higher level module to join these components
together. Several 'translators' could also be constructed in order to
change one interface to another in order to enable all sorts of modules
to be plugged together.

The module descriptor consists of a number which says - phong lighting,
32bit rasteriser and so on with a bit to say whether this is hardware
accelerated or not.

Plan B:

A similar thing but using printf style formatting strings.
i.e.
"xy" takes a single 2d coordinate.
"xyz" takes a single 3d coordinate and so on.


I feel that a number based system would be faster as they can be acted
on directly.

Compilation will yeild a set of usable modules. At this time, a
configuration list or map which details these modules could be
generated. That will allow the runtime system to have a menu on hand. A
runtime registration function should also be provided which will allow
developers to register their own custom modules, equipped with suitable
interface descriptions of course.

Once this is in place, a higher level policy module (or arbitrator)
would be responsible for connecting the pipeline together based upon
requests from the developer.
i.e.
depth buffer, flat shading etc.

Because this is a module based system, the developer should be able to
access various modules directly but after a request to the policy
module.
i.e.
give me a 8 bit rasteriser with this interface spec.
give me a hardware text renderer with this interface spec.

Part of the policy modules' task would be to fit suitable translators to
an existing module in order to fit the request.

Right then, there you go boys (and girls?) go for it.


Bryan (running for cover...)

-- 

Oh Bugger...