From: teunis <teunis@computersupportcentre.com>
  To  : ggi-develop@eskimo.com
  Date: Thu, 20 Aug 1998 19:49:17 -0700 (MST)

Re: LibGGI3D RFC

On Thu, 20 Aug 1998, Jon M. Taylor wrote:

[clipped all but one note!]
> 	Thus, over time the generalized, modular system will get replaced
> by more and more specific-case rendering/shading DrawTriangle() functions. 
> IMHO this sort of evolutionary approach is the way to go, and LibGGI makes
> it quite easy to do.  Get it working first for the general case(s), THEN
> optimize for specific cases.  Often, implementing the general case
> solutions will enable you to get a clearer picture of the nature of the
> specific-case optimization needs, and you might end up being able to
> implement the specific-case optimizations in a better way than if you had
> taken that path from the beginning.
> 
> 	This relates back to the "why don't you just use Mesa"
> discussions.  Just as I am not saying specific-case rendering functions
> are wrong, I am not saying that accelerating Mesa on a specific-case basis
> is wrong.  They are not wrong, but they *are* specific-case optimizations,
> and those should ALWAYS come after the general case(s) have been taken
> care of.  IMHO. 

The point I wish to make is this:  How the API is initially designed shows
how far it can go.  A pure triangle-renderer that knows nothing about
triangles around itself is -slow- on more advanced rendering.  the
extensibility of parameters itself limits things...

Here's an API I just came up with and a few ideas:

typedef int ID_3drenderFunc

struct ggi3d_coordref
{
	float x,y,z;
	void *additional;
};

struct ggi3d_triangleref
{
	struct ggi3d_coordref* cache
	int a,b,c;	/* offsets into cache pointing to current coords */
	ID_3drenderFunc_ID rendering_function;
	void* additional;
};

void ggi3DTriangle(struct ggi3d_triangleref* tri);

and then you can associate more data as needed.  The basic case (invisible
3D triangle - ie no colour data) is still simple.

>From first glance it may look slower but:
	you can cache coordinates (and link 'em together :)
	you can cache triangles
	nothing is assumed about the data (afaik)....

An amusing varient:  (I have no idea if this is what info's needed.  I know
-nothing- about infinite planes beyond some guesswork)

struct ggi3d_planeref
{
	struct ggi3d_coordref* position;
	struct ggi3d_coordref* normal;
	ID_3drenderFunc_ID rendering_function;
	void* additional;
};

void ggi3DInfinitePlane(struct ggi3d_triangleref* tri);

And you can add some cache-generation and cache-management extensions
easily enough to libGGI as well as triangle-lists, triangle-groups, ...
and if you tie the renderer to the cache you can do the more accelerated
tricks :)

What do you think?

G'day, eh? :)
	- Teunis