Powered by
JSPWiki v2.8.2
g2gp 17-01-2009
View PDF

Creating and Using Virtual Reality: a Guide for the Arts and Humanities #

Virtual Reality Case Study Library #

Case Study 8: Building Babel II#

Rachael Beach


This paper documents an experimental workshop that took place over three days in Sept 1998 at Coventry School of Art and Design (Beach and Birtles 1999). The workshop was an exploration of the issues surrounding the construction and use of CVEs by the art and design community, though our conclusions are relevant to the use of CVEs in all disciplines.

Building Babel II developed in response to our experiences of teaching VRML and to the problems of content creation and collaboration we perceived CVEs to have. This paper documents our attempts to solve these problems by integrating existing CVE technologies with art and design working practice.


As a group we had previously undertaken some research into currently available collaborative multi-user spaces. In most cases we found that technologies such as Active Worlds and Superscape offered highly optimised and efficient 3-D, collaborative representations of reality and, in the case of Active Worlds in particular, some facility to alter these representations. It soon became clear to us, however, that for the art and design community such preconceptions of reality imposed an unacceptable limitation on creativity. Whilst we were under no illusion that the CVE had been implemented for virtual ‘homesteading’ and not for collaborative building of alternative realities by artists and designers, nonetheless we felt that these CVEs held great potential for meaningful collaboration if only we could provide the user with the ability to create their own objects and worlds. We also perceived that, in our experience, meaningful collaboration was not actually easy to achieve through the interfaces provided in existing CVEs, and that additional support would be required for our artists and designers, some of whom had little or no working knowledge of VRML when they put forward a working proposal to us.

Having considered these problems, we felt that this meaningful collaboration was best achieved by the use of existing CVE technology integrated into certain aspects of art and design practice. So we decided to adapt existing CVE technologies and integrate them into a workshop in which participants worked collaboratively in both real and virtual spaces that mimicked environments that they would already be familiar with. This would, we surmised, provide the support for participants which we felt they needed to deal with these technologies.

VRML and the CVE server

In terms of existing technology we made the decision to use a VRML-based CVE. From a technical perspective we chose VRML for its adaptability, stability, specification and the wide variety of resource material available. More importantly, however, it has been our experience that VRML appeals to artists and designers, because it can be manipulated outside of its imagined use to describe abstract concepts, forms and behaviours.

We considered Vnet, Blaxxun and Community Place as VRML CVE servers. Vnet initially seemed the ideal solution to our needs, allowing us to bring together both Macintosh and PC users. However Vnet requires a level of understanding of VRML and Java that we felt would shift the focus of the workshop to that of overcoming technical issues rather than of creating environments. We found that Sony's Community Place was simply lacking in support and developer information and so we settled on the Blaxxun client and server pair. Despite its complex interface involving a series of HTML frames and embedded files, Blaxxun offered a stable server which would allow participants to upload a standard VRML world which could immediately be shared. We did, however, sacrifice some stability and functionality, such as the facility to alter the environment while present in it, as is possible in Active Worlds. In addition Blaxxun has a wide selection of support material and examples available for the server.

Security and trust

By deciding to provide a high level of control for the participants, i.e. access to the server, we incurred the security risk of providing access to configuration files and scripts. With this amount of access it is a relatively simple task to halt the server. Our choice though was to trust that participants would not wish to jeopardise their work by making untried, frivolous or malicious changes. Anyone visiting the experiment from outside the working group was not given permission to write files.

Our trust in the participants and their trust in us was a fundamental consideration when planning the workshop. Since the workshop was intended to investigate collaboration, we conceived of this collaboration on two levels, both the 'real and 'virtual'. CVEs are generally investigated from the point of view of remote working and so collaboration in that sense is truly virtual, but we believed that our participants would benefit from meeting each other and from meeting us. We hoped that providing this facility would encourage meaningful dialogue between participants and any trust and rapport that they formed would be transferred into the 'virtual' world. This scenario would also help provide support mechanisms for those who were less sure of VRML.

The real space

Figure 24: The real space

We therefore placed the participants in a 'real' space that they would feel familiar with, an approximation of an art and design studio. A clay workshop was commandeered and cleared and the space broken up with dividing boards and desks forming a variety of re-arrangeable niches for computers and people. We hoped that the inherent protocols of what space was private and what was public in this 'real' space would be transferred to the 'virtual' space.

Layout of the virtual world

To provide continuity we decided that the virtual environment should reflect the real and that we would like participants to be able to enter a global public world and then proceed into their own or another's private space. We wished participants to be able to enter their space by moving into the proximity of some kind of 3-D representation of their individual space, rather like moving around the real studio and then entering the divisions of space that belonged to themselves or others.

