From: teunis <teunis@computersupportcentre.com>
  To  : ggi-develop@eskimo.com
  Date: Wed, 19 Aug 1998 19:24:09 -0700 (MST)

Re: LibGGI3D RFC

On Wed, 19 Aug 1998, Jon M. Taylor wrote:

> On Wed, 19 Aug 1998, teunis wrote:

[clip]

> > Now thinking about it:
> > 	Coordinate clipping requires info about -all- present coordinates.
> > 		(X,Y,Z[,W][,U,V[,U2,V2..]][colour])
> > 	mayhaps we need to think about this further?  (don't know)
> 
> 	The higher layers could clip during tesellation, and as such
> they'd be able to take all those coordinates into account.

Ah - so the only clipping libGGI3D would do would be?
I'm curious, as moving any of the X,Y[,Z] coordinates will affect the
remainder of the coordinate list...

Now there's render-side clipping (Z-buffering)
Tesellation clipping (ie: viewing frustrum clipping)

So what clipping would libGGI3D handle?
Mayhaps just simple (front/rear) clipping?  (but some triangles may be
doublesided...)

[clip]

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

> > >  - I am not yet completly clear of how you want to manage textures ?
> > > What about texture cache management also ? You associate that to
> > > a particular shader, that's the idea ? BTW, I tend to like that idea
> > > of registering & using shaders like you proposed.
> > 
> > extension to libGGI:
> > 	video cache management
> > handles allocation of videobuffers for functions requiring such (BITBLT in
> > libGGI, libGGI2D, texturemapping in libGGI3D, fonts, additional screen
> > targets for displays that support such, ...)
> > 
> > perhaps
> > int register_buffertype(struct buffertype { int visible, char *name; } )
> > <handle> request_videobuffer(int width,int height,int bpp,int buffer,
> > 			     int buffer_type);
> > 	[it makes sense in case hw needs this on specific boundaries]
> > 
> > either that or:
> > <handle> request_videobuffer(size_t size, int blocktype,
> > 			     void *additional_data);
> > 
> > 
> > I'm not sure from here.
> 
> 	Why not set up such caching systems as intermediate display
> targets?  Drawing functions would render to the caching target, which
> would do the appropriate cache lookups, flushing, updating, etc and then
> render to the final target.  I would work the same way as other LibGGI
> intermediat targets (tile, trueemu, palemu, etc).


hmm...  Okay - makes sense.
That means doing a 
vis=ggiOpen("display-texture", [view options]);
vis=ggiOpen("display-Zbuffer", ...);
vis=ggiOpen("display-wbuffer", ...);

Yes?

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

G'day, eh? :)
	- Teunis