From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Thu, 18 Mar 1999 15:24:37 -0800 (PST)

Re: LibGGI3D design problem?

On Thu, 18 Mar 1999, Xavier Bouchoux wrote:

> Hi!
> 
> It occured something to me about what I understand to be the basis of
> libggi3d desing:
> 
> [...]
> >  This means that
> > the user can construct complex pipelines out of modules attached to the
> > visual and have the whole rendering process kick off when ggiFlush() is
> > called on that visual.  Fully automatic rendering with the ability to tweak
> > the pipeline layout as much as you want at runtime!  
> [...]
> 
> (Maybe I get this wrong, but for me this means that every program using
> libggi3d can tweak its rendering pipeline.) 

	If the visual module allows for such tweaking, yes.  Some will,
some won't, some will to varying degrees.  It is completely dependent on
that particulars of the situation. 

> But there is an issue with that:
> why is the openGL pipeline static and unchangeable? Because on high end
> card it is implemented in hardware only!
> So how can any program change the modules of libggi3d, if they represent
> some hardwired stuff? (in a precise order, where the only tweaking you
> can _maybe_ do is to turn on/off some parts of the pipeline, and not at
> all remove or add modules)

	In this case, there would only be a limited amount of tweaking
that would be allowed by the visual module.  But you must remember that
OpenGL is not the only API that can be used with GGI3D, and actually it is
not necessary to wrap any API at all around the pipeline(s) that are
attached to a given visual.  API wrappers are for those who want them and
for lagacy compatibility.  I continue to claim that the best way to use
GGI3D will be to take direct control over the pipelines and modules
yourself.

> So for me that means that the libggi3d design is very nice when thinking
> of software modules, or maybe small independant hardware modules (for
> instance, glide rasterizer and k6 3D instructions for the geometric
> transfo), but not at all for highend hardware. 

	Not at all.  If you load a GGIMesa extension library onto a
visual, and that extension library makes use of GGI3D modules internally
to implement the OpenGL API (which is what I am assuming will be done, as
I will probably be writing most of this myself), all of the rendering will
ultimately go through the visual module which is associated with the
visual you are rendering on.  In the case of high-end hardware as you
describe, the visual module will probably _be_ the whole "pipeline", as
all it would need to do is take the GGIMesa API calls and push them down
to the hardware directly - a very thin hardware communication layer, in
other words.  Thus, there is really no issue here regarding improper
tweaking of the pipeline - there's no pipeline to tweak in this case!  The
only time you will have tweakable pipelines is when you have some of your
pipeline composed of soft-rendering.  In these cases, some degree of
tweakability may be called for, or not, depending on the particulars of
the situation. 

	If you are a programmer who only desires to use prepackaged
high-level rendering modules (or an API bridge such as GGIMesa), you will
probably not be doing much if any tweaking of the GGI3D pipelines you use. 
The pipeline layout will probably be determined solely by the nature of
the visual you are rendering on - your "display target", to use a LibGGI
term.  But if you are writing device drivers for a complex graphics
chipset which has a lot of features but does not export OpenGL directly
from the hardware (as I am currently), there will be many different ways
to use the functionality that your hardware exports, and therefore there
will be many different possible pipelines that can be designed to
terminate by rendering through the visual module to your hardware.

	This illustrates what I consider to be one of the fundamental
advantages of GGI3D - all of the functional and contextual abstraction can
take whatever form is appropriate to your needs, and that form can be
anything at all. No matter what kind of hardware you have, no matter how
you want to represent that hardware, no matter what types of lower-level
hardware or software functionality you want to bind together into more
abstract higher-level representational systems - GGI3D can do it all.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed