home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / sci / virtual / 2509 < prev    next >
Encoding:
Text File  |  1992-07-22  |  4.4 KB  |  119 lines
  1. Newsgroups: sci.virtual-worlds
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!destroyer!ubc-cs!uw-beaver!news.u.washington.edu!milton.u.washington.edu!hlab
  3. From: broehl@sunee.waterloo.edu (Bernie Roehl)
  4. Subject: Re: TECH: My standard is better than your standard.
  5. Message-ID: <BrqssG.JDG@watserv1.waterloo.edu>
  6. Originator: hlab@milton.u.washington.edu
  7. Sender: news@u.washington.edu (USENET News System)
  8. Organization: University of Waterloo
  9. References: <1992Jul19.055422.12836@u.washington.edu>
  10. Date: Tue, 21 Jul 1992 14:12:15 GMT
  11. Approved: cyberoid@milton.u.washington.edu
  12. Lines: 105
  13.  
  14.  
  15.  
  16. In article <1992Jul19.055422.12836@u.washington.edu> Jeremy Lee
  17. <s047@sand.sics.bu.oz.au> writes:
  18.  
  19. >I've got an answer to this. See my report. Objects themselves decide
  20. >which other objects to talk to. Objects naturally form a group that
  21. >talk almost exclusivley to each other, and that, to all intents and
  22. >purposes, is the same as a "world"
  23.  
  24. I really like the sound of this, if it can be implemented efficiently.
  25. How do you deal with the... wait, I should read your paper first before
  26. asking a lot of questions that you may already have answered.
  27.  
  28. >>If an object is to be invisible to certain other objects, it simply
  29. >>doesn't acknowledge messages from that object (including messages like
  30. >>"what do you look like" or "what is your location").
  31. >Heyyyy! We think alike. I came up with exactly the same thing last
  32. >night.. Each object is responsible for only itself.
  33.  
  34. Exactly.
  35.  
  36. >>However, I still have to worry about all the stuff in the office next
  37. >>to mine.
  38. >
  39. >Probably the best way to deal with this is to use a system where if an
  40. >object doesn't get seen for one frame, then the chance of even
  41. >attempting to render it for the next frame goes down.
  42.  
  43. A good idea, but what do I do when I first enter the world?  Do I have
  44. a long start-up period while I receive and render the entire environment?
  45. (Also, some graphics implementations will find it easy to keep track of
  46. which objects are actually visible; others will find this very expensive
  47. to do).
  48.  
  49. >I agree. It's easier to put the messages in a queue, with timestamp
  50. >attached. If the object want to pay attention to the timestamp, then
  51. >that is their business.
  52.  
  53. Right.  (Of course, sending a timestamp with every single message does
  54. add to the overhead and lowers the performance).
  55.  
  56. >The universe itself throws causuality out the window on occasions
  57. >anyway, so why worry about that?
  58.  
  59. Agreed.
  60.  
  61. >You can't rewind it. It's a non-deterministic system.
  62.  
  63. Agreed again.
  64.  
  65. >I personally like the idea of 128 bit numbers to describe spatial
  66. >co-ordinates.
  67.  
  68. I still maintain that 128 bits is overkill.  How often do you need to
  69. model the entire universe at the quantum level?  And having all that
  70. extra data to send around the network would degrade performance even
  71. further.  I think we should start with something smaller, but that from
  72. day one we should make provision for expansion.
  73.  
  74. >>>Extensiblity is a requirement for any protocol.
  75. >>
  76. >>Agreed!!!
  77. >
  78. >Of course.
  79.  
  80. I think this is one of the points we *all* agree on!
  81.  
  82. >Routing and all network stuff should be trasnparent and should have no
  83. >bearing on what constitutes a world. In that sentence, you are basically
  84. >saying that objects are restricted to worlds in close physical
  85. >proximity, and I therefore wouldn't be able to connect to a world that's
  86. >in Tokyo, for example.
  87.  
  88. Not sure what you mean by "a world that's in Tokyo"?  A virtual world doesn't
  89. really *have* a physical location.
  90.  
  91. As to why routers are important... even with very, very high-bandwidth
  92. networks I don't think we want every object in the multiverse having to
  93. broadcast to every other object.  We need some way of limiting traffic
  94. to those who are interested in it.  (Broadband vs baseband, sort of).
  95. Different "worlds" (and perhaps different regions within a world) are
  96. different "channels".
  97.  
  98. >Sounds like your routers are central controllers, and I thought we all
  99. >agreed that they just won't be able to cope.
  100.  
  101. Not central controllers; *distributed* controllers.  Even "controllers" is
  102. the wrong word.  They're routers; they help objects communicate efficiently.
  103.  
  104. >See my paper.
  105. >[...]
  106. >See my paper.
  107. >[...]
  108. >See my paper.
  109. >[...etc...]
  110.  
  111. All right, I get the idea.  You want me to see your paper, right?  :-)
  112. Looking forward to it.
  113.  
  114. -- 
  115.         Bernie Roehl, University of Waterloo Electrical Engineering Dept
  116.         Mail: broehl@sunee.waterloo.edu OR broehl@sunee.UWaterloo.ca
  117.         BangPath: uunet!watmath!sunee!broehl
  118.         Voice:  (519) 885-1211 x 2607 [work]
  119.