From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Wed, 19 Aug 1998 22:02:39 -0700 (PDT)

Re: LibGGI3D RFC

On Wed, 19 Aug 1998, Sengan Baring-Gould wrote:

> Jon M. Taylor wrote:
> >      Next is the notion of pluggable shaders.  A triangle is drawn by
> > setting a bunch of pixels.  What shade those pixels are can be determined
> 
> > in a huge number of different ways.  LibGGI cannot possibly avoid bloat if
> > it has to know about all those ways to shade triangles.  Therefore,
> > DrawTriangle can take a pointer to a shader table entry, which contains a
> > pointer to a shader function.  Thus, the code using LibGGI3D can implement
> > arbitrary shaders and LibGGI3D doesn't need to know about the gory
> > details.  Both prebuilt shader functions (SHADE_PHONG,
> > SHADE_GORAUD_TEXURED, SHADE_FLAT, etc) and user-defined shader functions
> > go in this table.  The prebuilt shaders allow DrawTriangle() to use
> > hardware shading if it is present, or fall back to software shading if it
> > is not.
> 
> What about texture mapping, etc. 

	Texturing == shading.

> Something like Enlightenment/Gtk with
> themeswould do well to use this. 

	Yeah, it could definitely speed things up. 

> Also assigning gart space is definitely a GGI
> kernel
> level thing.

	What's "gart space"?  I'm not familiar with the term. 

> > * struct camera { float x1, y1, z1, x2, y2, z2 }. Every LibGGI3D display
> > will have a camera struct attached to it.  A generic hook for arbitrary
> > display data should also be present - the shaders might use it.  void
> > *private_data.
> 
> 
> 
> > * int DrawTriangle (float x1, y1, x2, y2, x3, y3; shader_index shader; void
> 
> > *shader_data) is the core drawing function.
> 
> These lines seem to contradict: 2D triangles but 3d camera?

	I goofed.  There should be z coords in DrawTriangle() too. 

> > Q: What about z-buffering?  You said you were going to make that part of
> > the API.
> >
> > A: I changed my mind.  Once you start worrying about buffers, their
> > dimensions, their layout, their coordinate system, etc etc you open up a
> > whole can of worms.  If people want these features, they can either write
> > a DirectBuffer equivalent or draw to a secondary depth buffer.  LibGGI3D
> > is for drawing only.  Extra stuff should have its own API.
> 
> I disagree. Z-buffers are in the hardware: the card gets a triangle in
> 3spaceand draws it to 3space.

	Depth buffers (z-buffer is a HSR rasterization algorithm) are
*somtimes* in hardware.  Sometimes they are in software.  Sometimes both. 
Sometimes neither.  Depth buffers, direct-to-hardware or secondary, should
definitely be an option but not required.

Jon

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