Architectural Design CVE

Independent Study Report: Collaborative Architectural Design Environment (CADE)

Thomas Vollaro - School of Information MSI

Initial Proposal | Project Log | Demo Reel Story Boards

PLEASE NOTE: The interactive vignettes below require a VRML plugin.

Introduction

The architecture, engineering, and construction (AEC) industry is lagging behind industrial design and aerospace with the use of synchronous distance collaboration tools. These tools are becoming a necessity as firms become globalized and air travel remains expensive and potentially dangerous. For this independent study, I set out to design and prototype a Collaborative Architectural Design Environment (CADE). The intent of this prototype was to explore some of the issues involved with real-time collaborative design over the internet. This was not intended to be a full-blown 3D modeling application. To that end, I purposefully used a simple metaphor of Froebel Blocks for the user interface. Froebel Blocks are used to teach children spatial concepts and are also used by architects to develop early design ideas. With this prototype, I explored the possibilities and limitations of this type of application. I conclude with lessons learned and directions for future work.

Design Process

I began by reviewing the literature on collaborative virtual environments (CVE) and computer-supported cooperative work (CSCW). I also look at some popular 3D modeling packages such as 3D Studio MAX and FormZ for interface standards. I was trying to distill the simplest possible shapes and modifiers to apply to the Froebel Block metaphor. This simplicity allowed me to develop a working prototype within a limited timeframe that could be tested with real users. I then developed a list of required features (Fig. 1) and created some paper prototypes (Fig. 2). The design process ran through a few iterations, as will be shown below, but this basic idea was maintained.

Create floor plate and walls Create columns and windows Modify dimensions on all features Modify solid colors and transparency Save file to VRML format Switch between orthogonal views Collaboration features Type text back and forth Voice communication Annotate design	expand image	expand image
Figure 1 - Initial Requirements List	Figure 2- Paper Prototypes of initial design idea

Technical Details

The next step was deciding on a technical platform. I decided on VRML and Javascript because it would afford me all of the necessary primitives and scripting capabilities. The ability to run within a standard Web browser with a plugin was also an advantage. However, VRML has no inherent multi-user capabilities. I was forced to look for existing solutions, since writing the actual code for a multi-user server was well beyond the scope of this project. I found well developed multi-user VRML servers from Blaxxun and Parallel Graphics, but both were prohibitively expensive. I also located two open-source servers written in Java, VNet and Deepmatrix. While both had been abandoned in 2000 after about a year of intense development, the software was still available. I chose Deepmatrix since it was easier to install and had better documentation. The Deepmatrix Java-based client-server model is quite simple. The VRML file is embedded in a browser applet and all communication is handled with the VRML External Authoring Interface (EAI) (Fig. 3). The VRML file must contain a custom node for each routable event type based on PROTOS supplied with the program. Any action event within the world must be routed to one of these custom nodes. The server then "listens" for these routed events and passes them on to any other client that is concurrently logged into the server (Fig. 4). The incomplete status of the software forced some limitations, mainly that the client will only run in Windows, using Internet Explorer, with the Microsoft Java Virtual Machine installed.

expand image | view VRML
Figure 3 - An early working prototype	Figure 4 - The Deepmatrix Routing Model

Finalizing The Design

After successfully loading the server and testing it on my early prototype (Fig. 3), I decided that the modifier menu across the bottom was too clunky. I did not think that users would make the connection between the menu and the objects themselves. Also, the X, Y, Z labeling does not map well to the potential users' mental model. I decided to rethink the modifier widgets and place them on the objects themselves. This follows current standards in 3D modeling and provides the user with immediate feedback of the modification (Fig. 5). I then added a grid to the floor plane to make it easier for users to locate themselves and objects within the space. I also added a "Load File" button that simulates the loading of an external file. This allows users to navigate through a finished space. I also added two human avatars to the system since the existing ones were inadequate. They are currently floating heads with no body. The head rotates with the user so others can see what they are currently looking at (Fig. 6). Future versions will include full-body avatars with gestures such as pointing (the VRML link supplied below does not include avatars or the client applet).

