home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / sci / virtual / 2597 < prev    next >
Encoding:
Internet Message Format  |  1992-07-28  |  4.1 KB
  1. Path: sparky!uunet!zephyr.ens.tek.com!uw-beaver!news.u.washington.edu!milton.u.washington.edu!hlab
  2. From: keithley@apple.com (Craig Keithley)
  3. Newsgroups: sci.virtual-worlds
  4. Subject: Re: TECH: world description
  5. Message-ID: <1992Jul29.073343.28356@u.washington.edu>
  6. Date: 28 Jul 92 19:34:08 GMT
  7. References: <1992Jul16.001255.10153@u.washington.edu> <1992Jul17.185842.
  8. Sender: news@u.washington.edu (USENET News System)
  9. Organization: Apple Computer, Inc.
  10. Lines: 79
  11. Approved: cyberoid@milton.u.washington.edu
  12. Originator: hlab@milton.u.washington.edu
  13.  
  14.  
  15.  
  16. In article <1992Jul17.185842.2330@u.washington.edu>, lonachon@anu.edu.au
  17. (andrew longhorn ) wrote:
  18.  
  19. > There would probably be a few levels of control procedures, maybe
  20. > gravity and solidity reactions can be overridden also.
  21. >  ...
  22. > But you think this is
  23. > silly and link your controls (output of the spirit) to the inherited
  24. > rotation, movement controls of the subtrees of the table (i.e. the
  25. > legs), then stand up and walk (or fly) off somewhere, to the amazement
  26. > of onlookers.
  27. > 
  28.  
  29. This highlights the question of "What defines the laws of your local
  30. _reality_?"  In the _reality_ I define (on my VR server?), I may wish
  31. to prohibit the overriding of the laws of physics.  This would
  32. disallow the use of "Magic", for example, preventing someone from
  33. making a table walk or fly.
  34.  
  35. So how do we define the "rule systems" of each locality?  Such "rules"
  36. could encompass things such as time constants, gravity, friction, etc.
  37. I've not fully worked out how rules are defined, but as for handling
  38. rules, I do have a few thoughts.  I think that:
  39.   
  40.   No limit to the number of rules.
  41.  
  42.   Rules might be overriden individually or en masse.
  43.  
  44.   Ability to reject a request to override a rule.
  45.   (and so forth...)
  46.  
  47. Unfortunately this opens up much more difficult issues.  Because it
  48. may be simpler to model objects on a behavioural level rather than on
  49. the physical level.  If modeled on the behavioural level, then the
  50. object's 'behaviour' might be defined rather simply.  Using the table
  51. as an example, the object's extremities might not have any "controls"
  52. (subroutines) that allow movement of the legs.  Making the table walk
  53. would require control extensions to the object.  Work arounds would
  54. need to be used to handle object destruction (or damage). Modeling at
  55. the physical level would require a greater simulation of object
  56. components (ie: Legs, table top, etc.).  If you want a general
  57. solution to the requirement of prohibiting the overriding of rules,
  58. then you probably need to simulate the interaction between components
  59. in the object.  For example, without overriding the 'no magic'
  60. rule(s), the attempt to move a leg would result in a broken table leg
  61. (caused by trying to move a joint that's solidly glued in place).  If
  62. you could override rules, then the table leg could flex and the table
  63. would walk.  This is an example, so please don't thrash on the
  64. specifics of how a table leg could move by dissolving the glue, adding
  65. a hinge, changing the table's substance, changing the table's design,
  66. etc.  Assume that the object's construction is immutable.
  67.  
  68. So I'm still wrestling with the issue/choice of defining object
  69. behaviour by scripting or by a complex rule system + object component
  70. interaction.  I can best explain the quandry by asking: Would you
  71. rather define a clock by writing a 'behaviour' script that describes
  72. the motion of the hands of the clock, or by defining the
  73. innards/components of the clock.  Writing a script may require
  74. foreknowledge of all the possible rule changes (time constants,
  75. friction, gravity).  Having complete foreknowledge might be
  76. impossible.  On the other hand, using a rule system & object component
  77. interaction may make objects difficult to 'design' and the simulation
  78. crawl (imagine a clock store!).
  79.  
  80. I suppose the best solution might be to allow for both methods of
  81. defining objects and their behaviours.  Or even a combination of the
  82. two methods.  I further suppose I'd just prohibit the overriding of an
  83. object's behaviour scripts.  Well, maybe sometimes.  Always?  Hmmm...
  84. Wish that table would stop flying about...
  85.  
  86. Thoughts anyone?
  87.  
  88.  
  89. Craig Keithley
  90. Apple Computer, Inc.
  91. keithley@apple.com
  92. Anything not forbidden is mandatory.
  93.