From: Scott McNab <jedi@tartarus.uwa.edu.au>
  To  : ggi-develop@eskimo.com
  Date: Wed, 19 Aug 1998 12:10:37 +0800 (WST)

Re: LibGGI3D RFC

> 	OK, here's my first stab at nailing down my LibGGI3D system
> proposal.  Feedback is appreciated. 

A few good ideas, however I think there are a number of serious limitations
to this system which will inhibit its usability. I havnt got time at the
moment to comment properly but I'll try to mention a few off the top of my 
head to begin with:

[stuff-cut]

> II. Overall design
> 
> 	So the keyword here is "simple".  If OpenGL is too complex, then
> let's look at what parts of OpenGL we *don't* need: 
> 
> * 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. 

Granted.

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

Sounds fair. 

> * 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.
> 
> 
> 	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.
> 
> 	The first feature is the notion of a camera.  This is just two
> sets of 3D coordinates which specify a viewpoint and a direction.  This is
> necessary to map the 3D coordinate space onto the 2D coordinate space of
> the display.

Umm hangon...the notion of a camera is directly related to the concept
of a model space which we have decided we are not going to deal with.
The triangle drawing code doesnt care where the triangles are in space, 
only what the screen coordinates & Z value are so it can fill the screen
scanlines whilst applying perspective correction on textures etc (and 
Z-buffering).


> 	Next is the notion of triangle drawing.  LibGGI3D will have only
> one drawing function, DrawTriangle().  The triangle is the fundamental
> object of LibGGI3D.  All other 3D shapes can be tesellated into triangles,
> which are the prototypical polygon.

A DrawTriangleStrip() primitive is almost as essential as a DrawTriangle()
primitive because it has the potential to cut vertex bandwidth requirements
by 1/3rd. It is supported by most new 3D chipsets and can also lead to a
more efficient software rendering implementation too.

[more stuff cut]

> 	So, all LibGGI3D does is draw shaded triangles in a particular
> coordinate system.  End of story.  With these simple tools, almost any
> type of 3D hardware/software acceleration combo can be used and used
> fairly well.  Many common 3D video cards are based on triangles, and for
> those that are not (infinite planes, polygons) we can still use triangles
> or collections of triangles to represent polygons or polyhedra.

There is a lot more to 3D than its coordinate system. If you are going to
support coordinate systems directly then you will also need to support
things such as view volume culling etc. Not supporting this properly makes
the API useless. Personally I dont think any of this should be the domain
of libGGI3D...More on this later.

[more stuff cut]

> IV. Other stuff (FAQs)
> 
> Q: What about z-buffering?  You said you were going to make that part of 
> the API.
> 
> A: I changed my mind.  Once you start worrying about buffers, their
> dimensions, their layout, their coordinate system, etc etc you open up a
> whole can of worms.  If people want these features, they can either write
> a DirectBuffer equivalent or draw to a secondary depth buffer.  LibGGI3D
> is for drawing only.  Extra stuff should have its own API. 

Z-buffering is an integral part of 3D rendering. If you dont support this
at the rendering primitive layer then where else are you going to support
it? The whole point is that pixels are accepted or rejected individually.
This means the higher level stuff doesnt need to worry about calculating
how to render two polygons which may be intersecting in any number of
ways. Drawing intersecting 3D objects is almost impossible without
Z-buffering, or at least extremely computationally intensive and 
impractical.

[more stuff cut]

> A: Nope.  LibGGI3D does not concern itself with hidden surface removal. 
> None of the triangles are "aware" that the others exist.  Remember,
> there's no 3D world here.  If you want a 3D world, write LibGGI3Dworld or
> use OpenGL.

Argh! It HAS to concernt itself with hidden surface removal. Here you
have said you dont want a 3D world yet you want to be able to to draw 
triangles from given world coordinates looking in a specified direction.
Thats a pretty good description of a world modelling system if you ask me.

> 	That's all for now.  Take a look and let me know what you think. 

OK enough complaining, this is what I think :)

1. LibGGI3D should be a 3D primitive rendering system, just like 
   LibGGI2D is a 2D primitive rendering system (well as far as I know).
   Therefore it should provide support for things which are essential for
   rendering 3D primitives which are:

	   - drawing triangles and triangle strips in 2D SCREEN SPACE with
		 additional parameters for Z value (or 1/Z) and shading/texture
		 coordinates etc.
	   - support for 3D specific things such as Z-buffer and possibly
		 alpha buffer.

   This is similar to LibGGI2D which deals with (well should if it doesn't)
   things such as Points, Lines, BitBlt, etc which are 2D specific.

2. LibGGI3D should NOT concern itself with object->world->window space
   coordinate conversions. If hardware becomes available which can
   accellerate this through hardware matrix multiplication of vertices or
   something then this could be incorperated into a separate library.
   This seems to be the biggest point of confusion regarding libGGI3D
   at the moment and I think its important to make a clear distinction
   between 3D primitive rendering and 3D object management/transformations.

A good way to get a better understanding of these things is by downloading
the 3DFX Glide programmers documentation. I'm not saying Glide is the only
way by any means but their library is well designed in many areas. The
distinction between 3D world coordinates and 2D screen coordinates of 
rendered polygons is clearly separated from the library. To include this
in the library makes it considerably more complex because suddenly you 
have to include stuff like view volumes, clipping, etc. This layer is 
what belongs in Mesa/libGGI3DWorld/etc.

This system keeps the library clean and simple and makes it easy to 
provide hardware accelleration support for a range of different chipsets.
It would also map quite nicely to the Mesa device rendering subsystem
if people wanted a complete 3D object management/transformation system
yet still allow for specific cases to use the library directly.

Anyway thats just my first thoughts on the matter. I'm open to comments/
suggestions if you think my head is screwed on backwards ;)

------------------------------------------------------------------------
Scott McNab                                       Phone: +61 8 9386 0540
Software Engineer                                Student Support Officer
Research and Development Dept              University Computing Services
Fractal Graphics                         University of Western Australia
http://www.fractal.csiro.au/                      http://www.uwa.edu.au/
sdm@fractal.csiro.au                            jedi@tartarus.uwa.edu.au