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

Re: LibGGI3D RFC

On Thu, 20 Aug 1998, teunis wrote:

> On Thu, 20 Aug 1998, Jon M. Taylor wrote:
> 
> > 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.
> 
> 
> Finally!  -THIS- is the issue behind clipping.

	Not completely |->.

> According to the person who wrote the GGI3D FAQ, 

	That was me.  I really need to update it. 

> tesselation is -not-
> something to be handled by libGGI3D.

	Tesselation of higher-order shapes into triangles is not to be
handled by LibGGI3D.  Tesselation of a clipped triangle into two
sub-triangles as part of clipping during rendering *might* be handled by a
LibGGI3D *renderer*.

> [and applying a texture is alot easier before tesellation imho]

	If that is the case, the higher layers can do their calculations
for texturing a patch before tesellation and send that info to the shader. 
Would that get around the problem? 

> > > > > > > >  - 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?
> 
> Ah - but available clipping methods may vary per renderer as well...
> texturemapping - none, tesellation, interpolation, depth-buffers only
> 	(you -don't- want to lose where the U,V should be when you clip!)

	Yep.  Either the renderer will have to be smart enough to handle
this, or the higher layers will have to be able to precalculate enough
texturing info that a dumb renderer can do its job correctly.  But I don't
foresee any situations where it just can't be done correctly period.

> > > > > 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.
> 
> It's missing in libGGI2D as well.  the libGGI powers-that-be said "not in
> GGI" and noone has finished an extension to handle it.
> 
> That's why I keep asking!  (and getting the runaround)
> 
> I'm wondering what -it's- API / modus operandi should be!

	You started another thread on this subject, so I'll post my
thoughts there. 

Jon

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