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

Re: LibGGI3D RFC

On Thu, 20 Aug 1998, teunis wrote:

> On Thu, 20 Aug 1998, Rodolphe Ortalo wrote:
> 
> [clip]
> > 
> > A display target allows you to _specialize_ the functions (ie: to adapt
> > them to a specific environment). E.g. you can provide a
> > ggi3dDrawTriangleDamnFastOn16Bpp(x,y,z) function in a display-damnfast-16bpp
> > display target. And the user will not call it directly, it will simply
> > use the normal ggi3dDrawTriangle(x,y,z).
> > This is the purpose of display target and dynamic loading of specialized
> > lib. (As you guessed, the "stub" lib is the generic lib that gets loaded
> > anyway if there is nothing specialized for the running environment.)
> 
> hmmm.....  there's a way to associate additional coordinate data with a
> triangle but I can't remember how...

	Well in principle you can associate *anything* with a triangle. 
But my idea is that this type of thing will be done by high-level
triangle/object handling code, and any traingle "metadata" (vertex
normals, etc) that would be needed for shading purposes would be
precalculated and passed to the shader in the shader_data struct.  If
per-triangle data is still needed, maybe a void *triangle_data could be
added to the triangle struct or something. 

> Here's some useful additional coordinates:
> 	U,V	- texture / etc coords
> 	[Un,Vn]	- multitexturing - additional coords as needed....
> 	R,G,B,A - gouraud shading.  the colour gets blended across triangle
> 	X,Y,Z   - the _original_ set for lighting conditions
> 	MIXn	- a blending coefficient for blending textures together...
> 		(wrote this for fun one time - varies blend levels
> 		 across triangle :)
> 
> Then there's fixed (triangle-wide) data:
> 	Texture
> 	Flat shade  (I occasionally use this as lightlevel -with-
> 		     gouraud-shading :)
> 	material definitions (light reflection,ambience,...)
> 
> if that helps any (I doubt it)...

	It helps me.  You seem to be the man with the knowledge on this
subject, so I guss I will defer to you on how best to handle this data
with clipping, etc.

> How about
> ggi3DTriangle(X1,Y1,Z1,X2,Y2,Z2,X3,Y3,Z3,int shader,void *data);
> and have the shader understand the additional coords within *data?

	That's the idea.  But issues arise with DrawTriangleSet(), which
also gets a shader type and shader data.  How do we handle per-triangle
data in that case?  Do we have to?  That's what I was trying to get away
from with my "interpolate the normals when clipping" thing.  But if we
have to have per-triangle data, we have to have per-triangle data.  I just
don't want to slow things down any more than necessary. 

> Or even better:
> struct 3d_tridata { int shadeID; float x1,y1,z1, x2,y2,z2, x3,y3,z3; };
> and use "poor man's inheritance" to override this like so:
> struct 3d_flatshade   { struct 3d_tridata bit; ggi_color c; };
> 	(assign type=FLAT SHADED)
> struct 3d_textriangle { struct 3d_flatshade bit;
> 			float u1,v1,u2,v2,u3,v3 };
> 	(assign type=FLAT SHADED TEXTURE)
> 
> int ggi3DTriangle(struct 3d_tridata* data);
> 
> What do you think?

	How about something more generalized: 

struct triangle
{
	float x1, y1, ....;
	shader_type shader;
	void *shader_data;
}

struct shader_data_flat_textured 
{
	float u1, v1, ....;
	ggi_color c;
	texture_buffer *buffer;
}

	...and have the shader functions cast shader_data to a pointer to the
appropriate shader_data_xxx struct based on switch(shader_type).  This
encapsulates all the extraneous data in the shader_data_xxx structs and
lets us have one standard triangle struct. 

> (I have problems with this but that's another story....  has to do with
> triangle-compression systems...)
> 
> Also to cover points:
> 	Z buffering should exist as a GGI(3d?) target so that new commands
> 		will be able to use it immediately..
> 		(ggi3Dpoint, ggi3Dline, ggi3Dtriangle as primitives?)
> All ya have to do is set the target and voila!  instant Z-buffering
> support :)

	I'm starting to wonder about this, actually.  I wish I knew more
about the 2D buffer handling - I'd like to follow its design lead as
closely as is feasible.

> You're probably starting to see what boundaries I hit with lotsa rendering
> info possibly passing through (ie: triangles with textures + gouraud
> shading :)

	It'll get expensive if *every* triangle needs to drag a bunch of
data around with it, but for triangle sets a lot of data is per-set rather
than per-triangle so that might help a bit.

> > So, I don't know exactly the API you want to use, but it seems to me that:
> >  - zbuffer management can be turned on/off rather easily, and that conventional
> > functions like ggi3dDrawTriangle can have a zbuffer and non-zbuffer
> > implementation, hence I thought that feature would be easily integrated
> > in libggi3d (through the use of a specialized display target);
> 
> Z-buffer target!
> (hmm - and future reference: 3D multidisplay target where one screen=left
> eye, another=right, and other permutations :)

	LIBGGI_DISPLAY=3dmulti:[eye_coords1, target1, eye_coords2, 
target2, ....

> hmm Makes me think. (more later :)

	Me too.  This is going to be fun! |->

> >  - while texture management, on the contrary, seems to require a different
> > function (with different arguments from the normal one), hence I thought it
> > would be better in another extension lib (libggi3dtextured).
> 
> It's not so simple....  but maybe it is?

	It is, IMHO. 

Jon

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