From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : teunis <teunis@computersupportcentre.com>
  Date: Wed, 19 Aug 1998 19:12:18 -0700 (PDT)

Re: LibGGI3D RFC

On Wed, 19 Aug 1998, teunis wrote:

> On Wed, 19 Aug 1998, Jon M. Taylor wrote:
> 
> > On Wed, 19 Aug 1998, Andrew Apted wrote:
> > 
> > > Jon writes:
> > > 
> > > >  III. Design specifics.
> > > >  
> > > >  * 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. 
> > > 
> > > I guess x1,y1,z1 is the camera position, and x2,y2,z2 is the normal to
> > > the viewplane, but what about the orientation of the viewplane (the "up"
> > > vector for want of the precise term) ?
> > 
> > 	On reflection, I think I will have an observer X, Y, Z and a view
> > orientation theta, phi, alpha.
> 
> And a near/far clipping planeset...
> (a whole viewing frustrum is handier - especially for clipping :)

	I'd prefer to handle clipping separately.  If DrawTriangle() and
friends can assume that there are no clipping/overlap issues to deal with,
the drawing routines will be a lot simpler.  Hardware either does its own
clipping or expects the clipping to already be done.  I agree that
clipping (of triangles) should be part of LibGGI3D, but not part of
DrawTriangle().

Jon


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