Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!mordor!lll-tis!ames!ucbcad!zen!ucbvax!ZERMATT.LCS.MIT.EDU!RWS
From: R...@ZERMATT.LCS.MIT.EDU (Robert Scheifler)
Newsgroups: comp.windows.x
Subject: Minutes of X11 3D Workshop, 18-19 Jun 1987
Message-ID: <870630090409.5.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Tue, 30-Jun-87 09:04:00 EDT
Article-I.D.: KILLINGT.870630090409.5.RWS
Posted: Tue Jun 30 09:04:00 1987
Date-Received: Thu, 2-Jul-87 00:55:46 EDT
Sender: c...@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 860
X11 3D Workshop minutes, 18-19 June 1987, MIT.
Tom Morrissey (HP) and Jim Michener (Apollo)
Attendees:
Marcel Meth, AT&T Bell Labs
Mark Hood, Applicon/Schlumeberger
Tony Barkans, Applicon/Schlumeberger
Dave Gorgen, Apollo Computer Inc.
Jim Michener, Apollo Computer Inc.
Jud Harward, Center for Remote Sensing, Boston University
Hann-Bin Chuang, Astronomy Dept, Boston University
Bernard Servolle, Bull-MTS
David Bailey, CalComp
Patricia Barstow, CalComp
Jan Silverman, CalComp
Jan Hardenbergh, Cognition, Inc.
Steve Blank, Dana Computer
Bruce Borden, Dana Computer
Mark Patrick, Dana Computer
Dana Marnell, Data General Corp
Ying-Sheng Wen, Data General Corp
Brian A. Axtell, Digital Equipment Corp
Laurence Cable, Digital Equipment Corp
Dave Carver, Digital Equipment Corp
George Champine, MIT / Project Athena
William Clifford, Digital Equipment Corp.
Dick Coulter, Digital Equipment Corp
Jeff Friedberg, Digital Equipment Corp.
Branko J. Gerovac, Digital Equipment Corp.
Elana Granston, Digital Equipment Corp.
Harry Hersh, Digital Equipment Corp.
Robert Holt, Digital Equipment Corp.
Kathleen Langone, Digital Equipment Corp.
Leszek Kotsch, Digital Equipment (Europe) S.A.R.L.
John McConnell, Digital Equipment Corp
Rico Piantoni, Digital Equipment Centre Technique Europe
Randy Nickel, Digital Equipment Corp.
Pete Nishimoto, DEC - VMS Workstations
Randi J. Rost, Digital Equipment Corp.
Jeffrey S. Saltz, Digital Equipment Corp
Reinhild Schwarz, Digital Equipment Corp
Shreyas B. Shah, EDS/GM
Roy Wirthlin, EDS/GM
Stefan Noll, FhG AGD
Gregg Orangio, General Electric, Silicon Systems Tech Dept
Tom Morrissey, Hewlett-Packard
John Howard Palevich, Hewlett Packard Laboratories
Jeff Stevenson, Hewlett Packard
Greg Laib, IBM
Mitch Kuninsky, Masscomp
David Wolfendale, Masscomp
Mike Bailey, Megatek Corporation
Paul Dworkin, MIT / Media Lab
Bob Scheifler, MIT / LCS
Y. Obi and Y. Hongo (Japan), NEC Systems Lab
Robert L. Gordon, Prime Computer,Inc.
Salim Abi-Ezzi, RPI / CICG
Dan Reece, SDRC
Mark Callow, Silicon Graphics
Nai-Ting Hsu, Silicon Graphics Inc.
Allen Leinwand, Silicon Graphics Inc.
Andy van Dam, Stellar Computer & Brown University
David Laidlaw, Stellar Computer
Jerry Evans, Sun Microsystems
Lewis Knapp, Sun Microsystems
Eileen McGinnis, Sun Microsystems
David Rosenthal, Sun Microsystems
Dennis Doughty, Symbolics, Inc.
Bill York, Symbolics, Inc.
John Dalrymple, Tektronix (Information Display Group)
Dave Verhoeven, Tektronix
Georges Grinstein, University of Lowell, Graphics Research Lab
Zhong-Yu Zhou, University of Lowell, Graphics Research Lab
Deyang Song, University of Lowell, Graphics Research Lab
Greg Cockcroft, Univ. of Michigan, Center for Info. Tech. Integration
Bertram Herzog, Univ. of Michigan, Center for Info. Tech. Integration
Michael Foody, Visual Edge Software Ltd
Larry Atwood, Visual Information Technologies
9.30 Called to order by Branko Gerovac.
Branko did some straw polls to characterize the group. Lots of
vendors, x-windows users and implementers, 3D graphics systems
implementers, graphics and windowing standard folk. Not many
application developers/users.
Some X history. Emphasize omission of "policy" in X.
Discussion of possible meeting logistics.
Version 2.07 X3D was distributed prior to the meeting. This proposal has
been revised from comments from, and work with, Sun. This new version is
version 2.08, which will be presented at this meeting along with the deltas
between version 2.07 and 2.08.
What is the goal/focus of the meeting?
Just to discuss the DEC/Sun (version 2.08 X3D) proposal?
The only proposal received as input to the workshop is the 2.07/2.08
X3D doc. There was some discussion of whether we should talk about
goals before we talk about a particular proposal. One goal of the
meeting is to solicit participation.
Context / overview of effort (Randy Nickel & Eileen McGinnis)
What were they (DEC) trying to accomplish?
1. to extend X for 3D graphics,
2. to support graphics standards (especially PHIGS & PHIGS+ (the stable
parts of PHIGS+)),
3. to expose features and functionality that are provided in the newer
technologies, and
4. to do this in a timely manner, (requirements / need is there now for
high performance 3D graphics within the X windowing environment).
(before 1990)
Questions from group:
What is explicitly not be addressed by this?
Imaging, CSG, 3D text are NOT explicitly addressed.
Explicit support for PHIGS/PHIGS+ IS provided.
Is a sample server to be provided? Simple answer - yes.
What is being proposed (protocol, library)?
Just a protocol. The library and C-binding in 2.07 were just examples.
Technical overview "high order bits" (Randi Rost)
Why is X3D necessary?
- The X window system needs 3D graphics capabilities
- PHIGS and PHIGS+ need an X window system binding
- Current hardware products have more functionality than is
exposed in graphics standards (not so true since PHIGS+ development
has progressed)
X3D Product Goals
- Provide 3D graphics functionality as compatible X extension
- Support efficient layered implementations of graphics standards products
- Support workstation products from low end to high end
- expose features of high end systems
- allow efficient implementations on low end systems
- Provide timely implementations on a variety of platforms
X3D support for standards
- PHIGS most important
- Incorporate stable PHIGS+ functionality
- Synchronize with October 87 PHIGS draft (DIS text)
- Support other standards like GKS-3D
Standardization goals and non-goals
- create a standard 3D extension by working within the X community
- no current plans to attempt ANSI/ISO standardization
- must standardize X3D protocol to ensure network compatibility
- may standardize X3D client library (X3lib)
- X3lib provides thinnest layer on protocol
- may not want to expose X3lib to standards users
- vendors have existing libraries to support
- don't need to standardize utilities
- examples are included in proposal document
- vendors may have own preferred conventions
Primary features of X3D
- X-compatible, extends X capabilities of 3D
- full 3D graphics in window environment
- network based
- industry standard
- hope for multi-vendor support
- efficient PHIGS, GKS support
- PHIGS, GKS developed before widespread use of window systems
- based on modern graphics model
- includes support for reflection, lighting, antialiasing
- flexible, efficient on a variety of systems
- supports new hardware/software technology
- Feasible, practical (actually a goal not a feature); can
be implemented in a timely manner
- X, X3lib prototype
X3D (DEC) design team: (note: across many DEC groups)
Randi Rost, DEC Workstation Systems Engineering
Jeffrey Saltz, DEC Base Graphics Systems
William Clifford, DEC Base Graphics Systems
Peter Nishimoto, DEC VMS
Jeffrey Friedberg, DEC High Performance Workstations
Branko Gerovac, DEC High Performance Workstations
Dick Coulter, DEC High Performance Workstations
Brian Axtell, DEC Base Graphics Systems
John McConnell, DEC Corporate Standards
Technical details (Jeff Friedberg)
X3D technical goals
- promote illusion that each window is an independent 3D workstation
- support structure mode and immediate mode with one interface
- strive to keep interface "policy free" (no favors)
- provide extensible, long-lived 3D interface
- K.I.S.S. Keep It Simple Stupid (simplicity)
? Since there is this list of deferred things, is there a second order
extension mechanism (for things like GDPs, GSEs, escapes)?
Not yet, may be needed.
X Client/Server model
client client
\ \ /
\ \ /
v v v
X server
Connections are atomic-command oriented.
X and X3D dispatchers (figure)
X3D
Request -> Connection -> Core X ----------------> X3D
Queue Dispatcher Requests Dispatcher
/ | \ / | \
v v v v v v
C o r e X X 3 D
Resources in X3D
- GContexts (extended)
- Windows (extended)
- Pixmaps (extended)
- Fonts (extended)
- Font families (new)
- Structures (new)
- Format contexts (new) e.g. floating point
Possibly not appropriate in graphics extensions, should possibly
be in connection contexts in X
Extended GContext
- output primitives
- transformation attributes
- rendering attributes
- raster attributes
3D drawable hierarchy
3D drawable
/ \
X drawable \
/ \ \
window pixmap structure
Output command processing (figure)
output output
commands commands
| |
v v
Renderer Element
| Pointer
| |
v v
Raster Structure
Data Elements
............. .........
Window/Pixmap Structure
A renderer
Purpose: distinguish (support) immediate mode and struct traversal
Output commands Traverser commands (Post Root, Set Regen Mode)
| |
v yes v
? call structure? ------> structure traverser <----> structures
|
| no
v
rendering
pipeline
|
v
raster data
A somewhat ambiguous and loaded model, hence some discussion ...
? Send same command to a struct AND to an X drawable? No
? What is the structure traverser really doing?
? What is in the server and what is in the client?
Traverser and structures are in the server.
? What about synchronization of the traverser?
Due to the contentious nature of the topic, this was referred to
sub-group for discussion.
? Atomicity of commands? Intend to permit parallel traversals.
There are two kinds of atomicity:
Traversal atomic (cannot twiddle with environment during traversal)
X command atomic (indivisible queue per connection)
X3D rendering pipeline (figure)
Base geometry & input colours
| local modelling coordinate system & input colours
v
Colour type conversion
| local modelling coordinate system & base colours
v
Composite modelling transformation
| world coordinate system & base colours
v
View orientation transformation
| view reference coordinate system & base colours
v
Light source shading computation
| view reference coordinate system & shaded colours
v
Depth-cueing computation
| view reference coordinate system & depth-cued colours
v
View mapping transformation
| normalized projection coordinate system & depth-cued colours
v
Clipping
| clipped normalized projection coordinate system & clipped colours
v
X window coordinate mapping
| X window coordinate system & clipped colours
v
Device coordinate mapping
| physical device coordinate system & clipped colours
v
Device colour mapping
| physical device coordinate system & physical device colours
v
physical device coordinates & physical device colours
? write back atomicity?
Renderer State
- pipeline state
- current attributes
- GC aliases
- light tables
- colour table
- filters containing name sets
- hit test results
- traverser state
- root of posted structure network
- implicit traversal mode
A structure resource
element pointer -------> structure elements
editing mode
Structure networks
S1 S4
/\ /\
/ \ / \
v v v v
S2 S3 S5 S6
\ /
\ /
v
S7
Call structure execution
Structure A _-> Structure B
set text colour / polyline
set HLHSR mode / set curve colour
call structure B / text
set curve colour <---\__ set curve style
set marker glyph \-polyline
11.05 break
11.15 re-convene
Overview of topics for further technical discussion
(elaborated throughout meeting)
- traversal semantics
- client/server execution semantics
- write back data to client
- structure extensions (data per object)
- double buffer proposal
- input model
- PHIGS[+] layering on top of X3D
- peer interfaces
- binary binding for protocol
- conceptual CSS's "location" in X3D
- how to GSE, GDP & escape
- defaults
Documents
- X11 protocol
- X11 xlib
- X11 xtoolkit
- dpANS PHIGS
- PHIGS+
- X3D 2.08
- X11 Input Extension proposal
Possible proposals that may need to be considered
- X3D 2.08
- Something from Tektronix
- Something from SGI
- PHIGS+
- Postscript 3D
SGI view of things (Nai-Ting Hsu)
A high-quality PHIGS implementation may not be the best path.
SGI's experience with hundreds of significant real-time 3D applications.
"Adequate" performance is not enough
Experience shows a "RISG" approach wins
Minimalism is the route to real-time 3D
PHIGS on X3D delivers a "terminal" graphics model to applications
The terminal model does not support dedicated 3D interaction well.
The 3D graphics interface is a poor place to split an application.
"RPC" (Remote Procedure Call) delivers a more general interface
A simple graphics interface is called for
Embodies a RISG approach, to support effective dynamic applications
Relies upon powerful atomic primitives
Delivers a flexible lighting model
Provides interaction handling on the workstation
SGI is working on a proposal and would like to distribute it around the
Siggraph timeframe. It is not being proposed to this group, since it
is not strictly limited to X/windowing. This is merely mentioned for
the information of the group. Contact SGI representatives (see attendees
list) for more details and getting a copy of the proposal.
? More detail? Difference of emphasis. X3D 2.08 suggests how to
partition things.
? Expect data structures to be on which side of 'wire'? Application
dependent
? Expect to take GL and RPC-ify it? Not necessarily
? Is there an extension language?
? Public Domain or licensed? Not decided yet.
? Postscript 3D was listed before as possible proposal. Is anyone
going to submit it for consideration? (No response)
A goals discussion:
Library interface inappropriate, since it conflicts with
PHIGS[+], GKS/GKS-3D, CGI. No API (for now).
Library interface (API) to the full power of the protocol is
suggested to be necessary (e.g. for eventual testing).
? Goal to Add 3D to X or Do 3D in X window environment?
(The latter implying having a local 3D application.)
Several definitely in favor of the former.
Protocol document not low enough; too much functional definition
(heavily PHIGS[+] vs. CGI)
Should this be a more general basis for a broader set of standards?
Should the protocol support just PHIGS[+] and GKS/GKS-3D or should
it support proprietary graphics interfaces and other graphics
standards (CGI).
Protocol extension versus window information access.
Peer interface as implementation.
Geometry & rendering (shape/sort) best done on server
If goals is to support PHIGS[+], why not make the protocol map
directly (1-1) to PHIGS[+] API? The protocol is a different level
in the system, and it is necessary to express the protocol in
a form fitting into that level of the system and into X protocol.
(But: It is hard to define something below the level of PHIGS that
supports PHIGS.)
Minimize network traffic.
Metagoal: Have a simple set of goals.
Suggestion: rename X3D 2.08 -> PHIGS[+] extension for X
architectural issues (RPC ... underlying across)
(this then is not an X extension)
David Rosenthal's attempt at shooting down API advocates.
- API already addressed by ISO/ANS
- Server extension mechanism not defined yet, and won't perform
well enough to meet graphics goals. The server extension
mechanism is not mature enough to use.
- Therefore, only address protocol.
Need for generic low-level (elemental) protocol, e.g.,
"just" shaded triangles and vectors.
12.45 broke for lunch
14.00 reconvene
How to proceed?
Break into the following groups
1. protocol specific to PHIGS (Gerovac)
2. protocol for atomic generic low level
(non-PHIGS, not anti-PHIGS) (Verhoven)
3. peer interface for graphics (Palevich)
to determine their respective goals.
Broke into groups to at 14.15, to re-convene at 15.30
Reconvene at 15.50
Non-PHIGS protocol group.
PHIGS is not the answer for everyone.
Bruce Borden will prepare a proposal to interface at the Z-buffer
level (a very low level) by August 1.
Non-PHIGS goals
- allow multiple extensions that don't interfere or preclude each other
- have a low level 3D model
- allow a decision to be made at runtime on how to partition the
pipeline between the client and the server
- allow for passing data by reference
- provide access to various points in the pipeline
Question
How much 3D functionality can be added to X without violating the
"no policy" goal? Not much above "true colour pixels".
Peer interface group.
Goal - Allow peers to bypass X11 for the highest possible performance
(w.r.t. output in windows). This might be achieved by providing hooks
for highest possible performance for environment where there is a
"fast path" between the application and the hardware (but at the
expense of portability). The X11 server still arbitrates window
clip lists and screen resources and distributed input, etc.
One possible model
3D clients High performance clients Pure X clients
\ \ | \ | \ / / /
\ \ | \ | \ | | |
V V | ----|-----------------> V V V
3D server ---------|-------|-----------------> X11 server
\ | | /
\ V V /
-------> Hardware <------------------
A possible model of a client (figure)
---------------
| Application |
---------------
|3D| | |
---- | xlib |
|dd| | |
---- --------
| | |
fast path >| \ | < X11 protocol
| \ |
| V? V
| --------------
| | X11 server |
| --------------
| | dd x calls
V V
---------------------
| dd |
---------------------
|
V
hardware
Concern: clip list synchronization
local connection to (dd to X11 server) to get that
What should be standardized?
Protocol":
"express interest in fast-path"
"this window's clip list should be synchronized"
Sample server:
"lock clip lists" machinery
Fundamental requirements/issues:
synchronizing hardware access (implementer problem)
synchronizing cliplists between X11 server and clients
PHIGS protocol extension group.
Goals:
- PHIGS protocol extension & encoding compatible with existing X
- Incorporate stable PHIGS+ functionality
- Synchronize with PHIGS DIS (Oct 87 draft)
- Support a performance range of X server platforms
- Timely definition of protocol extension
- GKS-3D will be considered later either as addition to this
extension OR as a separate extension
Where do we go from here? What did we learn from this?
Query of folks' inclinations after seeing the goals of the efforts:
(Multiple inclinations permitted)
Most people are disposed toward working on PHIGS protocol.
About 1/6 of the folks are interested in the non-PHIGS protocol.
About 1/10 of the folks are interested in making a hybrid protocol
happen.
Generic (non-PHIGS) protocol (Bruce Borden, Dana Computer)
Application
^
\
v
database
\
Visualization
| + PHIGS+ protocol level
Database (display list)
|
Traversal
|
Transform
|
Clip
| * low-level generic protocol level
Z-buffer <-> Draw
|
Frame buffer
|
Display
Problem: Where is lighting and shading? (All over, ugh.)
Assertion: Bandwidth down to beyond the clip stage has the same
bandwidth (37.5 megabytes/sec), then the bandwidth explodes, and
hence is it useful at that level to define the protocol. (And
possibly at higher levels, too.)
Low level interface (at the level of "Z-buffer <-> draw" above)
Drawing (all 3D)
coloured vector
coloured triangle
random pixel write
Patterns
2D for all drawing primitives
1D stipple for vectors
enable/disable
z-buffer
clear
enable/disable
colour
mode
map management
(goal: Arbitrary previewing over the net, since
REAL application dynamics would be impossible over net
anyway -- see assertion above.)
17.20 adjournment for the day.
Friday, 19 June 1987.
9.40 re-convene
Process and logistics for further work.
Umbrella X11-3D organization
Report on X11 proposed future organization
June 8 meeting of 10 entities
MIT is going to prepare a proposal, available mid-July timeframe
to create an industry consortium under the auspices of MIT as
the organizer. The goal being the continuation of work on X.
Some fee for joining up. Some commitment (say 3 years). Members
would sit on an advisory board. MIT would be the decision making
body. The consortium would have a chief architect (an MIT person)
who would make the decisions. There would also be MIT staff to
take care of the logistics of X maintenance/development.
? Would there need to be a sub-chief architect (also from MIT)
for each major extension? Don't know - all of this is still
being formulated.
? Would the fee be graduated by company size? Ditto.
? Would universities and/or government agencies be treated any
different with respect to schedule? Ditto.
? What is the deadline for having this in place? Ditto.
We, X3D extensions, would like to be sanctioned by this yet-
to-be-formed group. The disposition of the X community seems to be
that if this group is reaching consensus, then continue.
Timeliness, schedule
What was/is the X11 schedule?
before - lots of independent, background work, X6 to X10
Apr 86 - first meeting
Jul 86 - 1st public review draft
Sep 86 - 1st public review closed
Dec 86 - major Berkeley Un*x release with X10 toolkits (HP & DEC)
Jan 87 - X users conference
Feb 87 - alpha server release
May 87 - alpha update
Jun 87 - beta server release
Sep 87 - close beta, release
DEC intends to provide a sample server for X3D
X11-3D proposed schedule
19 Jun 87 - workshop, public review, output X-PHIGS 2.08
22 Jul 87 - X-PHIGS 2.08 comments in
26 Jul 87 - PHIGS+ public review begins
03 Aug 87 - X3D meeting (west)
17 Aug 87 - X-PHIGS 3.0 public review
21 Sep 87 - X-PHIGS 3.0 public review ends - comments in
21 Sep 87 - PHIGS+ comment period ends
28 Sep 87 - X-PHIGS 3.05 document available
01 Oct 87 - X3D meeting (east)
05 Oct 87 - ASC X3H3 meetings (Lowell,MA)
12 Oct 87 - X-PHIGS 3.1 available
protocol spec / function freeze
19 Oct 87 - ISO PHIGS editting meeting (Fort Collins, CO - tentative)
26 Oct 87 - PHIGS+ meeting (Troy,NY)
09 Nov 87 - synchronize with PHIGS draft (DIS?/ANS? text)
16 Nov 87 - X-PHIGS 4.0 draft available
Sample server strategy
When available?
What available?
Skeleton useful enough to be fleshed out?
Possibly a assumes only a frame buffer?
The first sample server would most likely be a full software server
that would talk to a frame buffer.
Possibly a subset sample server in April 1988.
There will most likely not be a sample server in 1987.
Process
X11 process (fyi)
- an architect / document editor, Bob Scheifler, spent 70% of his time
- active individuals - contributors
- active reviewers - less involved than contributors
- daily exchange of mail with commenters
- continual incremental exchange
- periodic change summaries
- periodic portions
- occasional full releases
- Bob drives people toward resolution
- issues restatement when needed
- mail log
- geography not as important in the design process, but is
important for sample server development
ANS arena methodology
- commenting period
- meeting
- discuss comments
- draft & vote on issues
- sometimes draft document changes
- maintain issues log
- publish draft document
(sometimes after 1/2 cycle in committee)
- (sometimes) written responses to commentors
Which process is best for us?
- X11 process better for the timeframe we are looking at
- the architect is a pivotal individual in the X11 scheme
- most folks like the electronic and incremental nature of
X11 discussion mechanism
- issues are a fundamental tool for progressing the effort
- encourage comments in the form of issues / proposals
- principal architect (or architect team) for each extension
(right now, X-PHIGS+) needed
- a chairman of the X graphics needed
Deliverables
(see the schedule)
Resources
Propose: initial architecture team comes from individuals who drafted
2.08, other members welcome. Architecture team dedicated (50-100%)
to the effort. DEC and Sun will contribute to this team. The following
organizations had representatives that felt that their organization
should be on this team, but could not commit at this time: Tektronix,
Data General, Apollo, HP, Prime, IBM, Bull. Organizations should
notify the chairman (Herzog, see below) of their level of commitment.
Electronic mail distribution:
The X11 3D graphics electronic mailing distribution list is accessed
through: x11...@athena.mit.edu
It is your responsibility to convert the domain name to mail paths
familiar to you.
To get on the list, send mail to: x11-3d-requ...@athena.mit.edu
The x11-3d list will be zeroed out, so if you want to be on it, send in
a request.
x11-3d-works...@3d.dec.com will be set up this weekend as an interim
measure.
Organizational local mailing lists are encouraged. Each organization
should set up organizational distribution lists, and only place one
mail entry in the x11...@athena.mit.edu distribution list.
Copyright.
It is just there as a placeholder until it can be turned over to MIT.
DEC believes it is okay for organizations to duplicate the
document. If any organization has any problem copyrighting the
document with the copyright on it, contact DEC for more copies
or explicit release for the copyright.
Chair nominations
Roles & responsibilities of chair:
- manage the decision making process
- not chief architect
- resource requirement?
- public liaison (trade press, ANSI, professional societies)
- MIT liaison
- notification of activities (inside and outside group)
- manage membership
- Oversees all groups within X-graphics group, not just one
group (e.g. PHIGS)
- accessible (email)
- convene and chair X-graphics meetings
Nominations:
Bert Herzog, accepted and unanimously approved.
email address: b...@citi.umich.edu
Double-buffering proposal is 'formally' with the X11 base group
but comment and discussion in X3D arena is desired.
Name of the top-level committee dealing with graphics for X.
Ended up agreeing on X3D, but there was a strong sentiment for
something more general, X-graphics.
Much thanks to DEC and MIT/Athena for sponsoring the workshop.
Meeting adjourned at 15.30.