home *** CD-ROM | disk | FTP | other *** search
/ Virtual Reality Homebrewer's Handbook / vr.iso / rend386 / doc / plg.doc < prev    next >
Text File  |  1996-03-19  |  4KB  |  93 lines
  1.                           PLG File Format
  2.                     Version 4.1 -- August 1992
  3.                      Written by Bernie Roehl
  4.  
  5. As of version 4.0, the PLG format once again officially supports
  6. floating-point values for coordinates.  (As far as the code in REND386
  7. goes, PLG files have always been floating point; we had been trying to
  8. standardize on a long-integer representation, but have decided there's
  9. no real problem with floats).
  10.  
  11. Note -- REND386 still uses an integer format internally.  This means
  12. that if the floats in a PLG file are too small, you must scale them on
  13. loading (otherwise they'll all wind up being the same value).
  14.  
  15. A PLG file basically has three parts: a header line, a list of
  16. vertices and a list of polygons.
  17.  
  18. The header line has the object name, the number of vertices, and the number of
  19. polygons; for example:
  20.  
  21. kitchen_table 100 35
  22.  
  23. which would mean that the object "kitchen_table" has 100 vertices in 35
  24. polygons.
  25.  
  26. Anything after the polygon count should be ignored, since it may be used for
  27. future expansion.
  28.  
  29. Following this line are the vertices, one x,y,z triplet per line (each
  30. value is a floating-point value, and they're separated by spaces).  For
  31. example:
  32.  
  33. 18027.56 23025.27 98703.18
  34.  
  35. Note that only the first three values on the line should be used; anything
  36. following these values should be ignored.  This allows future support for
  37. such things as vertex normals.
  38.  
  39. This is followed by the polygon information, one line per poly; each of these
  40. lines is of the form "color n v1 v2 v3 ...".  The color is an integer
  41. specifying the color of this polygon, and v1, v2, v3 and so on are indexes
  42. into the array of vertices, origin zero.  The 'n' is the number of vertices
  43. in the poly.  The vertices are listed in a countclockwise order as seen from
  44. outside the object.  Note that the vertices are counted "origin zero", i.e.
  45. the first vertex is vertex number 0, not vertex number 1.
  46.  
  47. For example:
  48.  
  49. 2 4 8 27 5 12
  50.  
  51. would mean a four-sided polygon bounded by vertices 8,27,5 and 12.  This
  52. polygon has color number 2.
  53.  
  54. The color can either be a decimal integer or a 0x or 0X followed by a
  55. hexadecimal integer value.  For details on colors, see the separate colors.doc
  56. file.
  57.  
  58. Note that anything after the list of vertex indices should be ignored;
  59. this is to allow future support of additional features.
  60.  
  61. That's it.  Much simpler than OFF format, and yet easy to convert to (or from)
  62. OFF if need be.  Also has the advantage that you can store multiple objects
  63. in the same file; you could even store a complete scene description in a
  64. single file, as opposed to as many as three or four OFF files for each object.
  65. This makes it faster to load.
  66.  
  67. The PLG format supports comments.  Anything after a # should be ignored by any
  68. program that parses PLG files.  In addition, lines beginning with a '*' should
  69. be ignored (they will eventually be used for adding extra information to
  70. a .PLG file).
  71.  
  72. I still recommend and endorse the use of OFF files for sharing of objects,
  73. since they have lots of additional information (author, creation date,
  74. copyright info, etc).
  75.  
  76. As of version 4.00, PLG files can now have multiple copies of an object at
  77. different resolutions.  PLG files containing such multiple-resolution versions
  78. of objects must have "#MULTI" as their first line.
  79.  
  80. For each object defined in such a file, the object name includes a number
  81. specifying the pixel size of the object on the screen.  The object names
  82. for each representation must be <name>_####
  83. where #### is the smallest pixel width to use this representation for.
  84. For example, TABLE_15 would be a valid name.
  85.  
  86. If the smallest rep size is zero, then that represenation will be used
  87. no matter how small the object gets.  If the smallest rep size is 2 or
  88. greater, the object will vanish if it gets too small.
  89.  
  90. Within REND386, these files are loaded by a special function, and are stored
  91. internally as a list of representations.  When a scene is rendered, the
  92. correct representation is autmatically selected based on screen size.
  93.