From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : Paul Sargent <Paul.Sargent@3dlabs.com>
  Date: Thu, 20 Aug 1998 19:57:00 -0700 (PDT)

RE: LibGGI3D RFC

On Thu, 20 Aug 1998, Paul Sargent wrote:

> 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). 

	Yeah.  It is more than a bit intimidating, to be honest.  I like
simple, clean, modular APIs that build on each other.  I have put off
digging into OpenGL (and X too |->) because of this.  But I really need
to.  I'll probably do that after I have gotten my hands dirty with
LibGGI3D.

> 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

	OK.  I had read that OpenGL "didn't expose the geometry pipeline" 
and took that to mean that geometry couldn't be accelerated.

> > 	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. 

	_In totality_, yes.  Where is it written that you have to swallow
the whole thing in one bite?  Even OpenGL doesn't handle *everything*.

> The
> problem is if you design a F1 car, your going to have difficulty
> supporting something the size of a dump truck with it. 

	I'm not trying to.  Maybe I can learn some useful stuff about
automotive design, internal compustion engines, etc. from designing the
race car, but ultimately a dump truck is a whole other design and should
be looked at on its own terms - good for some stuff, overkill for other
stuff, and even worse at a few things.  Same with LibGGI3D and OpenGL.

> (Ever think
> synonyms are more trouble than they are worth. :-)

	Yeah |->.  But that wasn't a bad one, actually.

> > 	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. 

	Somewhere.  It may be in the hardware. 

> That's what
> rasterisation is. 

	If I want to target LibGGI3D to a vector display, I won't be doing
any rasterizing.

> 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

	Of course this kind of code will be present.  But it will be in
the display targets.

> > 	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)

	The shader functions themselves will be software-only, because a
"shader function" for hardware shading is a meaningless concept.  What the
pluggable shaders concept gives you is a way to separate shading from
rendering.  If I call DrawTriangle() and tell it to use a phong shader, it
can transparently use hardware color ramps if available, or fall back to
the software phong shader I passed it.  And I don't need a separate
DrawPhongShadedTriangle() function either.

Jon

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