thinman@uunet.UU.NET (01/30/91)
This article explores my inspirations for a VR language
design.
Sources of inspiration: X
The X Window System has demonstrated the incredible benefits
of separating applications from computers with graphics
hardware. Its breadth of applications and range of hardware
platforms show the power of this concept. Unfortunately,
all other aspects of its design are clumsy, making it
difficult to hold X up as a shining example. Happily, there
are better ones.
Source of inspiration: NeWS
SUN's NeWS system uses PostScript which, like its
inspiration, Forth, was designed for easy human and computer
interpretation. These factors and other design decisions
doom it to full interpretation by a uni-processor
interpreter. Over the next 10 years the cost of parallel
processing and RAM will continue to rocket downward. The
language should be very high-level, so that the remote
hardware can compile downloaded software into directly
executable form across the wide variety of platforms which
exist or will soon. It should be possible to translate a
program into a fairly efficient binary for uniprocessor,
multiprocessor, and custom hardware platforms. A single 3D
graphics program should run on on a PC or an SGI. (However,
it should make nicer pictures on the SGI.) A program ported
to a machine 1000 times faster should run at least 100 times
faster.
Source of inspiration: Habitat
The Habitat system is an interactive computer game using
arcade-style graphics on a Commodore 64, connected by 300
baud modem to a national computer BBS. It's communal: up
to 6 people play in one cell and appear on each others'
screens. It's big: there are 20,000 cells, 15,000 paying
subscribers, and several hundred people logged in on a
normal evening. All software in the game resides on the
home terminal. (The Japanese version uses a 386 PC with a
built-in CD ROM loaded with graphics.) Only high-level game
control information goes over the slow, non-real-time data
connection. Habitat proves that networked graphics software
can work, if the right information goes over the net.
Sources of inspiration: BASIC
With a language which is downloaded in source form, users
are always in control of their environment. Every time I
use a Mac, I want to throw it out the window, because
I am only allowed to do what some programmer thought I
should be able to.
Sources of inspiration: Hierarchical display lists.
The concept of hierarchical data representation used in
PHIGS (and elsewhere) is powerful. Inheritance of
"properties" or "qualities" such as position, color,
shading, specularity, etc. is a very natural structural
technique. The language should be based around hierarchical
inheritance. While strict hierarchical structure doesn't
support some styles of data structure, it does most of the
job that we need. Other types of data structure, e.g.
various types of graph, can be implemented by adding a
construct that connects parts of the tree.
Sources of inspiration: Functional Programming
Standard procedural programming describes actions on data
over time. Under Functional Programming a program is a
hierarchical tree of functions. When the program is run,
portions of the tree are evaluated and I/O occurs as a side
effect of evaluating those portions. A hierarchical
graphical data list is like a Functional Program:
evaluating the list creates an image as a side-effect. It's
natural to extend this concept to interaction: every time
the picture changes in response to user input, the "picture
function" is evaluated again. For virtual reality, the
function may be evaluated 60 times a second, twice for
stereo viewing. More precisely, a VR program can choose to
evaluate the graphics function based on successive values of
a system clock which ticks every screen redraw.
The language needs real-time specification. With a high-
level scene description language, you don't specify low-
level control, but instead specify when different sub-
programs will be run. The system has algorithms for
scheduling out the different tasks. This is very Zen:
instead of completely controlling the computer, you tell the
computer "do what I mean" and it will do the best it can.
Obviously, more sophisticated analysis becomes possible with
a more abstract language.
Almost all existing window systems include several inches of
documentation and require the programmer to memorize large
chunks of it; generally they are not accessible to unskilled
programmers. Non-programmers are only allowed to interact
with the creations of skilled programers. Using these
systems is much like watching TV with a very powerful remote
control: it's pleasant, but you don't get to shoot your own
videos. The language should consist of several layers of
lightweight tools, each of which is fairly simple by itself,
but create complex effects when combined. (The UNIX
"spell" program is, or was, an shining example of this. It
consisted of four simple programs, run in sequence.) These
off-the-shelf components, and a CASE system, should allow
non-skilled programmers to write graphics software (as
Logo does).
The language needs network access. Given that a program is
read in by the system in an encoded source-level form, it is
simple to extend the system so that sub-programs are sent
across the net and executed by the receiver. A MazeWar game
would send out simple tree functions containing variables
showing a player's position, orientation, and laser trigger
status. This opens up security problems: both in handling
hostile attacks and buggy downloaded programs. On the other
hand, the system can start up with no program at all and
download a world with the same mechanism it uses to
communicate with other systems. "Code as data" systems have
the horrible problem that compilation becomes very
complicated. All compiled objects need "wrappers" that
allow them to be linked in and out of the system, which is a
noticeable overhead item.
A language like the one outlined here can live and grow for
the next ten years, serving the needs of 3D graphics and
hypermedia during that time. It will take a year to design
the language and turn out a low-res, low-speed, portable,
production-quality system for CISC and RISC desktop
machines. A simple authoring/playback system for these
machines will serve to get the software in the hands of
industry sponsors, third-party developers, and hackers, who
will be the backbone of the effort. After designing the
basic display engine, the next phase is to design a user
interface toolkit that explores the concepts of user
interfaces which vary according to machine capability and
personal taste. After a lot of experimentation with a
working system, it will be possible to codify a user
interaction language similar in scope to the Macintosh UI
guidelines.
I have a preliminary version of my language design, based on
the functional programming/display list ideas outlined
above. I will post it in a week.
First the fuse, then the bomb :-)
Lance Norskog
thinman@cup.portal.com