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

Re: LibGGI3D RFC

On Thu, 20 Aug 1998, Rodolphe Ortalo wrote:

> 
> > On Wed, 19 Aug 1998, Jon M. Taylor wrote:
> >> hmm...  Okay - makes sense.
> >> That means doing a
> >> vis=ggiOpen("display-texture", [view options]);
> >> vis=ggiOpen("display-Zbuffer", ...);
> >> vis=ggiOpen("display-wbuffer", ...);
> >>
> >> Yes?
> >	Yeah.  They you'd maybe use something like LIBGGI[3D?]_DISPLAY =
> >cache:[texture,zbuffer,...].  I dunno LibGGI *that* well yet.
> >
> >> 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.
> 
> Well, it seems to me that I'm starting to understand the way you want
> to go... However, there may be some problems in doing so... (Even though
> libggi should provide a convenient framework.)
> 
> The extension mechanism of libggi provides a mean to add _new_ functions
> to the GGI API, available for a given ggi_visual_t.
> This means that you can add a function ggi3dDrawTriangle(x,y,z) easily
> (NB: The x,y,z parms are here just because I _need_ parms for the following,
> I don't mind if this is realistic.)
> This is the purpose of extension libraries.

	Yes, I understand.

> A display target allows you to _specialize_ the functions (ie: to adapt
> them to a specific environment). E.g. you can provide a
> ggi3dDrawTriangleDamnFastOn16Bpp(x,y,z) function in a display-damnfast-16bpp
> display target. And the user will not call it directly, it will simply
> use the normal ggi3dDrawTriangle(x,y,z).
> This is the purpose of display target and dynamic loading of specialized
> lib. (As you guessed, the "stub" lib is the generic lib that gets loaded
> anyway if there is nothing specialized for the running environment.)

	I understand this, too.

> However, with respect the zbuffer issues, textures, etc. on libggi3d it
> seems to me you are doing the two things at once...

	I don't mean to, I just don't understand some of the finer points
of buffer handling in LibGGI.  I'd like to do the 3D buffers as close to
the same way the 2D buffers are done. 

> Okay, drawing with textures enabled is only a particular way of shading.
> But it also implies a different number of parms for the function that
> draws triangles...

	Nope.  It all goes into the particular shader_data struct, which
gets passed to the shader function via a void pointer.  All you need is
the one void pointer and the one shader_function_type pointer and you are
all set. 

> So, I don't think you can simply provide ggi3dDrawTexturedTriangle(x,y,z,u,v)
> through a display target, you also need the extension lib (because of the
> u,v parms...)

	No, all you need is a different shader function.

> You can turn around this (e.g. for texture management) using some
> kind of "drawing context", with a function like ggi3dSetShaded(the_shader).

	That could be done as well. 

> But, can this prevent you from having a ggi3dDrawTexturedTriangle function
> which arguments are different from the normal ggi3dDrawTriangle ?

	You don't want specialized drawing functions, because you'll end
up needing 10000000 different ones and the only differences will be the
shading. 

> If not (and I suspect not, or I would not argue) then you have another
> function added to libggi3d that you did not want...
> 
> 
> So, I don't know exactly the API you want to use, but it seems to me that:
>  - zbuffer management can be turned on/off rather easily, and that conventional
> functions like ggi3dDrawTriangle can have a zbuffer and non-zbuffer
> implementation, hence I thought that feature would be easily integrated
> in libggi3d (through the use of a specialized display target);

	Yeah.  LibGGI2D can draw to a secondary buffer, draw to a
DirectBuffer, or draw directly to the hardware without using a buffer at
all.  I'd like to have the exact same arrangement for LibGGI3D. 

>  - while texture management, on the contrary, seems to require a different
> function (with different arguments from the normal one), hence I thought it
> would be better in another extension lib (libggi3dtextured).

	It just need another shader function with different stuff in its
shader_data struct. 

> Hence my remark that zbuffer handling wouldn't be so costly in comparison
> to texture management... (I admit I did not consider both simultaneously.)

	It is costlier than just drawing to a 2D buffer directly, but if
you want voxels to manipulate later you need to accept that cost. 

> Where am I wrong on what I say ? (if you understood anything at all ;-)

	I think my lack of detailed experience with LibGGI has confused
some people and made them think I am after something complicated WRT
buffers.  I'm not.

Jon

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