ERCIM Research Report - 02/97-R049
ERCIM
Computer Graphics Network
Edited by David Duce, Klaus Kansy and Michael Wilson
11th February 1997
The ERCIM Computer Graphics Network organised a workshop on VRML at the
Coseners House, Abingdon, UK, on 29/30 January 1997. The idea for the workshop
came from the Steering Committee of the ERCIM Computer Graphics Network
in May 1996. It was felt by the Steering Committee that a workshop was needed
in order to formulate a European view on VRML. Version 2.0 of VRML was due
to be published in August 1996. All groups in the ERCIM network expressed
interest in the topic and a number of topics were identified:
One of the key questions to be addressed was "what additions should
be in VRML 3.0"?
Since that time, VRML 2.0 has been put forward for standardization to
the ISO/IEC Committee responsible for computer graphics and image processing
(JTC1/SC24). A review of the document took place in the autumn of 1996 and
an Editing Meeting to address the comments raised on the letter ballot took
place in the USA in December 1996. Several members of the ERCIM Computer
Graphics Network were involved in the preparation of these comments. Three
major concerns identified in this process were the quality of the VRML document,
the suitability of VRML for use in visualization applications and the use
of VRML in multi-user worlds.
The meeting opened with an introduction to the background and aims of
the workshop, given by David Duce. Anthony Steed, from University College
London who was a member of the UK delegation to the ISO/IEC VRML Editing
Meeting gave an overview of the state of the VRML document within the standardization
process. Two talks were given by researchers from the University of Leeds,
introducing the topics of VRML in visualization and multi user worlds and
describing work in progress at Leeds in these areas. The meeting then split
into working groups to address these two topics in more detail. It had been
hoped that there would be the opportunity to review the new VRML document
arising from the Editing Meeting, but this was not available in time for
the workshop. It had also been envisaged that some work could be done on
formal description of VRML 2.0, but it did not prove possible to do this
and this will remain a task for a future meeting.
At the close of the workshop, reports were received from the two working
groups and recommendations to ERCIM were formulated.
A list of attendees at the workshop, together with email addresses is contained in Annex A.
Anthony Steed of University College London, described the current state
of the VRML document and the discussion and decisions made at the Editing
Meeting in December 1996. Copies of Anthony's slides are appended to the
paper version of this report.
Anthony's interest in VRML came from his PhD work, where he developed
a data-flow like VR system which had architectural similarities to the sensor
- logic - effects model of VRML.
Development of the VRML document appears to have been driven by the annual
occurrence of the Siggraph Conference. The VRML Architecture Group (VAG)
conducted the discussion of VRML through a mailing list. Two systems were
designed to meet the perceived requirements of the community: Moving Worlds
from SGI and Active VRML form Microsoft. Sony were involved in the Moving
Worlds proposal, but did not make a separate submission. This community
process resulted in the choice of the SGI Moving Worlds proposal. VRML 2.0
was published on August 4th 1996 and is available at http://vag.vrml.org/VRML2.0/FINAL
and extended VRML 1.0 with interaction, animation, scripting and extensibility
functionality.
Meanwhile, discussions were taking place between the VAG and ISO/IEC
concerning the standardization of VRML by ISO/IEC. Agreement was reached
in June 1996 that VRML 2.0 would be brought into ISO/IEC JTC1/SC24, the
computer graphics and image processing committee. The VAG would act as architects
and the ISO/IEC VRML Rapporteur Group, set up within SC24 to manage the
ISO/IEC VRML project, would comment on the document and assist with the
editing process.
The document entered the ISO process as a Committee Draft and was circulated
for letter ballot.
The UK, along with other nations, submitted detailed comments on the
document. The UK disapproved the draft for the following reasons:
The outcome of the letter ballot was 6 yes votes, 3 yes votes with comments,
and 2 no votes (UK, USA). 500 comments (weighing 3 pounds!) were received
with the votes. The Editing Meeting in San Diego in December 1996 was convened
to address these comments, produce a Response Document (a formal reply to
the submitters of the comments) and instructions for the Document Editors
for preparing the next version of the document.
The comments were well-received by the VAG members present at the meeting;
an additional 100 comments were added from the VRML "community".
There was great reluctance to change any functionality described in the
document that was not actually broken. The main reasons given for this were
the number of browsers currently available (at least 8) and the number of
VRML worlds that have been developed (at least 20,000), not to mention the
number of VRML books! However, it was emphasised that the VRML Consortium
(more of this later in this report) would encourage extensions to VRML 2.0.
The major changes agreed were:
Other comments did not receive such a sympathetic hearing.
Anthony's talk gave rise to much discussion. The key points raised are
summarized below.
Stuart Lovegrove, a PhD student from the University of Leeds described
the research he is planning to do. His thesis title is "Sustainable
Communities for Collaborative Research" and he started work on this
topic in October 1996, so the work presented is very much preliminary work
and first ideas.
The background to Stuart's work comes from the COVISA project at the
University of Leeds School of Computer Studies. The COVISA (Co-Operative
working in VIsualization and Scientific Analysis) project looked at understanding
requirements for group working in visualization. Fully working collaborative
extensions of the IRIS Explorer modular visualization system have been produced.
These allow several users to collaborate by exchanging data or by joint
control of the user interface.
The development of WWW technologies have also lead the group to look
at using IRIS Explorer as a visualization server. The user interface is
a HTML page, and the server returns the visualization generated as a VRML
file. Collaborative working is achieved by storage of previous results.
Further details of this work were given in Jason Wood's talk, see section
5.
The aim of Stuart's project is to combine these results, to provide WWW
visualization and multiuser, interactive and collaborative working in real
time, along with persistent data storage. The initial architecture is based
on a central server connecting to user and data clients. User clients receive
VRML files and JAVA. The central server controls message passing between
users. It is being written in JAVA (to aid portability) and supports multithreading
(allowing connection requests to be serviced at any time) and broadcasting
(allowing incoming messages to be sent to all connected users).
VRML files are used to represent shared scenes and avatars. Currently
these are statically defined. The VRML structure incorporates a script node
with an external JAVA class. VRML routes are run from the script file to
other nodes within the shared scene. Currently routes are also statically
defined. Eventually routing needs to be tailored to what each particular
user can interact with.
There is a socket interface between the JAVA client and the network,
through which events are passed from the server to the VRML file and the
VRML file to the server. The data client also has a socket interface to
the server. Users moving or interacting in a scene send messages to the
server, which provides a method of viewing all events.
Some proof of concept experiments have been carried out, based on the
Dimension X Liquid Reality browser. Two simple scenarios were shown. The
first provides a shared pointer, multiple avatars representing users and
a "clickable" cube which changes its colour in response to clicks.
The demonstration correctly displays the views of user 1 looking at user
2 and user 2 looking at user 1 on their respective browsers. In the second
scenario, users are placed in a simple world. Avatars now have a humanoid
appearance.
Stuart stressed that the work reported represents the very first stage
in his project and there are many questions and problems still to be addressed.
Issues raised include:
Michael Wilson gave a short presentation on current uses of VRML in a
range of different application domains and examples of applications that
VRML ought be able to support.
The Community Place system uses an architecture similar to Stuart's,
except that the VRML and database servers are combined. Position/location
is broadcast from avatars; avatar motion can be expressed.
The Sony circus park test demo is an illustration of the games sector. (http://vs.sony.co.jp/index-e.htm)
The DIVE 3D VR system does not use VRML but is an example of a multi
user VR application which VRML should support. (http://www.sics.se/dce/dive/)
Work at RAL on the use of VRML to visualize engineering design is an
illustration from the engineering sector. The RAL group have generated VRML
from a CAD package, in order to explore the assembly sequence of a complex
object (a very large detector for a high energy physics experiment at CERN).
(A fuller description will appear under http://www.ccl.ac.uk)
A Cambridge company have developed a web agent, Autonomy, which uses
2D icos to visually represent agent state, again this is an example of an
application which VRML should support. (http://www.agentware.com/)
The QPIT project at Lancaster University has developed an approachto
multi-user embodiment within data visualizations - populated information
terrains. This again is an example of a type of application that VRML should
be able to support. (http://www.comp.lancs.ac.uk/computing/research/cseg/projects/qpit)
The Persona project at Microsoft is looking at general Lifelike Computer
Characters. (http://www.research.microsoft.com/research/ui/persona/related.htm)
Jason Wood gave a presentation about work carried out by himself, Ken
Brodlie and Helen Wright at the University of Leeds.
Jason described a VRML 1.0 system for server-side visualization across
the web.
A traditional model of visualization considers the transformation of
data to image in three stages: filter, map and render. Overlaying this with
a server-client relationship, the server may be thought of as a publisher
and the client as a user.
A client-side approach associates the data with a WWW server and the
transformation process (filter, map, render) with the client. Data are requested
from the server (e.g. through a form interface) and are returned for local
processing by the visualization system located with the client.
A server-side approach associates the data, filter and mapping transformations
with the publisher in a visualization server, and the rendering process
with the client. This gives control for data mapping to the server rather
than the client. Again a forms interface to the visualization server can
be used to define the type of transformed data required by the client.
Leeds have developed such a visualization server, based on IRIS Explorer.
A forms interface is used to describe the visualization required. This is
passed through a CGI script to the visualization server which generates
a script to drive IRIS Explorer to produce the visualization required. The
geometry file output by IRIS Explorer is captured and translated to VRML
and passed back to the client.
An example application was described. Air quality data are available
from a public source. Data are collected hourly and made available about
2 hours later. Currently the data supplier provides the latest hourly data
values, previous data values, some forecasts of future values and some basic,
predefined graphs. A web-based interface has been written to this data service,
using the Leeds visualization server. From the interface form, the user
can select the site, pollutant, time etc. for which data are required. The
server returns a VRML file containing a visualization of the selected data.
The work has revealed some limitations of VRML 2.0, for example: adding
a colour scale so that the user can always see it is not at all easy. There
is a solution using proximity and sensors, but this seems an overly complex
mechanism for satisfying a rather simple requirement. Solutions such as
putting the colour scale in a separate viewing area do not work because
one cannot guarantee consistency of colours over areas.
This group was chaired by Michael Wilson, CCLRC.
The group viewed the basis of discussion as being four document sets
:
The working group was very much informed by the view of the current state
of VRML and the MUVW proposals of Anthony Steed (UCL) and Stuart Lovegrove
(U of Leeds) whom the group thank for their contribution.
Scope
It was agreed that the scope of MUVW would be expected to include many
things (everything that was suggested) :
Suitability of VRML2 for MUVW
The experienced view was that DIVE (from SICS) was the preferred MUVW
tool today rather the VRML2 ones, but it is supported on UNIX and not PC
platforms since it passes massive object state changes between peer to peer
connected clients, and includes no security so one user can destroy another's
VW. Therefore it is acceptable for responsible research use (it is also
free with source code), but impractical in many ways for commercial use.
VRML2 was accepted as the future for MUVW and there was not seen to be
any problems in it for most uses of rendition - most of the discussion was
about the interfaces, tools, and architectures for using VRML as the graphics
language about documents 2 and 3 mentioned above.
Recommendation :
The changes requested to the VRML standard itself were :
Architectures for MUVW
Suggested architectures include the client browser to HTTP server link
with the downloading of a MUVW, then the linking to the MUVW server to support
the existence, location, and action of objects in the MUVW such as other
users. Clearly the main role of the architecture is to maintain consistency
between different user's views on the MUVW.
The Living Worlds proposal does not address these three possible alternatives.
Efficiency/ Technical Capability
The efficiency of the architecture will be limited by a bottleneck in
any of 3 places:
Recommendation :
The MUVW proposal (documents in group 3) should provide a server API
to register services, and guidance on the placement of services at client
or server.
Object Creation by Users
VERMELgen uses Jverge Java class libraries to support the construction
of a VW from inside another VW, but uses the stand alone Jverge modeller
which may not be strictly VRML2 compliant.
There are no proposed mechanisms for MUVW users to create or import previously
created objects into MUVWs. This is a problem where a user at a meeting
wishes to introduce a model to explain something.
This issue is confounded by the general problems associated with object
creation in VRML2 itself.
Recommendation :
The MUVW proposal (documents in group 3) should address this issue and
propose standards with interfaces.
Consistency
Maintaining consistency between different user views of the MUVW was
addressed above in architectures. The main problem that most approaches
have is that of apparent simultaneous actions. For example, if two users
simultaneously pick up a wallet, which one has it. The window of a simultaneous
event is controlled by the delays in the network communication. These are
minimised if each object has an object server thread running on some machine
in the MUVW, and this thread is accessed before the world for any user is
updated (therefore two users can never pick up the wallet). However, the
cost of this solution is an increase in processing, and another communication
overhead. In a client/ single MUVW server architecture this is putting more
strain on the server communications bottleneck; in a peer to peer architecture
the threads for different objects can be spread throughout the participating
peers to reduce the bottleneck problem, but the communication still includes
overheads.
Recommendation :
The MUVW proposal (documents in group 3) should address this issue and
propose standards with interfaces.
Persistence
World Persistence : A user leaves a MUVW, but other users remain in it,
and make changes to it. A user then joins the world: do they enter at the
normal starting state, the state at which they left it, or the state in
which other users see it? Presumably, as a user enters a world and registers
with the world server, the server knows the start up state, and the current
state of the world, and informs the user's browser of the difference to
update the user's view of the world to the current state and ignores the
state at which the user left it. No document addressed this issue.
User Entry Point Persistence : In VRML2 worlds users enter at a standard
entry point. If the user has left a world he will not re-enter at the exit
point, but always at the standard entry point. If the local browser stores
the exit point from each world a user has left, then re-entry at that point
could be supported.
Recommendation :
The MUVW proposal (documents in group 3) should address this issue and
propose standards with interfaces.
Security & User Authentication
It is necessary to limit areas of MUVW to users, costing models require
that all users are identified, and it is required that users cannot destroy
other users' worlds.
Living Worlds proposes zones where scripts can be attached at the boundary
to enforce security checks on entrance, but no procedures for this are included
at present. No general user identification model is proposed. Object destruction
is not supported in VRML, so it is not a problem here.
Recommendation :
The MUVW proposal (documents in group 3) should address this issue and
propose standards with interfaces.
Device Drivers and Rendering Hardware
All current browsers support non-immersive MUVW assuming desktop use.
To extend a browser to a new display device, to add new input devices (e.g.
gloves, game controls etc.) or specifying the parameters of the output device
in order to tune the presentation requires getting inside the browser. No
browser currently publishes its API to support this. The Liquid Reality
browser is issued as Java bytecode so it is possible to decompile this,
edit it and then recompile it, but this would be a breach of the license
and is in any case hardly an answer to the problem.
Recommendation :
Browsers publish API's to support the change in I/O device and properties.
Services
Services such as :
Avatar, Pointers, Whiteboard, link-list, DB I/F, Search, Sort, Security
could be provided by server or browser. If they are to be supported by
browsers to improve efficiency then we need to be able to add to them rather
than limiting them to browser supplied services. For both server and browser
then we need the API to :
Recommendation :
The MUVW proposal (documents in group 3) should address this issue and
propose standards with interfaces. Browsers and Servers should publish API's
to support services.
Avatars
The avatar proposal appears to support one avatar per browser in order
to overcome portability problems - this is not the general solution to this
problem.
It should be possible to present different avatars in different worlds
(e.g. one for flight simulation, another for business meetings, etc.) which
does not appear possible in the proposal. There are potential problems associated
with introducing multiple avatars of the same person into a single world
and managing the control of these.
There is no guidance in the Universal Avatar proposal as to embodiment
as avatars for different tasks.
Recommendation :
The Universal Avatar proposal (documents in group 4) should address this
issue and propose standards with interfaces.
Portability
The major problem with using VRML2 MUVWs today is the lack of consistency
in the browsers. MUVWs only run in the browser for which they were written.
VRML1 worlds run in all VRML1 browsers, so the worlds are portable, but
until there is more portability resulting from standardisation, VRML2 MUVWs
are too much tied to the browser, so we expect a browser war until somebody
produces a browser which is available on all platforms that can break the
market.
The problems of Java versus JavaScript versus Authoring Interface conformance
to different normative appendices were mentioned above. Similarly, the issues
of placing functionality in the browser versus the MUVW itself. Different
server structures are mentioned under the architecture heading.
Recommendation :
Conformance to standards for VRML2 browsers, servers, MUVW protocols
is required to enable portability of MUVWs.
This group was chaired by Klaus Kansy, GMD.
Is VRML a Visualization Tool?
The authors of VRML claim that it can be used for visualization. At the
workshop, examples were seen from the University of Leeds and British Telecom
which use VRML in visualization applications. VRML was seen to be useful
for some kinds of visualization, but it does not address or solve many problems.
Advanced visualization needs modelling power. It is not sufficient to
transfer low level data and simple scripts but compact descriptions at a
high conceptual level and powerful operations at that level are required.
The description of the data to be visualized may take the form of a set
of values over a regular or irregular grid, or may be expressed analytically,
for example, by a set of differential equations. Descriptions at this level
are beyond the scope of VRML. Throughout the meeting there was the constant
reminder that one of the design goals for VRML was that it must run on a
PC.
Visualizations often involve large volumes of data. Medical imaging applications,
for example, frequently involve image sizes in excess of 10 Mbytes. There
is a need for some form of lazy down-loading in VRML, so that data are only
requested when they are needed, for example, depending on the user's viewing
direction. This is a non-trivial problem, which is not adequately addressed
by level of detail. There is a need for both server and browser intelligence
in order to decide what needs to be down-loaded and when.
A Reference Model for Visualization
In his introductory talk, Jason Wood, University of Leeds, had introduced
the following reference model for the visualization pipeline:
| data | --------- | filtering | ---------- | mapping | ---------- | rendering | ---------- | image |
This visualization reference model was discussed in detail. The filter
process selects and transforms application data. The map process maps the
data to be visualized onto visualizable elements and render generates the
image to be viewed. Although there were discussions about the limitations
of this model, it was felt overall that it is helpful and assisted in structuring
some of the discussion.
Where is VRML located in the pipeline in this reference model? It was
felt that VRML belongs between the mapping and rendering processes. The
VRML representation contains the data the browser needs for rendering this
VRML world. Views of the visualization from different view points can be
computed by the renderer, though in some circumstances this may require
regeneration of the model by the application. Consider a mesh containing
pressure data at points on the mesh. To compute the pressure at intermediate
points requires interpolation of the data. Suppose pressure values are mapped
on to colour values. A renderer displaying this image without reference
to the data will compute colour values at intermediate points on the grid
by interpolating in colour space, rather than interpolating in data space
and performing the data to colour mapping. Such different interpolation
schemes can generate very different results.
Limitations of VRML
It is difficult to build menus into a VRML scene. Are they part of the
3D world? Adding annotations or colour scales is also difficult. VRML does
not currently allow multiple views in the same window. Adding this functionality
would start to address these concerns.
Solid Modelling
The group also looked at the needs of solid modelling, which turn out
to be somewhat similar to the needs of visualization. Model description,
interaction and lighting are key concerns. As in the case of visualization,
there are examples where it is necessary to go back up the pipeline from
the viewer to the publisher in order to carry out certain operations.
Solid Modelling
Scripting was hotly discussed. The by now standard answer "scripting
solves it" was seen to be very unsatisfactory. The problem is that
scripting is very important and hence ought to be a part of VRML, yet support
for scripting by browsers is optional. Scripting ought to have a more official
status.
Conclusions
Some conclusions were reached about missing functionality needed to make
VRML a useful tool for visualization tasks.
The closing plenary session, after receiving reports from the Working
Groups discussed the recommendations that should be made to ERCIM, through
the ERCIM Executive Committee. VRML is a development of importance to many
of the ERCIM institutes and a development that ERCIM should seek to influence
through its own offices as well as through those of its own member institutes.
| Boyd | David | RAL, UK |
| Clark | Adrian | University of Essex, UK |
| Collins | Lewis | British Telecom, UK |
| Crossley | Martin | British Telecom, UK |
| Drumm | Ian | University of Manchester, UK |
| Duce | David | RAL, UK |
| Ducrot | André | INRIA, France |
| Francis | Alan | Page Description Ltd, UK |
| Gallop | Julian | RAL, UK |
| Herman | Ivan | CWI, Netherlands |
| Hopgood | Bob | RAL, UK |
| Jeffrey | Andy | University of Manchester, UK |
| Joan-Arinyo | Robert | UPC, Spain |
| Kansy | Klaus | GMD, Germany |
| Kennaway | Richard | University of East Anglia, UK |
| Lovegrove | Stuart | University of Leeds, UK |
| Martinho | Carlos | INESC, Portugal |
| Mueller | Markus | AED, Germany |
| Rist | Thomas | DFKI, Germany |
| Sastry | Lakshmi | RAL, UK |
| Solano | Lluis | UPC, Spain |
| Steed | Anthony | University College London, UK |
| Wilson | Michael | RAL, UK |
| Wood | Jason | University of Leeds, UK |
This report is also available as:
gziped
PostScript file (use the "load to disc" option)
PDF
file (For PDF files, a
free viewer (Acrobat Reader) is available from Adobe Systems.
