home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / sci / virtual / 2576 < prev    next >
Encoding:
Internet Message Format  |  1992-07-28  |  4.9 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!mips!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!usenet.coe.montana.edu!news.u.washington.edu!milton.u.washington.edu!hlab
  2. From: dstamp@watserv1.uwaterloo.ca (Dave Stampe-Psy+Eng)
  3. Newsgroups: sci.virtual-worlds
  4. Subject: SCI: Toward a REALIZABLE network VR standard...
  5. Message-ID: <Bs17qD.14q@watserv1.uwaterloo.ca>
  6. Date: 27 Jul 92 05:10:59 GMT
  7. Sender: news@u.washington.edu (USENET News System)
  8. Organization: University of Waterloo
  9. Lines: 77
  10. Approved: cyberoid@milton.u.washington.edu
  11. Originator: hlab@milton.u.washington.edu
  12.  
  13.  
  14. OK...  I think it's time that some limits be noted in terms of what a
  15. do-it-now VR protocol for general use must use.  If you have more
  16. resources, fine, but that doesn't mean that the standard will be
  17. designed to need that much to work-- but it will have options to use
  18. it.
  19.  
  20. Network bandwidth: Must work acceptably with data rates as low as 1000
  21. baud (100 bytes/sec) to the stations, although servers can have a lot
  22. more.  By "stations" I mean a computer that does not manage an object
  23. or area in the world.  These will probably have to be limited to
  24. larger machines, unless you have an Ethernet connection.  Just traffic
  25. volume, nothing to do with machine power.
  26.  
  27. Object resolution: Let's get real.  Most objects can be expressed in
  28. local (object-frame) coordinates of 16 bits or less.  The object can
  29. have area (or world) coordinates of 32 bits, and pose can be sent with
  30. 16-bit (or less) angles.  Again, it's a message size issue.  We can
  31. have multiple versions of each object, or perhaps a CSG representation
  32. (it will depend on how "pretty" the expanded CSG looks on remote
  33. machines: the option of having a hand-tuned poly rep is essential).
  34. And as for object complexity, try to keep it well under 100 polys
  35. (average of 20 is nice).  But a simple system NOW and extensibility
  36. will get the thing going.  Add a request facility for CSG or texture
  37. mapped or other stuff.
  38.  
  39. Areas: Definitely split up the world.  Not just to keep the resources
  40. required to manage the world under control, but to control visibility
  41. and object detail (representation) as well.  Use planes to define
  42. areas, and NEVER assume axis-alignment.  Try to cache a bit of the
  43. local world "structure" at the local server to prevent a long pause as
  44. "where am I NOW" messages are exchanged.  It's possible to use a
  45. static form of BSP trees for this purpose, and to generate small
  46. subsets for checking local motion.  Visibility can be handled by
  47. region and by distance (i.e. server maintains object visibility lists
  48. between areas, including simplified object lists for distant regions).
  49. GOAL: less than 100 objects needed to start the world up.
  50.  
  51. Motion: Forget any system that sends updates more than one a second.
  52. Use a predictive stratagy, i.e. encode the local motion's goal, speed,
  53. direction, and acceleration curve.  Object "owners" (whoever can move
  54. an object at this instant) handle collision detection with that
  55. object-- which includes your body.  Autonomous moving objects should
  56. be handled by either the area server or their object server.  WE HAVE
  57. TO KEEP LOCAL REALTIME.  Interruptions to switch areas and to get
  58. ownership of objects are barely permissable (but needed).  ALWAYS
  59. assume there may be a 1 or 2 second delay in transmission, and that
  60. the medium may be bursty (and the bursts may split your packet).  It's
  61. a tough net, folks.
  62.  
  63. Support: Users will be interfacing with keyboards, joysticks, mice,
  64. gloves, Sega glasses, HMDs, ...  so ALL must be supported.  How?  Not
  65. really the net's business!  All we can do is provide the visual raw
  66. material and let the local implementation decide how to create the
  67. move commands or how to navigate.  Although with keyboards some
  68. attatched text commands for an object would be nice, such as scripts
  69. to be executed (open door, etc).
  70.  
  71. Human Factors (or how to cheat): In the end, the system will be used
  72. by people.  It will probably NOT be used to run submolecular
  73. simulations or other tasks that require enormous complexity or even
  74. accuracy.  So local area scales will work fine (and are essential for
  75. natural interfacing and the development of perceptual maps of the
  76. system).  Stuff like limits on resolution or quantized motion or force
  77. thresholds to make control simpler etc. fits into this catagory.
  78.  
  79. In summary, it's a real world out there.  If you match the ideas to
  80. the limits, you can spend your time solving problems and finding
  81. extensible solutions.  Otherwise, you're just part of the Dream-Team
  82. trying to simulate the universe on a C-64.
  83.  
  84. --------------------------------------------------------------------------
  85. | My life is Hardware,                    |                              | 
  86. | my destiny is Software,                 |         Dave Stampe          |
  87. | my CPU is Wetware...                    |                              | 
  88. | Anybody got a SDB I can borrow?         | dstamp@watserv1.uwaterloo.ca |
  89. __________________________________________________________________________
  90.