"SfR Fresh" - the SfR Freeware/Shareware Archive

Member "gle-3.1.0/src/README.gutil" of archive gle-3.1.0.tar.gz:

    1 
    2 Note to users:  turning backfacing culling on may improve performance;
    3 will make no visual difference when join style is CAP.
    4 
    5 -------------------------------------------------------------------
    6 
    7 Work left to be done:
    8 ---------------------
    9 
   10 1) cylnder/cone tesselation should be adaptive ...
   11 2) round-join tessleation should be adaptive.
   12 
   13 4) Need to interpolate normal vectors for fillet triangles.  Not doing
   14    this results in visual artifacts in certain cases.
   15 
   16 5) Need to interpolate colors for fillet triangles (not doing this
   17    leaves potential for visual artifacts, although I haven't yet seen 
   18    any.)
   19 
   20 6) allow user to install callbacks for V3F, etc (similar to callbacks in
   21    gluTess).
   22 
   23 7) given i, j point, return actual x,y,z, coords.
   24 
   25 10) Some end-caps are concave ... OpenGL GLU utilioty does a sloppy job
   26     of concave polygons ... so some of the figures look bad. What to do
   27     about this?
   28 
   29 11) The ex_raw.c module would probably execute ()some tens of cycles) 
   30     faster if it had a ex_angle type interface for the normal vector gorp.
   31 
   32 13) Testing problem -- I'm worried that contours with only two points will
   33     croak the "cut_join" style code.  Be sure to test this.
   34 
   35 17) polycone raw endcaps are flashing colors -- some kind of bug.
   36 
   37 18) Write the @#$%^&*( documentation.
   38 
   39 -------------------------------------------------------------------
   40 
   41 FIXED:
   42 ------
   43 
   44 3) round join style not doing backfacing properly at this moment.
   45    FIXED 3 June 1993
   46 
   47 9) extrusions with more than 64 vertices in the contour may overflow the
   48    hardware ... our bgn...end constructs may have to check for such cases
   49    ... (for h/w with the 256 vertex limit only).
   50 
   51    A: Punt. Most hardware today doesn't have this limit anymore.
   52 
   53 12) Another significant optimization that can be performed is to convert
   54    many of the routines to work along z-axis only.  One reason this was
   55    not done right off the bat was for readability and maintainability.
   56    However, once the code becomes stable, this may be a good idea. 
   57    (What I mean here is that many routines, such as "intersect()" and
   58    "CUTTING_PLANE()" perform operations on x and y coordinates.  These are
   59    needed for a GENERAL "intersect()" routine; however, the way that they
   60    are used below does not require that generality (since all of the
   61    drawing occurs parallel to the z-axis).  With a little bit of careful
   62    thought, the x and y computations could be ripped out).
   63  
   64    A: But this will not work if there are twists in the contour, since 
   65       now, extrusions do NOT run parallel to z-axis, and the x,y
   66       coordinates are non-trivial.
   67    
   68 14) Q: convert extrude.c to work in a bgn/end style of collecting up data?
   69        (how to handle 2x3 affine matricies in the bgn/end style?)
   70     A: Don't do it.  It would make it hard to deal with the per-vertex
   71        affine matrices.  A much better idea is to implement a C++ object
   72        which has a begin-end interface for each poly extrusion object.
   73 
   74 15) convert to OpenGL
   75     Done. However, see note 10 above.
   76 
   77 16) add texture demos that demo the texutre hack.
   78 
   79 -------------------------------------------------------------------