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