From: vanderwerkend@LONEX.RL.AF.MIL (Dan Vanderwerken)
Subject: Re: TECH: My standard is better than your standard!
Date: Fri, 26 Jun 92 12:59:10 GMT
Organization: RL


In article <1992Jun22.222306.25422@u.washington.edu> s047@sand.sics.bu.oz.au (Jeremy Lee) writes:
>Decided to throw my ha'pneys worth in.
>
>[much good info deleted]
>
>Imagine this. Another patch intersects with  one of the patches of the
>current object. This fact  is  detected by  the environment,  and both
>objects are notified of all the relevant details. What happens next is
>up to  the individual objects.  They may decide   to "converse"  for a
>little and decide upon a  course of action.  (message passing  between
>objects  is allowed.  Described  later.)   The most likely  thing,  of
>course, it that they will decide  to 'move'. The environment will have
>already notified  the two objects of  their relative  vectors, surface
>normals,  and intersection point.  A normal  object will  do  a little
>straight computation, and decide that it now wants to be  moving  in a
>new vector with a different spin. It may decide  to change it's shape.
>It may decide to change it's colour.  It  may decide to emit  a noise.
>This is all up to  the object. It  may  choose  to ignore the  message
>entirey, and will   continue to  sit  rock-steady as  the other object
>'bounces' off it.  (Decidedly non-newtonian.) You may cry  "What about
>consistency!". Well,  you will  just have to  metaphorically grab that
>particular object by the scruff of it's metaphysical  neck and tell it
>to do that  in future.  Obviously   this  is a very powerfull  way  to
>describe objects.

I like this concept!
How about a multi-processing environment where each object gets its own
processor and follows it's own rules.  Most of the rules will be global
or universal such as the basic laws of physics.  For example, you're driving
some type of war machine in a VR game and you run into a building.  You sent
the building you mass and velocity.  It calculates your momentum and, based
on its knowledge of itself, decides whether to topple, cave in, or simply
stand solid and allow you to bounce off.  Your war machine does the same
thing.

Other rules will be local and apply only to the specific object.  Graphic 
objects could even be broken down into sub-objects and the sub-objects could 
each have their own processors.  Your VR game war machine would be a composite
of many graphical objects, each with their own processors, "talking" to each
other.  The machine would have a radar unit/display that follows it's own
set of rules but is part of the overall war machine.
>
>Back to message passing.  Imagine our hypothetical  collision. The two
>objects  may  want  to  pass a  message.  Passing a message  basically
>involves sending  some encapsulated machine-readable  message, and not
>hoping for  a reply. Once  again, it it up to  the recieving object to
>accept or ignore the incoming message and decide upon what to  do with
>it. Obviously, you may want to lay down some sort of initial 'Rules of
>Object Etiquette' that it  would be considered  rude to violate. Rules
>such as inertia. When two objects collide, they  tell each other about
>their   current mass, which will  help  to compute what happens  next.
>Objects may request information  about the other  object, but  needn't
>expect a reply.
>
>[more good stuff deleted] 
>
>Now, what language are we going to write this in? Don't  know. We are,
>however, going to have to make a new one. It's  not going to  be C, or
>C++, or pascal, or Lisp, or bloody COBOL. None of  these are adequate,
>and I'm  not  going  to  argue on  this point! A  VR  environment will
>require a human/machine readable language that  is self-modifying, and
>_very_high_level_. Look at Hypertalk for a  good  idea,  but it's also
>going  to  incorporate  a  lot  of other   ideas,   such as a database
>managament  system. It's also going  to be  interpreted, because don't
>forget that you have no idea on what machine  (or machines) it's going
>to be running on, and it will be constantly changing  itself, maybe. I
>know that interpreted languages are slower  (they can  still be pretty
>quick, if they  are sufficiently advanced.) but  computing  power will
>keep increacing, and I  think that  we  realise  that  VR is  going to
>eventually be implemented on BIG  computers.  Note that these  scripts
>will  be executed  by  whatever  machine is running  that  environment
>system, so you can have a lovely  big cray acting as  a dial-up server
>with  your little workstation taking  care of the graphics. The server
>need only notify you of what  happens to the  relative position of the
>object, and how the geometry of it's patches have changed.

