From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Thu, 20 Aug 1998 20:32:38 -0700 (PDT)

Re: LibGGI3D RFC

On Thu, 20 Aug 1998, teunis wrote:

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

	I agree.  That is why I am putting so much time into soliciting
feedback. 

> A pure triangle-renderer that knows nothing about
> triangles around itself is -slow- on more advanced rendering.  

	Truly.  That is why I proposed triangle sets, which are triangle
patches + metadata.

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

	Very nice.  That is very close to what I had in mind. 

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

	And arbitrary metadata can be attached to the individual triangles
and/or the triangle set.

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

	Again, this sounds like what I was aiming for.  Although I don't
know much about infinite planes either |->.

Jon

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