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

Re: LibGGI3D RFC

On Thu, 20 Aug 1998, teunis wrote:

> On Thu, 20 Aug 1998, Jon M. Taylor wrote:
> 
> > On Wed, 19 Aug 1998, teunis wrote:
> > 
> > > On Wed, 19 Aug 1998, Jon M. Taylor wrote:
> > > 
> > > > On Wed, 19 Aug 1998, teunis wrote:
> > > 
> > > I'm curious, as moving any of the X,Y[,Z] coordinates will affect the
> > > remainder of the coordinate list...
> > 
> > 	For one triangle this shouldn't be a problem.  For a set, you do
> > what you can. 
> 
> so what happens if you clip a triangle and you lose the corner [u,v]
> coordinates?  All of a sudden your texture is moving around when it gets
> clipped.  The same happens for colourblending when you have discrete
> colour components per-corner - all of a sudden your blends get messed
> up...
> 
> How do you mean to handle this?

	Clip and retesselate the triangle before you apply a texture map. 
Won't that take care of the problem?  I have to admit that my texture
mapping knowledge is not a strong as it could be, but I'm not seeing why,
if you clip and retesselate the triangle(s) before you do any shading, you
won't be OK.

> > > > > >  - I want clipping in libggi3d also.
> > > > > 
> > > > > See above...  and this requires also the camera info (view frustrum,etc)
> > > > > to be available....
> > > > 
> > > > 	Right. 
> > > 
> > > So how does this work?
> > 
> > 	Attach it as a struct to the visual. 
> 
> not what i meant *sigh*.  I mean how do you expect clipping to work?

	Oh.  Sorry |->.  Well, I guess it would really depend on the 
rendering target.  If rendering directly to triangle hardware, maybe no 
clipping at all (the HW would do it).  If rendering to a depth buffer, 
you could render eatch triange or triangle set into a secondary buffer 
sized to not need clipping and then copy that into the master buffer, or 
directly into the master buffer if no shading/texturing issues are present.

	The point is that the clipping is target-specific.  there won't be
one (or more) "standard" LibGGI3D clipping techniques, because there are
so many different ways to render 3D.  In LibGGI2D, things are a lot
simpler.  In 3D, you can render to a 2D buffer and clip there, or you can
render to 2D hardware with hardware clipping, or you can do a
sutherland-hodgman algorithm in 3D, or you can retesselate, or you can
retesselate with varios kinds of interpolation, or you can render into a
depth buffer and clip there, or you can render into a hardware depth
buffer and the hardware will clip, or you can render triangles directly to
the hardware, or... see my point?

> [clip]

	Heheh.  At last that clipper is simple |->. 

> > > Though there should be some kind of internal mechanism for handling
> > > display memory!  (so it doesn't get all fragmented and can be used
> > > effectively!)
> > 
> > 	I guess the buffer system doesn't *have* to be in a target.  AAIK 
> > is isn't(?) in LibGGI2D.
> 
> Supposedly DirectBuffer handles this.  Will someone -please- tell me the
> status on non-primary-display DirectBuffers?!?!?!?!??!
> WHAT NEEDS DOING?

	Don't ask me, I'm just learning this stuff.  If it hasn't been
done, it will probably have to be implemented as part of writing LibGGI3D. 
Not initially, but eventually.

Jon 

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