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

Re: LibGGI3D RFC

On Wed, 19 Aug 1998, James A Simmons wrote:

> > * 3D world modeling.  We don't need it, and it can be implemented on top
> > of LibGGI3D if needed.  Our job is to do 3D drawing, not model worlds. 
> > 
>
> Yes. And are their any cards that do this in hardware? I don't think so.
> Might be wrong.

	Not as far as I know.  Maybe some custom high-end VR hardware or
some military flight simulator systems, but not consumer-level stuff.  Of
course, now that 3D hardware is being put in the CPU (AMD K2, etc) you
could say that it *is* being done in those cases.

> > * Complex object representational schemes (polyhedra, surfaces,
> > constructive solid geometry).  Again, this is a job for a higher-level
> > API.  All of that stuff is tesselated down before rendering anyway, so
> > LibGGI3D can be designed with the assumption that such tesellation has
> > already been done.
>
> Agree. Support only triangles. I seen your earlier post about triangles.
> I have code to turn polygons into triangles. What is also nice about
> triangles is we could use RAPID for collison detect. Its the fastest
> method out their and it tells the exact place of intersect. Image a game
> were you could blow holes threw people. 

	This would be good for PenguinPlay. 

> > * Lighting, shading, texture mapping, or any other such algorithms.  All
> > of these are methods for determining the color of a pixel based on certain
> > data.  If we give up world-building (see above), we no longer have the
> > necessary information to shade pixels properly.  We need to provide a
> > general way to shade pixels, but not make any assumptions about how that
> > shading should be done.  That, again, is a job for higher API levels.
> > 
> 
> I believe their is away around this. Yes we couldn't directly support this
> but we could emulate this using something similar to pluggable shaders
> idea. The use of color functions to map colors to the framebuffer.

	Sort of like what is done by the trueemu and palemu targets, but
with a more general focus.  Pluggable colorspace conversion functions.  I
like it!  It has applications beyond LibGGI3D, too.  If the rest of LibGGI
could do this sort of thing, the need for trueemu and palemu would
disappear.  Each drawing operation could convert from any color format to
any other format just by dropping in a different conversion function on a
per-drawing-request basis.

> > 	So, what are we left with?  Essentially, we are left with two
> > basic concepts: 3D drawing and 3D shading.  That is all we need in our
> > API. But of course there are features we will need to have in order to 
> > implement these primitives cleanly and with maximum flexibility.  So now 
> > we get to the specifics of the LibGGI3D API design.
> 
> No problem. Plus this is all modern 3D cards do.

	Not all.  PowerVR's infinite planes works with polyhedra too.

> > III. Design specifics.
> > 
> > * struct camera { float x1, y1, z1, x2, y2, z2 }. Every LibGGI3D display
> > will have a camera struct attached to it.  A generic hook for arbitrary
> > display data should also be present - the shaders might use it.  void
> > *private_data. 
> > 
> > * int DrawTriangle (float x1, y1, x2, y2, x3, y3; shader_index shader; void
> > *shader_data) is the core drawing function.
> 
> Should go into the kgi drivers accel.

	Yes, if the hardware does triangles.  If the hardware is
unaccelerated, you fall back to software drawing.  If the hardware does
polygons or infinite planes or whatever, you have some massaging to do
before the hardware gets the data.  You may not even want to use
DrawTriangle() in these cases - DrawTriangleSet() would be the way to go
so you don't lose object information. 

> > * int DrawTriangleSet(triangle_set *triset; shader_index shader; void
> > *shader_data) draws set of triangles, which can be used to draw polyhedra
> > for hardware like infinite planes.  If future hardware can draw surfaces
> > directly, triangle-based surface patches can be used with this function as
> > well. 
> 
> Should kgi drivers support triangle sets? IMHO no.

	KGI drivers should support whatever the hardware supports.  If the
hardware supports triangle sets, so should the KGI driver.

> > * shader_index register_shader(shader_func *myshader) registers a custom
> > shader function with the system and returns an index into the shader
> > table.
> 
> No problem. KGI drivers can support that in accel. Also software emulation
> can be small if you use my color funtion idea. One line of code for each color
> component. 

	I'd let the shader decide how to handle the RGB components.  If
the shader does translucency/refraction or does something wierd like
simulate a diffraction grating (??? but possible!), it'll need all the
color info.

> > * int unregister_shader(shader_index myshaderindex) unregisters a shader. 
> > On GGI_exit(), all registered shaders are forcibly unregistered.
> > 
> > IV. Other stuff (FAQs)
> > 
> > Q: What about z-buffering?  You said you were going to make that part of 
> > the API.
> 
> Think about that more in depth. No pun intented. Think about allocating
> frames and labeling them as specific types.

	This is the way to go.  depth-buffer, alpha-buffer, w-buffer, 2D
texture buffer, 3D solid-texture buffer, etc.  Each buffer type needs
special handling.  LibGGI3D can't be expected to know about all this.  Do
it in the rendering targets or a separate buffer-handling library
extension.

> > Q: If I draw a triangle close to the camera and then draw another one much
> > farther away such that the first, closer triangle should occlude the
> > second, further one, the second one instead is drawn over the top of the
> > first one!  Isn't that wrong behavior?
> >
> 
> Possible Z buffer. 

	Right.  *Render* to a z-buffer HSR algorithm, or a painter's
algorithm, or a full depth buffer, or whatever.  LibGGI3D doesn't do that
sort of thing, the rendering targets do.

> Or could use culling for cheesy hidden surface
> removal.

	Backface culling should be done to the triangle sets (which
presumably representing polyhedra in this case) before sending them to
LibGGI3D for rendering.

Jon

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