Note to users:  turning backfacing culling on may improve performance;
will make no visual difference when join style is CAP.

-------------------------------------------------------------------

Work left to be done:
---------------------

1) cylnder/cone tesselation should be adaptive ...
2) round-join tessleation should be adaptive.

4) Need to interpolate normal vectors for fillet triangles.  Not doing
   this results in visual artifacts in certain cases.

5) Need to interpolate colors for fillet triangles (not doing this
   leaves potential for visual artifacts, although I haven't yet seen 
   any.)

6) allow user to install callbacks for V3F, etc (similar to callbacks in
   gluTess).

7) given i, j point, return actual x,y,z, coords.

10) Some end-caps are concave ... OpenGL GLU utilioty does a sloppy job
    of concave polygons ... so some of the figures look bad. What to do
    about this?

11) The ex_raw.c module would probably execute ()some tens of cycles) 
    faster if it had a ex_angle type interface for the normal vector gorp.

13) Testing problem -- I'm worried that contours with only two points will
    croak the "cut_join" style code.  Be sure to test this.

17) polycone raw endcaps are flashing colors -- some kind of bug.

18) Write the @#$%^&*( documentation.

-------------------------------------------------------------------

FIXED:
------

3) round join style not doing backfacing properly at this moment.
   FIXED 3 June 1993

9) extrusions with more than 64 vertices in the contour may overflow the
   hardware ... our bgn...end constructs may have to check for such cases
   ... (for h/w with the 256 vertex limit only).

   A: Punt. Most hardware today doesn't have this limit anymore.

12) Another significant optimization that can be performed is to convert
   many of the routines to work along z-axis only.  One reason this was
   not done right off the bat was for readability and maintainability.
   However, once the code becomes stable, this may be a good idea. 
   (What I mean here is that many routines, such as "intersect()" and
   "CUTTING_PLANE()" perform operations on x and y coordinates.  These are
   needed for a GENERAL "intersect()" routine; however, the way that they
   are used below does not require that generality (since all of the
   drawing occurs parallel to the z-axis).  With a little bit of careful
   thought, the x and y computations could be ripped out).
 
   A: But this will not work if there are twists in the contour, since 
      now, extrusions do NOT run parallel to z-axis, and the x,y
      coordinates are non-trivial.
   
14) Q: convert extrude.c to work in a bgn/end style of collecting up data?
       (how to handle 2x3 affine matricies in the bgn/end style?)
    A: Don't do it.  It would make it hard to deal with the per-vertex
       affine matrices.  A much better idea is to implement a C++ object
       which has a begin-end interface for each poly extrusion object.

15) convert to OpenGL
    Done. However, see note 10 above.

16) add texture demos that demo the texutre hack.

-------------------------------------------------------------------