Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!dali.cs.montana.edu!milton!broehl@watserv1.waterloo.edu
From: broehl@watserv1.waterloo.edu (Bernie Roehl)
Newsgroups: sci.virtual-worlds
Subject: Re: Yo! people!
Message-ID: <1990Aug29.153952.19163@watserv1.waterloo.edu>
Date: 29 Aug 90 15:39:52 GMT
References: <31304@unix.cis.pitt.edu>
Sender: hlab@milton.u.washington.edu
Organization: University of Waterloo
Lines: 85
Approved: hitl@hardy.u.washington.edu


Part of the problem is that VR is a very abstract kind of idea right now,
and different people have different views of what it should be.  Asking for
usable source code at this stage may be premature.

Having said that...

On a 386 with a VGA card and a decent color monitor you can do stereoscopic
3-D imaging using the old 3-D glasses approach (one lens red, one green or
blue).  You simply draw each object twice (as a wireframe), once in from
the left-hand perspective in red and once from the right-hand perspective
in blue.  As the objects move, you redraw the scene.

With this setup and the serial-port-based DataGlove mentioned a few articles
back, you can create a simple virtual reality in which you can see and
manipulate objects in three dimensions.

The same approach should be usable on any system with a color display and
a serial port (newer Macs, Suns, etc).

If you have a second serial port, you and a friend with a similar setup
can share a virtual reality via modem.  You basically send each other
the dataglove coordinates, so that there's a "hand" for each of you at
each end of the connection.  This could be also done over the Internet.

Once ISDN becomes widespread, you can even communicate via voice at the
same time that you're manipulating a shared virtual reality.

Over time, better imaging hardware becomes available (e.g. LCD based
glasses to allow the images to be in color).  Eventually something like
the "Private Eye" mentioned earlier in this newsgroup, augmented with
head-position sensors, would allow you to "look around" and see solid
3-D objects in full color.  The computation load for something like this
would be *very* substantial, however, and would almost certainly need a
dedicated board with processing, memory etc.

One issue that I'd like to hear discussed is that of protocols.  Even for
the simple system described above, it would be nice to have a standard
way of passing information back and forth.

On a larger scale, I could see a multi-user VR being hosted on central
machines.  How about something like this for an overall configuration:

	A particular type of VR would consist of a number of "buildings"
	(corresponding to network hosts) each containing a number of
	"rooms" (processes running on a host).  Each room would contain
	a number of "occupants" which might correspond to users or to
	processes that manage that occupant.  The "occupants" might
	be animate (people, pets, etc) or inanimate (tables, chairs,
	walls etc).

	A user sitting at home might only be occupying a room in his
	own building.  Via a point-to-point connection (via modem or
	ISDN, for example) he could invite a single guest over, or go
	visit someone in a room in another building.

	An organization might have a host capable of supporting a large
	number of connections, and which could therefore be occupied by
	a large number of people simultaneously.  A company might have
	a virtual "office building", a school might have a virtual building
	with a number of "classrooms", etc.

	Each "building" should probably have a "lobby" with a list of
	available rooms, and a security guard to limit access.

	In software terms, each "room" would be responsible for taking
	the information from each occupant and relaying it to all the
	other occupants (or in some cases, to a specific occupant).

	Each user would maintain a visual representation of the contents
	of the room that would change as information is received from the
	room.

	The "information" referred to above could be anything, and should
	be extensible; examples would be audio information, information
	about the location/orientation of objects, changes in an object's
	appearance, etc.

So, anyone for designing a protocol?  The key is, of course, extensibility.

-- 
	Bernie Roehl, University of Waterloo Electrical Engineering Dept
	Mail: broehl@watserv1.waterloo.edu OR broehl@watserv1.UWaterloo.ca
	BangPath: {allegra,decvax,utzoo,clyde}!watmath!watserv1!broehl
	Voice:  (519) 885-1211 x 2607 [work]