From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Mon, 17 Aug 1998 22:00:27 -0700 (PDT)

RE: 3d

On Mon, 17 Aug 1998, David Waite wrote:

> When it comes down to it, 3d graphics hardware is not standardized enough to
> create a standard abstraction layer. 

	It all depends on what you think that interace should consist of. 
I think a z-buffer and polygon based system with pluggable shaders could
be used with almost anything out there right now.  Systems based on
polygons(duh), polyhedra, bezier surfaces, NURBS, or constructive solid
geometry (infinite planes, etc) could all be decomposed into polygons by
higher-level bridge code.  The polygon code could render directly to the
hardware in some cases (infinite planes, polygons, polyhedra) or decompose
into triangles for triangle-based hardware like the 3Dfx Voodoo chipset or
Virge.  It could also be treated as a mesh surface patch for bezier or 
NURBS rendering.

	A z-buffer means that the API functions take one more coordinate
(duh), but also that there is a depth buffer available.  This could be
done a la DirectBuffer - if you used it, your drawing commands would
render to the depth buffer and from there to the display.  otherwise you
would just be drawing dots on the screen, each triangle unconnected to the
others.  For people who just want to render a shape with a shade to the
display, this is small, tight and fast if you don't use the
DirectDepthBuffer thing (and pretty fast anyway - the memory cost of the
depth buffer goes way up the bigger your world, but the write-through
itself is just a couple extra cycles).

	Procedural texturing/shading lets you do anything from Phong or
Goraud shading to texture mapping to lighting to refraction, and even
radiosity and ray tracing if need be.  It also allows for custom shaders a
la RenderMan.

	So, with those three basic concepts, we can cover the most
hardware the best and easiest.  Like LibGGI, LibGGI3D would have the
ability to load helper libraries, so the handling of the polygons that are
fed to the rendering functions are turned into the form the hardware (KGI
driver, etc) wants is optimizeable.

> Even with OGL/DirectX, there are some
> cards that do not fit into the generalized scheme at all, and special cases
> have to be made (i.e. PowerVR2)

	Right.  A polygonal base object system lies in the "sweet spot" 
between the simplicity of triangles and the complexity of surfaces.  That
should minimize overall hassles from converting between representational
formats.  The algorithms will be simple and thus easier to optimize for
speed. 

> So, the best scheme in this case is to have the driver be either the
> low-level hardware, or have it be a low-level API that the manufacturer
> provides (i.e. Glide, PowerSGL I believe). Then any "greater" API would
> detect these drivers and abstract them.

	Those APIs serve two main functions: They maintain state info and
bang the hardware (like a KGI driver), and they also Explort a functional
API and do a lot of housekeeping stuff, representational translations
(textures, colorspaces, object representations, etc), which is more
properly done in a userspace library API like LibGGI3D.  We need a Voodoo
KGI driver and set of Glide LibGGI helper libraries.

> This way, you have the benefit of abstraction if it is possible, without the
> large amounts of bloat in kernelspace or other problems by making something
> like Mesa kernel-level.

	Mesa could be built on top of the LibGGI3D z-buffer/polygon/shader
plugin system I outlined above.  But it would still probably be better to
have MesaGGI helper libraries which talk to the KGI drivers directly.  But
it would also be more work - You could build a simple LibGGI3D "driver"
for your KGI driver, and a Mesa that renders to the LibGGI3D API will now
be accelerated too!  This would be (somewhat) analogous to Windows' OpenGL
"mini client drivers" vs. complete OpenGL drivers.

> You also get the benefit as a programmer of being able to program directly
> to the hardware driver, rather than being forced to program for an
> abstraction layer. 

	A good KGI driver gives you the same thing.  You choose your
abstraction layer and then bridge it to the KGI driver with LibGGI helper
libraries. 

> People can still use GLIDE to program 3dfx chips, as well
> as Mesa to generate platform and hardware independant code.

	LibGGI3D, as outlined above, could easily render to a Glide
target, a Voodoo KGI driver, Direct3D, or even OpenGL itself.  Yes, it
could be built on top of OpenGL, or OpenGL could be built on top of it. 
Just like with SVGALib, where it is both a LibGGI rendering target and a
LibGGI-using top-level API.

Jon 

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