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

Re: LibGGI3D RFC

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

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

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?

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?
(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 :)

You're probably starting to see what boundaries I hit with lotsa rendering
info possibly passing through (ie: triangles with textures + gouraud
shading :)
I'll get back on this one later - am rereading OpenGL docs again...  to
review for simplified functionset? *grin*

[clipa-clipa]
> 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 :)

hmm Makes me think. (more later :)

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

> Hence my remark that zbuffer handling wouldn't be so costly in comparison
> to texture management... (I admit I did not consider both simultaneously.)
> 
> 
> Where am I wrong on what I say ? (if you understood anything at all ;-)

Does this message help any?  Are we communicating or arguing about
completely different topics thinking they're the same? :)

G'day, eh? :)
	- Teunis