Current Functions

The following is a list of functions that are currently available in the system.

1. Create Object: A limited amount of basic forms can be created, including cube, column, and dome.
2. Select Object: An object is selected by clicking directly on it. The color changes to a semi-transparent blue. The transparency is helpful in seeing other objects and avatars that may have been occluded by the object.
3. Scale: Once selected, the object can be modified in four ways. Scale allows the user to enlarge or shrink the object across the three individual dimensions. Future versions will allow for global scaling.
4. Rotate: A VRML sphere sensor allows the object to be rotated in any direction. A possible enhancement would be to constrain the rotations around the three individual axes.
5. Move: An object can be moved in either the XZ (Flat) or Y (up-down) directions.
6. Delete: An object can be removed from the scene.
7. Load File: Currently this simulates the loading of a file by enabling a Switch node that displays a static model pre-loaded into the scene. This allows users to navigate through and add to an existing model. This is intended to show how users could load and export geometry created in external applications.
8. Select Avatar: I added two avatars, one male and one female, to the Deepmatrix client. The existing avatars were inadequate for the purposes of this project.
9. Navigate: This is handled by the VRML browser.
10. Collaboration: The Deepmatrix client provides a simple text chat feature for communicating. A possible enhancement would be to add voice chat feature, possibly by using an external application.

There is no explicit turn taking or object locking; each user can create and modify objects simultaneously. Also, each user can select and modify another user's objects. Future versions will include an "ownership" feature which will allow objects to be locked unless they are specifically selected to be shared.

User Testing

I ran some ad hoc user tests on the final version of the system. The following is an initial list of usability issues to address for future versions

- The "Disconnect" button on the applet is too large and was mistaken for the chat "send".
- The VRML controls are difficult for novices: This is a well known phenomenon. One way to address it is to create custom controls using VRML nodes.
- The first person perspective makes it difficult to see if objects are touching: The introduction of standard orthogonal views would help this. Also, maybe add snapping controls.
- The menu got occluded when the demo file was loaded: Ultimately, it would be better to have the shape and modifier menu as part of the applet.
- Finding others can be difficult: Using landmarks and also orthogonal "plan/section" views would address this.
- Object ownership and identification: It is unclear who created which object and who is currently performing a modification. The first issue could be solved by adding a roll-over showing who is the "owner" of the object. The latter could be solved by adding the user name to the cursor while a modification is being performed (as with the Microsoft NetMeeting conferencing application).

The following are three sample videos from the user test (Quicktime required):

Basic object creation (3.5 MB / 1 min 54 sec)	Basic object creation (3.5 MB / 1 min 29 sec)	Navigating and modifying an existing model (6.4 MB / 2 min 37 sec)

Future Work and Directions

The current version of CADE represents a small move towards synchronous collaborative environments for architectural design. However, much work remains to be done before this type of application could be used in a real-world working environment.

Short Term Goals
- First, more structured user tests need to be done to determine areas and features that are the most problematic.
- Create full-body avatars that can gesture.
- Allow multiple objects to be moved and modified as a group.
- Move the menu to the applet.
- Re-write the applet Java code so it is supported by the Sun JVM.

There are many possible uses for this type of application, a few are listed below.

Long Term Goals and Possible Uses
- A teaching tool for architectural students. They can inhabit and modify famous historical designs.
- A front-end to a knowledgebase of architectural elements (see X3D and aecXML)
- Collaborative online community building: As MUDs become more graphic in nature, this type of system could be used to collaboratively build rooms and spaces within a MUD.
- Add advanced features such as NURBS and genetic algorithms.
- Port to advanced hardware like CAVE for full-scale immersion.
- Interface with physical objects like blocks that are "aware" of the moves and modifications.

copyright © Thomas Vollaro 2003