I agree.  We need a new language (see my other post).  I doubt anyone is
going to create a language and then have the entire VR community embrace
it with open arms.  I think this new language will probably be a descendent
of one of the more popular languages of today (C, C++, etc--perhaps even
the Hypertalk you mention).  The advent of a truly great VR language will
probably be something that "just happens"--sort of like how UNIX "just  
happened".  I could be wrong.  If someone designs and builds a truly powerful
and useful VR environment--meaning all good VR must be done in this environment
because it's the only one available--then this would become the defacto 
standard.

Until then, expect a hundred different implementations of the same functionality
under different library names for C, C++, etc.  I agree with others, libraries
will probably provide the means of doing VR for quite some time.
>
>The renderer  gets  told  to begin  with  (when you  connect   to  the
>database) everything that you need to know (and  your system tells the
>server how much you  need to know.) about the  patches.  This includes
>downloading  the  texture maps, and  the code that renders the marble.
>You can even go as far as including  the code to  render it right onto
>the screen. In future systems, I can see the system asking each object
>if it actually appears  at each screen co-ordinate. Imagine  this, the
>system distributes a message saying "OK, guys,  I'm now computing this
>pixel, and I want y'all to tell me if you appear at it,  and if so, at
>what distance from the  observer, and if so, what  pixel value to use,
>and what transparency."   Each object then  reports back  RGB triplets
>and a trasparency value. Yes, I know, this takes a lot of  power. Yes,
>I know, we are not currently using crays. But one day we will.

>From what I understand, computer manufacturers have 64-bit, 1000 MIPS CPUs
in the laboratory _right now_ (of course, I'm taking the computer maker at
his word--this can be dangerous).  Is it unreasonable to think we'll be using
laptops with 64-bit, 1000 MIPS power 10 years from now?  I imagine the true
supercomputers of the near future running in the GIPS and TIPS.  Combine
this power with parellel processing and I think we'll be able to have 
reasonable VR.
>
>[more good stuff deleted]
>Where does the observer fit into  all  of this? They  are just another
>object, handled by  the local machine.  In this case,  there is also a
>link  between  the physical pheriperals of  the  machine and the 'body
>objects' defined in   the computer. With this model,   when you wiggle
>your little finger, what happens is that  the message gets sent, as an
>event, to the   'hand  object'  inside  the  environment. If  you have
>defined the event  handler correctly, then   the little finger  should
>wiggle.
>
>This  then  reduces the entire system   to  three  components. The  IO
>system, the renderer, and the object handlers.
>
>Nothing  of  what  I  have   described  here  is new.  It's  a logical
>alternative.  It's current disadvantage is,  however,  that it will be
>slow on  most current systems,  and very difficult  to run  on low end
>machines.  However, its expandable   and  flexible. These are the  two
>traits that  are needed in a  world  where computing power  is growing
>yearly. In ten years, we will each be able to buy the equivelant of an
>IRIS  workstation for our kids to  play around with.  That  is when VR
>will take off, and we need a system for the future, not for today. The
>harware isn't powerfull enough  yet, guys, but  we can still  define a
>good standard that will be usefull when it does arrive.
>
>***********************************************************************
>*    . Jeremy Lee s047@sand.sics.bu.oz.au    Student of Everything    *
>*   /|            "Where the naked spotless intelect is without       *
>*  /_|              center or circumference. Look to the light,       *
>* /  |rchimedes      Leland, look to the light" - Dale Cooper         *
>***********************************************************************

I think the most profitable discussions we can have for VR are discussions
of this type.

---Dan---

-- 
Dan Van Der Werken          | 
Rome Laboratory/IRDO        | 
Griffiss AFB, NY 13440-5700 | 
(315) 330-3127              |