home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / sci / virtual / 2879 < prev    next >
Encoding:
Internet Message Format  |  1992-08-21  |  2.9 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!usenet.coe.montana.edu!news.u.washington.edu!milton.u.washington.edu!hlab
  2. From: georgef@endeavor18.wv.tek.com (George Forman = GHF)
  3. Newsgroups: sci.virtual-worlds
  4. Subject: TECH: OIFF an object interchange file format
  5. Message-ID: <1992Aug21.232127.29246@u.washington.edu>
  6. Date: 21 Aug 92 22:18:02 GMT
  7. Sender: news@u.washington.edu (USENET News System)
  8. Organization: University of Washington
  9. Lines: 52
  10. Approved: cyberoid@milton.u.washington.edu
  11. Originator: hlab@milton.u.washington.edu
  12.  
  13.  
  14.  
  15. I have a few suggestions for OIFF:
  16.  
  17. 1. You might include a version # in the header.  This will probably
  18. save grief later.
  19.  
  20. 2. In the 2-D world, people have found it very useful to include a
  21. bounding box in the Postscript files.  This saves scanning the whole
  22. thing to find out if it's in the field of vision or whatever.  Also
  23. aids scaling-- suppose I want to put Jim's world in a shoebox on my
  24. shelf.
  25.  
  26. 3. Perhaps some notion of subroutines could be incorporated to reduce
  27. data size.  A 1 page description in a slightly higher level graphics
  28. language can produce a scene filled with 1000s of polygons.  The OIFF
  29. files will blow up geometrically-- each of the 40 houses each have 15
  30. boxes which each have 6 sides.  A very low-level OIFF will have to
  31. represent an awful lot of data, but a slightly higher-level OIFF can
  32. be much smaller.  I suggest such simple languages as found in computer
  33. graphics course textbooks.
  34.  
  35. 4. The file could specify the 6 light reflecting characteristics of a
  36. flat surface (RGB reflected & RGB diffuse) & let the *user's* display
  37. program decide whether to just quickly use a flat color model (just
  38. using the first 3 numbers), or to produce a beautifully lighted model
  39. using all 6.  To save space, suggest that the OIFF define a color map
  40. which the polygons then use by reference.  In the future, this color
  41. map could become sophisticated w/ texture & tiling information.  You
  42. certainly wouldn't want each polygon to have to specify all this
  43. information explicitly each time-- takes a lot of polygons of the same
  44. color to make a blue tree.  These are probably frills for the second
  45. version.
  46.  
  47. 5. Suggest making the file more readable & printable.  Right now it
  48. seems extremely vertical-- could waste a lot of printer paper.
  49. Wouldn't hurt to use a tab character between components of a vertex &
  50. newline after each vertex, or commas and tabs.
  51.  
  52. 6. I'm not so certain that things should be broken up according to the
  53. 5 senses: SOUN,VISI,HAPT,OLFA,TAST.  Yes, it's stable over centuries,
  54. but I'd think it'd be better to break things up according to the
  55. virtual devices on which they are to be displayed.  The 3-D world
  56. device (probably HUD, but perhaps not.), a much higher quality 2-D
  57. device (for text, explanations, detailed menus, high-resolution
  58. pictures etc. which won't work well on HUD), general room lighting
  59. device (RGB diffuse light? Strobe?), pack vibrator, floor vibrator,
  60. room heater...?
  61.  
  62. Good luck,
  63.  
  64.   GHF
  65.