From: snowdond@cs.man.ac.uk (Dave Snowdon)
Subject: Re: TECH: My standard is better than your standard!
Date: 24 Jun 92 13:25:04 GMT
Organization: Department of Computer Science, University of Manchester


In article <1992Jun22.222306.25422@u.washington.edu>, s047@sand.sics.bu.oz.au (Jeremy Lee) writes:
  [stuff deleted]
> I, like everybody else, have a personal dream about how to do VR. I'll
> explain it here, and leave it open  to discussion. I am thinking about
> this *very* seriously, becuase we are trying to get the stuff together
> here at Bond Uni to  set up a proper VR  Lab. (By proper, we mean more
> than datagloves   and  amiga's.  For instance,  a   couple of Indigo's
> would't go  astray, nor would  a mainframe or  two, if anyone  has CPU
> time they would like to donate to some real research.)

We (the Advanced Interfaces Group at Manchester University, UK) are in a
similar position. We have some kit, but if anyone does have some spare
supercomputers or money I'm sure we could puy it to good use :-)
 
The approach you describe is quite similar to our model for VR. If anyone
is interested, we described our proposed model in the paper "AVIARY -  A
Generic Virtual Reality Interface for Real Applications" by A.J. West,
T.L.J. Howard, R.J. Hubbold, A.D. Murta, D.N. Snowdon & D.A. Butler, which
was presented at the BCS "Virtual Reality Systems" conference in the UK, in
May. Some of the implementation details mentioned in the paper are a few
months out of date now.

I hope to have a prototype system up and running in a few months time. I
would definately agree that an OO style model with provision for a parallel
architecture is the way to go.

 [stuff about graphics deleted]
> You have objects defined in terms of groups of patches. Each object is
> also an active thing, and basically contains code that defines how the
> object acts when things happen to it.  Not that this  is _close_ to an
> OO model,   but not quite.   Things that happen include  messages from
> other objects, and interactions with  it's patches. The distinction is
> subtle.  What I am proposing is that the  environment does  not 'move'
> an object when it  interacts with another,  but that it notifies it of
> the fact  and the object  moves itself.  Or  not, depending on  how it
> feels.

  [description of behaviour of colliding objects deleted] 

  Our model also has a similar notion of objects. To help with the
consistancy of behavour problem, we have a notion of 'worlds'. A world is a
set of attributes, with 'laws' (described by program code) which descibe how
the allowable ways objects in the world can behave. For example a world might
have notions of mass, gravity and inertia. The 'laws' would be encoded in
basic methods for object movement etc in that world which would be inherited
(and potentially refined to allow for pecularities of a particular object
class) by classes describing the objects in that world. Worlds need not be
defined from scratch, they could inherit from existing worlds.

Obviously some applications will require different behaviour, for example an application for visualizing abstract data may not require gravity or any other
physical properties. In our model there would be a world with laws tailored
for this sort of application, and a user could move between active worlds
at will.

This approach means that the behaviour of objects is not constrained by the
system and very little needs to be built in to the system.

  [stuff aboutr event handlers 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.

  Agreed. I've been thinking about how I'd like to describe objects in our
system and have a rough idea of the lanuage I'd like to implement. We will
probably go for an incrementally compiled language for speed though. 

  For the prototype, I'm using bits of C (with some custom libraries to
support notions of objects and distributed communication etc) to describe
the 'methods' (or event handlers) supported by objects. This is purely
because I don't have time to implement a compiler for the language yet, I'll
do this when I have the prototype up and running (so I know that the basic
ideas actually work :-) this should only involve modifying the object
handlers.

  [stuff deleted] 
> We also need to  take a look  at  distributed processing. If you hae a
> number of machines on the network, then I don't see any reason why the
> master databse manager shouldn't ask a lightly loaded machine to "take
> care" of one or more of the objects. Obviously the client will have to
> instantly  report back any changes  to the object,  in case the client
> goes down or the connection breaks, but the client  no longer needs to
> request information about   that  particular object   (since  it's all
> local) which  saves  a little bandwidth  to   help compensate for  the
> increace  that having to  handle  that  object will  take.  If you are
> running a user-pays system, then some users may actually be paid money
> for the contribution that their system makes!
> 
> Handling an object will basically involve managing that objects events
> by running it's   scripts when the master database   manager gives  it
> events. If you can de-centralise this system, then you have opened the
> door to truly massive parallel processing. This may  mean not having a
> central manager,  and if  a  node  goes  down,  then  the  object just
> dissapears. This isn't nice, and you want a backup somewhere.

  The prototype of our system will be on a network of transputers connected
(via a host) to a network of workstations. While none of these machines has
*real* power it gives us a *very* parallel distributed system, with processes
running on arbitrary processors connected to the network.
 
> 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.

Again we have a similar notion of a user.
 
> 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.

I'm hoping that we've taken a sufficiently pragmatic approach to our 
implementation that our prototype will run at a reasonable rate. I've
sacrificed some generality for speed but as systems get faster things
should improve.
> ***********************************************************************
> *    . 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         *
> ***********************************************************************

-- 
Dave Snowdon
Department of Computer Science   Tel:    (UK) 061 275 5717
Manchester University            E-mail: snowdond@cs.man.ac.uk
M13 9PL U.K.                          or snowdond@uk.ac.man.cs

  The Devil may care... But I don't mind (T.S.o.M.)