Workspaces file structure

Figure 25: Workspaces file structure

Whilst the participants were actually in one room limited by walls, in virtual space the doorways to other spaces could be anywhere, the only restrictions being those of navigation. At this point the real and the virtual began to diverge. We found that in terms of navigation the simplest arrangement of the 'gateways' was to place the 3-D icons at ground level, in a line immediately in front of the viewer as they entered the space. The gateways themselves were originally intended to be a reduced version of each individual's space, so reflecting the conceptual basis of the whole structure. It became apparent during the workshop that people were creating far larger and complex worlds than we had anticipated so this facility was altered on the second day. A separate file was created in which participants could place a small representation of their space.

When constructing the virtual environment we tried to bear in mind the fundamental point that the development and installation of each participant's idea should be as simple and as quick as possible, bearing in mind their differing skills and experience. Considering this at the most basic level, using the CVE required that each user be able to:

  • create their world
  • upload their world file
  • view the world.

Our solution was a layered environment which we tried to keep as simple as possible. On the desktop, participants were provided with a text editor and various VRML builders such as Spazz 3D and Cosmo Worlds in order that they had as wide a choice as possible to create their world. Once the participant had constructed a VRML world they were then faced with uploading their file. They did this by naming their file as the default world and uploading it via a provided CGI script. This file space mimicked the real world as their folders were contained within a global directory named Babel. Once uploaded the participant could view their creation in the Blaxxun client.

Screenshot of the Building Babel II interface

Figure 26: Screenshot of the Building Babel II interface

Although their worlds would be three-dimensional, because of the current state of web technologies, the nature of support materials and the differing skills and familiarity of the people involved, the Building Babel interface was predominantly two-dimensional. Accompanying each 3-D working space and the main Babel environment, in an adjacent frame, we provided a set of files with examples, information about Babel and construction information. The graphical layout of the 2-D files was kept as simple as possible and a black background was chosen so that it would not visually dominate the interface. It was anticipated that towards the end of the workshop, or at some point following the workshop, individual participants would replace the construction information with a file, perhaps describing themselves and their VRML world, and a template was provided for this.

The Event

Day one was a very tiring day and explanation of the technology itself took up much of the time. Participants arrived mid-morning and were given a general introduction to the tools and the interface that they would be working with. We considered that it was very important for the participants to begin building their VRML as quickly as possible and so they were encouraged to make even the simplest piece of geometry and upload it to the space they had chosen.

Choosing a space had no guidelines attached in either the 'real' or the 'virtual' environment. In both more spaces were provided than were actually required, so that the individual did not feel forced into collaboration unless they chose it.

By day two participants began to understand the limits and possibilities of the virtual spaces and software and gained some confidence in the implementation of their ideas. Those with less experience tended to construct less complex ideas and to stay away from complex scripting. They tended to work in an organic manner responding to the tools that they were using rather than implementing a fixed idea.

At the end of day two we gathered to review the progress made. It soon became clear that, whether scripting or not, some of the participants did not have an understanding of the difference between a collaborative and a stand-alone VRML world or, if they did, they did not create a work which took advantage of the unique aspects of a CVE, namely shared events. As the server dealt with the addition and subtraction of avatars into this space it was assumed by many of the group that all events would be shared.

By day three participants were tired and as they began to implement the more complex elements of their work they hit problems. It was really only at this point that participants began to try to add events to their work. We had underestimated the level of technical support which would be needed to deal with this, even for such a small group. Although most individuals were by now comfortable with creating geometry, the complexities of scripting and passing events meant that much of the support groups' time was spent answering what we had previously considered to be relatively simple questions.

To compound this, technical problems began to occur as the server struggled updating work, and as a result of caching problems on their browsers, participants became confused by what they were looking at.

The event ended on a high, however, with participants all gathering to look at the work that had been created. Slowly, shouting around the room stopped and typing in the chat box started as people navigated around. At this point the extent of the problems of inline files became clear as the Babel environment became an unintended conglomerate of all the worlds, a kind of enforced virtual collaboration.


In conclusion it is possible to say that we experienced some success with our workshop and, for the most part, the existing technology was the most disappointing element, although we recognised that we were pushing it to its limits. This is not to say that our planning and implementation of the workshop was impeccable, as some aspects undoubtedly will be changed in the future.

In terms of success we felt that the main premise, that we should integrate the real and the virtual in order to facilitate collaboration, worked very well and it is obvious that bringing people together physically was of major benefit to the process. Participants developed an understanding and awareness of the others present and had the chance to associate a real person with a name, piece of geometry and a communication style.