🚀 go-pugleaf

In article <1993Jan27.043333.703@rock.concert.net> syzygy@rock.concert.net (Andrew B Smith -- Personal Account) writes:
>
>With all this talk of virtual reality (VR) and the waves of the
>future as related to VR, it has occured to me to ask whether any-
>body has thought to apply standards to the idea...
>
>I've been thinking a great deal on the realistic approach to
>bringing VR to the everyday houshold.  It seems to me that one
>of the strongest advantages any VR application would be total
>compatibility with the majority of other VR applications.  For
>those of us familiar with XWindows on a workstation, we know 
>just how nice it can be to run a graphical application from some-
>where else as if it were on your own machine.  Similar features 
>should be available to VR applications in the future.  To acheive
>this end, it will be necessary to build compatibility into VR worlds.

One in ten (technical) papers that I read on my walks through the
archives includes a call for standards. The problem is that every
group develops their own (admirable) architecture for a VR system,
usually using the client-server paradigm like X. All of these would
work, eventually, but almost none with each other.

More to the point is that the commercial concerns have their own
agenda, primarily of making a product which can sell, which means they
have to cut all sorts of corners to get it useful - none of which
involves generalising the architecture. Why do you think X runs like a
pig - because it is general. It won out because it worked just well
enough, was built for the future, and primarily was cheap, and you
could get the sources.

Frankly, I see the v-w approach going the same way. Lots of the little
companies which now have, and will continue to have niche markets
which will gradually expand, but when there is enough interest, one of
the institution developed general systems will probably take pride of
place.  (I only know of 5D, VEOS, and aviary at the moment. You can
get VEOS from the sci.v-w archives. Alternatively, a few people have
thought about starting from a MUD base - see the mud faqs for where
you can pick up their sources - but all seem to have come to the
conclusion that they are all but useless for the real-time graphically
based environment that most people mean by v-w).
-- 
       Jack               js@biu.icnet.uk
                         
If you only have a hammer, you tend to see every problem as a nail.
                -- Maslow

	Before I start quoting, I would like to say a few things -
	My introduction produced a number of replies (via e-mail) introducing
subjects that I'd like to see discussed as a part of the group.  One of these
(directly related to quoting below) is the formation of a 'group' focusing on
design considerations and shaping the computing medium of the future.
	I whole-heartedly support this suggestion.  If any readers of this
newsgroup are currently a part of VR development, PLEASE POST!  I would like to
know first-hand what the state of the art is, as well as what problems have
been encountered so far.
	
	Anyone interested in creating a VR focus group, please e-mail me
(brownea@cc.uvcc.edu).  I don't think I'll be able to do much more than basic
management (limited VAX access), but I would be glad to start co-ordination if
there is enough interest.  If you do volunteer for the group, please send a
brief description of yourself, goals, history, and what you might be able
(translate: willing) to do to help the group.  I see a future need for; an FTP
site, a newsletter management system, a members list with a correlator, a FAQ
(Frequently Asked Questions) list.  Let me know if I've missed anything.

	Okay, now for quotes.  Please note that my opinions come from a C++
(object-oriented) frame of thought. 

The following is quoted from what should be the post imediately before this:

In article <1993Jan27.043333.703@rock.concert.net>, syzygy@rock.concert.net (Andrew B Smith -- Personal Account) writes:
> 
> With all this talk of virtual reality (VR) and the waves of the
> future as related to VR, it has occured to me to ask whether any-
> body has thought to apply standards to the idea...
	I have.  Even to the extent of designing a system based on my initial
standards (not as in-depth as you've looked at creating).

> 
> I realize that it is probably too early to seriously apply any
> standards to VR programming, but it might be nice to get a head
> start on defining what issues will concern VR programmers.
	I disagree about too early.  I don't know if we'll have any say-so
without doing any actual VR development (or funding it).  It's never too early
for good design, and I think that a well thought-out design will be likely to
be accepted when the people who are on the frontier start thinking about
standards.

> VR Standards (tentative ver 1.0) -- issues to be considered
> -----------------------------------------------------------
> 
> 1.  Basic Software and hardware concerns
>    - frames/sec of animation
	I think, instead, a formatting standard to allow real-time emulation. 
This way each system could be designed for maximum capability without worrying
about crippling itself for compatibility reasons (let's _promote_
improvement!).  I see something like 'frame-skipping' to keep the 'world'
working correctly.

>    - degrees of view (horizontal and vertical)
>    - # of colors (the first standard could just have black, white and
>      grey shades)
	I see no reason not to include color as a part of the first revision. 
I think we should plan far beyond our current capabilities.  This way, we have
less upgrade-incompatibility to worry about.
>    - lighting model and shading
	What about transparency levels?

>    - vision curvature for peripheral vision

	  Actually, I think hardware design could easily be left to the 
manufacturer.  As long as his stuff will work with my code, I don't really
care how he goes about it.

>    - for remote VR applications, what kinds of protocols / hardware
>      ie. tcp/ip with ethernet on an IRIS
>    - goggle type (polarized lcd, color filter etc)
>    - sound support and dimensionality (should the sound be louder in
>      the left ear if the source is to your virtual left..?)
>    - spectrum support.  Should the VR be able to simulate infra-red &
>      ultra violet.  
	I think this would be simple to do.  The simulated infra-red colors
