From: Paul Sargent <Paul.Sargent@3dlabs.com>
  To  : 'ggi-develop@eskimo.com' <ggi-develop@eskimo.com>
  Date: Thu, 20 Aug 1998 02:45:49 -0700

RE: LibGGI3D RFC

Jon, 

It looks like we are talking at cross-purposes on some things.

> 	It appears from what people have been saying that I am a bit
> under-informed about OpenGL and geometry acceleration.  Mea Culpa.  But
> you still have to use OpenGL extensions, though, right?  Pluggable
> geometry acceleration isn't part of the base OpenGL spec?

No Extensions are needed to accelerate Geometry and Lighting.

Don't worry about not being up on all the finer points of GL (As we've
already said, it's a beast). Basically the way geometry acceleration
goes is that because geometry is behind the API it can be accelerated.
Anything behind the API can be accelerated. And with chips like Gamma (I
use 3Dlabs stuff as an example because I know it), everything is. 

Extensions would only be used if your hardware was able to do something
which GL couldn't. A Topical example would be Multi-texturing. There
exists a Multi-texture extension so that driver writers can expose that
part of the hardware through the API. In fact Mesa has this to allow
software Multi-Texturing

> 	You have a dump truck tire.  I want a racing slick.  Although they
> are both "wheels", the one cannot be used in place of the other (very
> well, anyway). 

I feel that 3D (in totality) is a dump truck sized problem though. The
problem is if you design a F1 car, your going to have difficulty
supporting something the size of a dump truck with it. (Ever think
synonyms are more trouble than they are worth. :-)

> 	But I don't even want rasterization!  All I want from LibGGI3D is
> a standard triangle representation system, abstract triangle drawing
> functions, and the concept of pluggable shaders.  I don't want a graphics
> pipeline, I want a set of hooks into any hardware or software pipelines or
> pipeline subsections.  LibGGI3D *targets* may (will, really) do all kinds
> of representational transforms, coordinate transforms, geometry
> manipulation, rasterization, vectorization, clipping, shading, and
> whatever else you can think of.  But LibGGI3D *itself* will just draw
> shaded triangles.

If you want do draw a triangle, you have a rasteriser. That's what
rasterisation is. Walking along the edges of a 2D triangle and filling
in the raster spans from one edge to the other. You can't get any
simpler.

We would be talking about implementing a handful of commands: glBegin /
glEnd, glColor, glVertex2. That is what you need for rasterisation only.
Simple. Can be optimised to death

> 	It has to be this way, otherwise we are on a slippery slope and we
> will get sucked into reinventing OpenGL.  I don't want that, or I wouldn't
> be pushing a LibGGI3D in the first place.  I want a simple, basic,
> flexible shaded triangle drawing (not rendering, drawing) API.

I don't want to re-invent OpenGL either. I just think that it's a model
that works well, fit's the hardware (because the hardware was designed
to fit it) and is scaleable.

> > GLU is the utility library that allows drawing of Polyhedra & Surfaces,
> > but that just calls OpenGL. So you could take the Mesa implementation
> > and use it with any GL library.
> 
> 	Or with LibGGI3D. 

Indeed!, but only if the API is the same ;-)

> 	Shading and texture mapping is included with the pluggable
> shaders. 

I like this pluggable shaders thing. Although I've still got to get my
head around it completly. Sound like it will be a software only thing.
Is that right? (I 'spose apart from the standard ones like flat, gourad,
gourad + Z, gourad + Texture, etc)

Paul