Index:
[thread]
[date]
[subject]
[author]
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
Index:
[thread]
[date]
[subject]
[author]