would be normal colors, just a differing cause.  I think the thing you might be
looking at would be 'does an object cause heat?'

>    - light beam creation.  In reality, beams are visible by light
>      reflecting off of suspended particles which obviously won't
>      be present in VR.
	For simplicity sake, I've always kind of considered that each object
will be self-illuminating.  Light exists in cyberspace as a result of an
object, not a reflection from the object.

> 2.  Physics
>    - what is an atom?  Is it an object or does an object consist of
>      atoms (specifically, what is the most basic building block in
>      a VR environment).  
	I've always figured an 'object' to be the simplest piece of cyberspace. 
It's what goes into the object that needs be defined.  Things like mass,
interactivity (can I touch it with my object? - collision management), colors,
position, speed, direction of motion.  What type of mass does it have?  and 
interaction levels (it should be possible for one object to absorb another).

>    - gravity.
>    - wind/air pressure effects
>    - heat
>    - general forces of attraction/repulsion (ex. magnetics)
> 
> 3.  Object characteristics
>    - elasticity
>    - mass/weight
>    - reflectivity/color/lumosity
>    - surface texture
> 
> 4.  Environment
>    - light source
>    - terrain mapping (if a terrain is being used, how is it stored
>      and displayed)
>    - scale
> 
> I'm sure that there are many things I've forgotten or overlooked.  As
> I said before, any input is welcome.  Some things, like standard hand
> motions for actions (ex. pointing to move in a direction) could be
> standardized very early, while things like terrain mapping would 
> obviously take a bit of time.  I hope I've given you all some food
> for thought,

	Here's a basic layout of how I see VR programming to work (please note
that, once again, I don't care what the manufacturer does, as long as I can
code to this 'type'):
	A VRE (VR Environment) should be able to be maintained apart from main
CPU operations.  Years ago, I thought it would be a Neat Idea if the hard-disk
controller, or video subsystem were 'intelegent'.  Had their own 8086(+) chip (I
do come from a PC world).  Based on this, a VR engine should be able to be on a
'card'.  Able to manage itself, given a basic operation.  Before I get into
coding standards, let me give an example of the hardware I dreamed up.  This
system is based on use with an IBM PC-compat.  It has no cosiderations for
sound (I don't see any problem with creating that).
	The focus is differing points of view from a single set of data.  The
engine is built based on the SCSI interface design, but many SCSI features are
removed to increase processing and communications speed.  The initial,
required piece of the engine is the correlator card.  This card will actually
be plugged into the motherboard.  It's job is to maintain the cyberspace world. 
It would need a HUGE amount of memory (the size of your active virtual world is
determined by what can fit into the RAM on the card), since every object in
your visible world will be maintained by this card.  It will have connections
to subunits which each control a point-of-view.  This way, a stereo vision
effect could be created, or a mono-vision effect.  Each is simple, just a
point-of-view.
	Since this is based on the SCSI system, each is chained onto the next,
with a maximum of 7 points of view.  A view unit will request a region of
cyberspace (conical, to account for point-of-view; perhaps we should include
flexibility enough in our spec definition to allow neural taps to request a
360-degree point of view (pov)).  The region is submitted to the view unit
which translates a 'map' of the pov into a disply of what is within pov. 
This leaves each unit hardware and software independant of each other unit.  As
long as they speak the same protocol, they can work together.  It also reduces
the processing load on the map-server (main unit), since it will not be
required to translate it's information into a hardware-specific mapping type
(like we're doing now on the pc).
	What the map-server _will_ have to do:
	maintain submitted objects:
		Objects are submitted by a program which is actually running on
the computer.  The description of the object is understood by the BIOS for the
map-server (MS), and from that basis of information, an object is created.
 	Serve pov maps to view units:  
		This really is very simple.  A pov map is really just a copy of
sections of the MS memory.  This WILL need a definition of how this map is
layed out.  Consider that this is a conical 3-d cross-section!
	Respond to the active program with information about a given object:
		This is (currently) very important, since it will save memory
for the computer running the program.  On a pc, this system should be able to
run in less than a single megabyte of memory.  I can see the future giving us
nearly unlimited memory with faster access time than we have now.  Good.  Let's
plan for ease of use AT THE LOWEST LEVEL, while expecting a better future.

	Somehow, the map-server will need to be able to update it's internal
information.  With the spec as I've got it now, you're world-size is limited to
the amount of RAM on the MS.  I'd like to see this be changed, but I think that
will really belong to the program using the VR system.  I guess, the map-server
will need a 'load region' type of function.  Couple that with a 'save region'
capability.

	Well, this is the basics that I've come up with as a way for VR to
work.  I think to build a standard, you need an idea of what your building to
fit.  

So, my expectations when building a standard:
	Seperate hardware from software whenever possible.
	Seperate software capabilities whenever possible - make an engine
		design, instead of a program design.
	Plan for a HUGE future, while making the ABSOLUTE best of what we've
		got right now.
	Start simple, and work your way up, building on what you've already
		got.
	
	Earl
	brownea@cc.uvcc.edu