From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Wed, 19 Aug 1998 17:18:05 -0700 (PDT)

Re: LibGGI3D RFC

On Wed, 19 Aug 1998, teunis wrote:

> On Wed, 19 Aug 1998, Rodolphe Ortalo wrote:
> 
> > [I don't quote anything from former posts, because I guess
> >  everyone read them, and they are long...]
> > 
> > Well, first, let's say I'm glad of the way this RFC was written and
> > commented. I'm also glad that Jon did this first try... (In other words,
> > thanks for the work ;-)
> > 
> > 
> > I tend to agree with the overall design of Jon. And I also tend to
> > agree with the comments Scott McNab made.
> > 
> > To summurize my views (with Jon's proposal as the basis):
> >  - I don't really feel the need for having a notion of camera in
> > libggi3d. I would be happy with simple 2D parameters in libggi3d
> > (in fact, projected 2D parms, plus 1/Z, U,V, etc...)
> 
> I can't think of a reason unless libGGI3D does clipping (which is a good
> idea).  In that case, full camera info -should- be present - or at least
> available to the renderers.
> 	(a 'renderer' extension to libGGI3D?  or KGI/...?)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	That is to be done in the LibGGI3D display target.

> >  - I think that Z-buffer wouldn't be so annoying to manage.
> > Jon does not seem to have the same view, so, could you point the things
> > that worry you on this point Jon ?
> 
> A Z-buffer requires X,Y,Z present...

	Right.

> (hmm - yer comment above about U,V,...  hmmmm.  I've got code that has up 
> to 27 discrete coordinates... just a simple gouraud-shaded
> multitexture+transform renderer...)
> 
> >  - I also think alpha management could be very useful and not so
> > difficult... (Same comment as previous point.)
> 
> it's part of that shading_data...
> 
> 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.

> >  - I want clipping in libggi3d also.
> 
> See above...  and this requires also the camera info (view frustrum,etc)
> to be available....

	Right. 

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

Jon

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