home *** CD-ROM | disk | FTP | other *** search
/ Frostbyte's 1980s DOS Shareware Collection / floppyshareware.zip / floppyshareware / KAND / DXF2DKB.ZIP / DXF2DKB.DOC < prev    next >
Encoding:
Text File  |  1990-08-22  |  4.1 KB  |  80 lines
  1. DXF2DKB - AutoCAD DXF File to DKB 2.0+ Ray-Tracer .DAT File Translator
  2.  
  3. Version 1.0 Written by Aaron A. Collins
  4.  
  5. This program is designed to take in AutoCAD DXF (Drawing eXchange Format)
  6. files and convert them to DKB scene description data files.  This is the
  7. first release of this program so it has some limitations.
  8.  
  9. To be the most universal, it is compiled for 8086 opcodes with optional
  10. 8087 support if it is detected.  The speed difference is not significant,
  11. the biggest speed limiting factor will be disk access/transfer speed.
  12.  
  13. The biggest problem when doing something like this is that AutoCAD has some
  14. truly Non-3D constructs (such as CIRCLES and LINES) that are nearly impossible
  15. to represent in a 3-D renderer.  I have taken the "cheese log" approach to
  16. making 3-D constructs that approximately represent the 2-D shapes.  For
  17. instance, I use VERY skinny triangles (nearly degenerate) to make "LINES" and
  18. "3DLINES", very small spheres to represent "POINTS" and very short cylinders
  19. to make "CIRCLES".
  20.  
  21. The more proper 3-D constructs like "TRACE", "SOLID", and "3DFACE" are most
  22. easily represented as one or two TRIANGLES in DKB, so an object consisting
  23. of these should essentially be correct.
  24.  
  25. Unfortunately a fairly prevalent 3-D construct in ACAD is the "POLYLINE",
  26. which can get really complex and have B-Spline curves or Polygon Patch Meshes
  27. defined by the VERTEX points, so they aren't implemented yet.
  28.  
  29. I strongly suggest isolating only one "object" per DXF file you write out,
  30. (that may be made up of many primitives, however) mostly because a bounding
  31. box is automatically created to surround the entire object.  This speeds up
  32. the intersection decision making process of the Ray-Tracer considerably.
  33. Each object should have it's own bounding volume if more than one is included
  34. in a scene, or the bounding box becomes fairly useless.
  35.  
  36. I have attempted to filter out degenerate TRIANGLES before they can get to
  37. and choke the parser in the Ray-Tracer.  Degenerate TRIANGLES are ones which
  38. have two of the three points the same (i.e. a "LINE"!).  Since there is no
  39. way to Ray-Trace a "LINE" in 3-D space, these are sick entities which would
  40. make the Ray-Tracer enter the Olympic Cookie-Toss.  At least they used to,
  41. before we added code to detect them and exit after the parsing process if
  42. any are detected in the scene.  You should rarely have to remove them manually
  43. any more.  Note though, that the Tracer uses a different mathematical method
  44. to detect degenerates than I do here, so there is the remote possibility that
  45. one or two might slip by.
  46.  
  47. You will have to edit the output file of the program to add in a VIEW_POINT
  48. and a LIGHT_SOURCE or two, at the very minimum.  I eventually will add code
  49. to translate these too, but for now you're on your own.
  50.  
  51. If you use Design-CAD 3-D instead of AutoCAD, you must use their external
  52. DXF.EXE program to convert the file to DXF format before feeding it into
  53. this program.
  54.  
  55. Anyway, if anyone wants to take a crack at "filling in the blanks" and doing
  56. some of the other primitives, go ahead and send it back to me!  I'm including
  57. the AutoCAD publicly released DXF.DOC file describing the DXF file format in
  58. EXHAUSTIVE detail.
  59.  
  60.  
  61. Future Enhancements (The Eternal List of Things To Do):
  62.  
  63. 1.  Add in code to parse the current viewpoint from the current viewport
  64.     from the DXF file while whizzing past the HEADER and TABLES section
  65.     and write out a proper DKB "VIEW_POINT" construct.
  66.  
  67. 2.  Add code to handle POLYLINES, if really done properly, would handle
  68.     the flags that identify splines and patch meshes, etc. and perform the
  69.     surface tesselation required to make these patch areas between VERTEX'es
  70.     into TRIANGLE'd polygons.
  71.  
  72. 3.  Add code to make "DECLARE" statements out of defined BLOCK's, and then
  73.     instance the BLOCK wherever indicated by the subsequent BLOCK entities.
  74.  
  75. 4.  I doubt it will ever handle "TEXT", as this would require a stroke-type
  76.     of character generator routine, or something.
  77.  
  78. 5.  Make it pick out the AutoShade entities for "CAMERA" and "LAMP" and
  79.     use these for VIEW_POINT and LIGHT_SOURCE's over any viewpoint defined.
  80.