home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / sci / virtual / 2571 < prev    next >
Encoding:
Text File  |  1992-07-26  |  5.0 KB  |  114 lines
  1. Newsgroups: sci.virtual-worlds
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!wupost!gumby!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: <Bs08MI.51v@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> <1992Jul26.075108.9516@u.w
  10. Date: Sun, 26 Jul 1992 16:32:41 GMT
  11. Approved: cyberoid@milton.u.washington.edu
  12. Lines: 100
  13.  
  14.  
  15. In article <1992Jul26.075108.9516@u.washington.edu> dlwood@mailbox.syr.edu (Davi
  16. d L Wood) writes:
  17.  
  18. >If the universe is defined by a message router [...]
  19.  
  20. That's the point of contention, really... but more on this later...
  21.  
  22. >that the message router should only inform you
  23. >(the client) of the existence of an object only if it occupies one or more
  24. >pixels after being projected with perspective shrinkage.
  25.  
  26. Right.  Of course, this depends on what your display's resolution is; do we
  27. want the router to have to deal with things like that?  If it does, it isn't
  28. just a router... it's something else entirely.
  29.  
  30. The other problem is that this still doesn't reduce the amount of data enough.
  31. If I look out my window right now, I can see the house across the street.
  32. Including the house in my rendering database is no problem; however, including
  33. all its contents (down to the forks and knives in the kitchen drawers) would
  34. be.  Yet if it weren't for intervening walls, I could certain see a fork
  35. at that distance.
  36.  
  37. With just size/distance clipping, most of the objects in the house wouldn't
  38. get clipped, even though I can't see them; more memory and more workload for
  39. my poor renderer to have to deal with.
  40.  
  41. > store in the machine's memory only the geometry and attributes (and 
  42. > ...behavior?) of those objects that contribute to a pixel or more after
  43. > perspective projection.  
  44.  
  45. Not clear if by "the machine's memory" you mean memory in the router or in
  46. the rendering station.  The latter I would agree with, the former I wouldn't.
  47. In any case, I suspect that isn't enough.
  48.  
  49. >I don't know about you, but objects flickering in and out in my peripheral
  50. >vision would be a bit distracting! :)  But, clipping is best handled by the
  51. >renderer, not the message router.
  52.  
  53. It's all related, though...
  54. If someone moves around in the hypothetical house across the street, do I need
  55. to know about it?  Based on size/distance, yes... based on obstruction by
  56. walls, no.  And even if I can see it, I can't necessarily interact with it
  57. (we need to reduce the number of object-object collision tests that must be
  58. done, since otherwise it's an N-squared problem and *very* expensive).
  59.  
  60. >I really like the idea of a message router controlling the passing
  61. >of messages between objects in a world.
  62.  
  63. Which raises all the problems of centralization.  A new object enters the world,
  64. the router has to do size/distance testing between it and each of the 10,000
  65. objects already there.
  66.  
  67. >the clients should never be trusted to
  68. >perform any task that you can do yourself (where "you" is the server).
  69.  
  70. That's a fundamental philosophical difference between us.  The server should
  71. never do anything that can be handled by the clients, since there is far more
  72. computing power in the clients (of which there are many) that there is in the
  73. server (of which there is but one).  The router should do as little as possible,
  74. and if we can figure out a way to eliminate it altogether, so much the better;
  75. otherwise, sooner or later, it will become the bottleneck.
  76.  
  77. >128 bits is not enough.
  78.  
  79. Not enough for *what*?  Quantum-level descriptions of the *entire universe* can
  80. be handled in 128 bits.  It's not like internet addresses or color palettes or
  81. DOS memory; we're talking the basic physical dimensions of the universe, here.
  82.  
  83. >You could use a system of variable length coordinates.  An id byte would
  84. >indicate how many bits (or bytes, take your choice) are used to locate a
  85. >coordinate.  Really, anything to extend the ability of the protocol
  86. >is better than putting a limit like 16 bytes.
  87.  
  88. I agree with this wholeheartedly.
  89.  
  90. >I'll admit 16 bytes is
  91. >fairly hefty, but if you want to dump an entire universe into a file [...]
  92.  
  93. Wow, between your high-capacity disk drives and Jeremy Lee's processor, you'd
  94. have one heck of a VR station!
  95.  
  96. >Honestly, how much CPU time is burned up by sorting out messages and
  97. >occassionally computing a size over distance function? Not much.
  98.  
  99. For 10,000 objects at 30 frames/sec?  Using Cray XXII's as routers may
  100. be a swell idea, but here in Canada our research budgets are kind of limited
  101. right at the moment...
  102.  
  103. >You NEED a central control by definition of DOMAIN.
  104.  
  105. A fundamental centralization vs decentralization debate.
  106.  
  107. I think we're zooming in on the most important issues here... let's keep at it.
  108.  
  109. -- 
  110.         Bernie Roehl, University of Waterloo Electrical Engineering Dept
  111.         Mail: broehl@sunee.waterloo.edu OR broehl@sunee.UWaterloo.ca
  112.         BangPath: uunet!watmath!sunee!broehl
  113.         Voice:  (519) 885-1211 x 2607 [work]
  114.