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