intelligent virtual environments: a new approach to ...

INTELLIGENT VIRTUAL ENVIRONMENTS: A NEW APPROACH TO INTERACTIVELY SOLVE SPATIAL CONFIGURATION PROBLEMS

A thesis submitted to the University of Teesside for the degree of Doctor of Philosophy

April 2003

By Carlos Calderon

Contents Abstract

12

Declaration

14

Copyright

15

Acknowledgements

16

1 Introduction 1.1 Background . . . . . . . . . 1.2 Motivation . . . . . . . . . . 1.3 Objective and research goals 1.4 Thesis organisation . . . . .

17 17 18 19 20

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

2 Spatial Configuration Problems in Design 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Spatial configuration problems . . . . . . . . . . . . . . . . . . 2.2.1 Examples of spatial configuration problems . . . . . . . 2.3 The design process in the interactive resolution of spatial configuration problems . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Application domain: the briefing stage in building design . . . 2.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Characterisation of VR systems 3.1 Introduction . . . . . . . . . . . . . . . 3.2 A Virtual Reality (VR) system . . . . 3.3 Evolution in VR . . . . . . . . . . . . . 3.4 Types of VR systems and performance 3.5 From VR to interactive design tools . . 2

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . .

22 . 22 . 22 . 23 . 24 . 25 . 27

. . . . .

28 28 28 29 30 32

3.6

3.7 3.8 3.9

Virtual Reality systems in the AEC Industry . . 3.6.1 Current practice . . . . . . . . . . . . . 3.6.1.1 Practical modelling approaches 3.6.2 Research projects . . . . . . . . . . . . . Characterisation of VR systems in design . . . . Discussion . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . .

4 Experimental study of VR in design 4.1 Introduction . . . . . . . . . . . . . . . . 4.2 Objective . . . . . . . . . . . . . . . . . 4.3 Method . . . . . . . . . . . . . . . . . . 4.3.1 Background: related experiments 4.3.2 Experiment design . . . . . . . . 4.3.2.1 Tasks . . . . . . . . . . 4.3.3 Participants . . . . . . . . . . . . 4.3.4 Materials . . . . . . . . . . . . . 4.3.4.1 Scenario . . . . . . . . . 4.3.5 Procedure . . . . . . . . . . . . . 4.3.6 Data collection . . . . . . . . . . 4.4 Data analysis . . . . . . . . . . . . . . . 4.4.1 Response variables . . . . . . . . 4.4.2 Explanatory variables . . . . . . . 4.4.3 Statistical analysis . . . . . . . . 4.5 Results . . . . . . . . . . . . . . . . . . . 4.6 Experimental considerations . . . . . . . 4.7 Discussion . . . . . . . . . . . . . . . . . 4.7.1 VR in design . . . . . . . . . . . 4.8 New directions . . . . . . . . . . . . . . 4.9 Summary . . . . . . . . . . . . . . . . . 5 Proposed Framework 5.1 Introduction . . . . . . . . . . . 5.2 Intelligent Virtual Environments 5.3 Fully interactive environments . 5.4 Related work . . . . . . . . . . 3

. . . . . (IVEs) . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . .

33 33 34 35 43 45 45

. . . . . . . . . . . . . . . . . . . . .

46 46 46 47 47 49 51 54 54 54 56 57 58 58 60 60 63 64 65 65 69 69

. . . .

70 70 70 71 72

5.4.1

5.5

5.6

5.7

Previous approaches to virtual design . . . . . . . . . . . 5.4.1.1 Constraint-based approaches . . . . . . . . . . 5.4.2 Examples of IVEs . . . . . . . . . . . . . . . . . . . . . . Technical aspects . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.0.1 Knowledge representation and formalism . . . . 5.5.0.2 Virtual Reality performance requirements . . . IVEs for spatial configuration problems . . . . . . . . . . . . . . 5.6.1 Knowledge acquisition: building design requirements . . 5.6.1.1 Generators . . . . . . . . . . . . . . . . . . . . 5.6.1.2 Characterisation of building design requirements 5.6.2 Constraint satisfaction as representation for spatial configuration problems . . . . . . . . . . . . . . . . . . . . . 5.6.3 Constraint Programming (CP) as a framework . . . . . . 5.6.3.1 Constraint programming in industrial applications . . . . . . . . . . . . . . . . . . . . . . . . 5.6.4 Solving the problem with Constraint Logic Programming (CLP) . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.4.1 Declarative formalism . . . . . . . . . . . . . . 5.6.4.2 Finite Domains (FD) as a semantic structure . 5.6.4.3 Interactivity . . . . . . . . . . . . . . . . . . . . 5.6.4.4 CLP(FD) implementations . . . . . . . . . . . . 5.6.4.5 Problem-solving mechanisms . . . . . . . . . . 5.6.5 Constraints as a form of representation of building design requirements . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 Implementation 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 An application: an intelligent configuration system for interior design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Technology baseline: integration of planning and visualisation 6.3.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 6.3.2 Interactive visualisation engine . . . . . . . . . . . . . 6.3.2.1 Rendering engine and subsystems . . . . . . . 6.3.3 Constraint solving mechanisms . . . . . . . . . . . . . 6.3.3.1 Arc-consistency . . . . . . . . . . . . . . . . . 4

72 74 76 76 77 78 80 80 81 81 84 87 89 90 90 91 92 93 94 97 99

100 . 100 . . . . . . .

100 102 102 103 103 104 106

6.3.3.2 Backtracking . . . . . . . . . . . . 6.4 Visual space . . . . . . . . . . . . . . . . . . . . . . 6.4.1 Content . . . . . . . . . . . . . . . . . . . . 6.4.1.1 Actors & objects . . . . . . . . . . 6.4.1.2 Geometry . . . . . . . . . . . . . . 6.4.2 Dynamics . . . . . . . . . . . . . . . . . . . 6.4.3 Interface . . . . . . . . . . . . . . . . . . . . 6.4.3.1 Interaction modules . . . . . . . . 6.4.4 Virtual environment development . . . . . . 6.5 Representation of the search space . . . . . . . . . . 6.6 Knowledge Acquisition . . . . . . . . . . . . . . . . 6.6.1 Design requirements expressed in CLP(FD) 6.6.1.1 Topological description . . . . . . . 6.6.1.2 Local constraints . . . . . . . . . . 6.6.1.3 Global constraints . . . . . . . . . 6.6.1.4 Primitive constraints . . . . . . . . 6.7 Interaction . . . . . . . . . . . . . . . . . . . . . . . 6.7.1 Overview . . . . . . . . . . . . . . . . . . . 6.7.2 System architecture . . . . . . . . . . . . . . 6.7.2.1 Communication modules . . . . . . 6.7.3 The interaction model . . . . . . . . . . . . 6.7.4 The solver . . . . . . . . . . . . . . . . . . . 6.8 Summary . . . . . . . . . . . . . . . . . . . . . . . 7 Example Results 7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 7.2 A sub-configuration . . . . . . . . . . . . . . . . . . 7.2.1 Problem representation . . . . . . . . . . . . 7.2.2 A proposed solution by the system . . . . . 7.2.3 Exploration and interaction . . . . . . . . . 7.2.4 Reactive environment . . . . . . . . . . . . . 7.2.4.1 The solver’s resolution mechanisms 7.2.5 Exploration of design alternatives . . . . . . 7.2.5.1 Intelligent backtracking . . . . . . 7.3 Full configuration . . . . . . . . . . . . . . . . . . . 7.3.1 Problem representation . . . . . . . . . . . . 5

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

106 107 107 107 108 110 111 111 112 113 115 115 117 118 120 122 126 126 126 128 128 130 134

. . . . . . . . . . .

135 . 135 . 135 . 136 . 137 . 138 . 140 . 142 . 148 . 148 . 151 . 152

7.4

7.3.2 Sample run . . . . . . . 7.3.3 Reaction time: reactivity 7.3.4 Heuristics . . . . . . . . Summary . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

8 Conclusions and Future Work 8.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 8.3 Future work and directions . . . . . . . . . . . . . . . . 8.3.1 Explanatory tools . . . . . . . . . . . . . . . . . 8.3.2 User-friendly exploration of alternative solutions 8.3.3 Increase complexity of the interaction loop . . . 8.3.4 Automation of the modelling process . . . . . . 8.4 Concluding remarks . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . .

. . . . . . . .

167 . 167 . 169 . 172 . 172 . 172 . 173 . 173 . 174

References

154 161 162 166

175

A Experimental procedure A.1 Detailed instructions for the participants A.2 Tasks . . . . . . . . . . . . . . . . . . . . A.2.1 Warm-up tasks . . . . . . . . . . A.2.2 Experimental tasks . . . . . . . . B CLP Solver: source code

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

189 . 189 . 193 . 193 . 193 195

6

List of Tables 3.1 3.2 3.3

VR research in the pre-construction phase. . . . . . . . . . . . 39 VR research in the construction phase. . . . . . . . . . . . . . . 41 VR research in construction. . . . . . . . . . . . . . . . . . . . 42

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10

Appreciation tasks. . . . . . . . . . . . . . . . . . . . . . . . Problem-solving tasks. . . . . . . . . . . . . . . . . . . . . . . Pre-processing data: transcription, segmentation and coding. Response variables. . . . . . . . . . . . . . . . . . . . . . . . Explanatory variables. . . . . . . . . . . . . . . . . . . . . . . Descriptive statistics for response variable QL. . . . . . . . . Descriptive statistics for explanatory variables. . . . . . . . . Descriptive statistics for response variable SL. . . . . . . . . . Questionnaire: advantages of a VR model. . . . . . . . . . . . Questionnaire: VR model is an accurate representation of the building. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

53 53 58 59 60 61 62 63 66

. 66

5.1 5.2 5.3

Knowledge and formalisms representation requirements . . . . . 78 VR technical requirements . . . . . . . . . . . . . . . . . . . . . 80 Constraint Properties . . . . . . . . . . . . . . . . . . . . . . . . 89

6.1 6.2 6.3 6.4 6.5 6.6

Unreal units. . . . . . . FD Variables size . . . . Local Constraints . . . Global Constraints . . . Descriptive and primitive Sequential distance. . .

7.1 7.2

First run: a proposed solution by the system. . . . . . . . . . . 138 Reaction time. . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

. . . . . . . . . . . . . . . . levels. . . . .

7

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

109 116 119 121 124 125

7.3 7.4 7.5 7.6 7.7 7.8

Heath and safety regulations expressed in local constraints. . Reaction time in full example. . . . . . . . . . . . . . . . . . Solver’s resolution time . . . . . . . . . . . . . . . . . . . . . Solver’s resolution time using the heuristic first-fail. . . . . . Solver’s resolution time using random variable instantiation and random value generation. . . . . . . . . . . . . . . . . . . . . Solver’s resolution time: mixed approach. . . . . . . . . . . .

8.1

Capabilities of VR systems. . . . . . . . . . . . . . . . . . . . . 168

8

. . . .

153 161 162 163

. 165 . 165

List of Figures 2.1

Relationship between the specification of VR systems requirements and the interactive resolution of spatial configuration problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1 3.2

The AIP cube . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Qualitative performance of different VR systems (modified from Kalawsky [Kal96]) . . . . . . . . . . . . . . . . . . . . . . . . . 32 “Downstream” translation process (adopted from [WT00]) . . . 35 Approaches to the creation of VR models (adopted from [WT00]) 35

3.3 3.4

4.1 4.2 4.3 4.4 4.5

Building layout: ground floor. . . . . . . Experimental methodology. . . . . . . . Experiment set-up: VR system. . . . . Visual Basic application. . . . . . . . . Roof of the lobby area: before and after.

. . . . .

. . . . .

50 52 55 61 67

5.1 5.2 5.3 5.4 5.5 5.6 5.7

. . . . . .

75 82 85 86 88 95

5.8

Approaches for virtual prototyping (adapted from [Lam96a]) . Model of design problems (adapted from [Law97] ) . . . . . . Characterisation of building design requirements . . . . . . . Constraints satisfaction problems . . . . . . . . . . . . . . . . Constraints examples . . . . . . . . . . . . . . . . . . . . . . Arc-consistency techniques. . . . . . . . . . . . . . . . . . . . Tree generated to solve four queens problem (modified from [Kor96]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conceptual levels . . . . . . . . . . . . . . . . . . . . . . . . .

6.1 6.2

The application example. . . . . . . . . . . . . . . . . . . . . . 102 Upper floor and exterior of the developed virtual environment. 104 9

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. 96 . 98

6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 6.13 6.14 6.15 6.16 6.17 6.18 6.19 6.20 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.11 7.12

Upper floor and counter of the developed virtual environment. Movable objects. . . . . . . . . . . . . . . . . . . . . . . . . . Avatars. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The geometry of the VE. . . . . . . . . . . . . . . . . . . . . Greeting action and its result displayed in the HUD. . . . . . The virtual environment “production” process (modified from [ST01]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sequential grid . . . . . . . . . . . . . . . . . . . . . . . . . . Design knowledge. . . . . . . . . . . . . . . . . . . . . . . . . Topological constraints as Prolog clauses and how these are expressed in the virtual environment. . . . . . . . . . . . . . . . Local constraints as a Prolog clause and how this is expressed in the virtual environment. . . . . . . . . . . . . . . . . . . . Global constraints as Prolog clauses and how these are expressed in the virtual environment. . . . . . . . . . . . . . . . . . . . Descriptive and primitive levels. . . . . . . . . . . . . . . . . A primitive constraint: set imposs rect(). . . . . . . . . . . . Defined constraint achieves a more efficient pruning. . . . . . System Architecture. . . . . . . . . . . . . . . . . . . . . . . Unreal event: the user drops an object. . . . . . . . . . . . . Solver stages. . . . . . . . . . . . . . . . . . . . . . . . . . . . Overall interaction model. . . . . . . . . . . . . . . . . . . . . Design knowledge represented in the VE. . . . . . . . . . . . Initial configuration given to the user. . . . . . . . . . . . . . The user seizes the ATM object and explores the VE to reallocate it. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reactive environment. . . . . . . . . . . . . . . . . . . . . . . Solver stages . . . . . . . . . . . . . . . . . . . . . . . . . . . Local and global constraints. . . . . . . . . . . . . . . . . . . Static Domains. . . . . . . . . . . . . . . . . . . . . . . . . . List of FD variables domains after constraint propagation. . . Enumeration. . . . . . . . . . . . . . . . . . . . . . . . . . . . Proposed configuration. . . . . . . . . . . . . . . . . . . . . . Intelligent backtracking: first backtracking. . . . . . . . . . . 10

. . . .

104 107 108 109 111

. 112 . 114 . 117 . 118 . 119 . . . . . . . .

120 122 123 125 128 129 131 133

. 136 . 137 . . . . . . . . . .

138 139 140 142 143 144 145 146 147 148

7.13 Intelligent backtracking: third backtracking. . . . . . . . . . . 7.14 Intelligent backtracking: fourth backtracking. . . . . . . . . . 7.15 Design knowledge express in the VE: movable and non-movable objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.16 Initial configuration proposed to the user. . . . . . . . . . . . 7.17 Exploration of the 3D environment by the user. . . . . . . . . 7.18 Interacting with the underlying knowledge. . . . . . . . . . . 7.19 New object’s location complies with the all constraints. . . . 7.20 Reactive virtual environment. . . . . . . . . . . . . . . . . . . 7.21 Intelligent backtracking. . . . . . . . . . . . . . . . . . . . . . 7.22 Intelligent backtracking: a meaningful configuration. . . . . . 7.23 Initial configuration using first-fail as heuristic. . . . . . . . .

11

. 150 . 151 . . . . . . . . .

152 154 155 156 157 158 159 160 164

Abstract This thesis describes a research investigation into the use of Virtual Reality (VR) to aid the solution of spatial configuration problems. Such problems are present in many domains: manufacturing, telecommunications and so on. They are however, particularly relevant to the Architectural Engineering and Construction (A/E/C) industry. They are of considerable significance in the briefing stage within the building design process and this has been selected as the application domain for this research. The aim of this research was not only to investigate the applicability of conventional VR for spatial configuration problems but also to develop interactive design tools which use VR techniques and can support the interactive resolution of spatial configuration tasks. Following a review of previous research into the use of VR for construction problems, an experimental investigation of the use of “traditional VR” for spatial configuration problems is described and the limitations of this use of VR are identified. In order to overcome these current limitations, a new framework based on Intelligent Virtual Environments to support a new generation of VR systems is proposed. The rationale behind this new approach is the integration of symbolic reasoning techniques into a virtual environment to support interactive problem solving. This is because Intelligent Virtual Environments (IVEs), which integrate AI techniques with real-time 3D environments, can support interactive problem solving, provided the underlying AI techniques can produce solutions within a time frame matching that of the user’s interaction. In these systems, the visual space is directly interfaced to a problem solver, but the implementation of an Intelligent Virtual Environment for the resolution of spatial configuration problems is far from trivial, since the computation of the solution space is often intractable. Therefore, in order to reach a high-level of integration

12

between the visualisation component and the problem solving component, the selected problem solving technique has to be compatible with the nature of user interaction in Virtual Reality (VR) within an interaction model. The development of a new approach to solving this problem is described. This is based on constraint logic programming (CLP), integrated in a realtime 3D graphic environment using an event-based approach as an interaction model. More specifically, the system developed follows an event-based approach in which the user interaction can be converted in real-time into appropriate solver queries that are translated back into automatic reconfigurations of the VE. To demonstrate the system’s behaviour on a full configuration example, interior building design is used as an application example. In this example, the furniture consists of a subset of 14 objects and uses real-world design knowledge in terms of building interior design for an office reception area. The implementation of this approach is described using the proposed example, sample runs are fully described and the search heuristics used to interactively find a solution are discussed. It is concluded that the proposed approach supports the development of interactive design tools which use VR techniques and enables the interactive resolution of spatial configuration problems. The results of this research may therefore have the potential for major developments in the selected application domain. For instance, the approach can be utilised in other applications such as layout configuration, space planning for new buildings and so on.

13

Declaration No portion of the work referred to in this thesis has been submitted in support of an application for another degree or qualification of this or any other university or other institution of learning.

14

Copyright Copyright in text of this thesis rests with Carlos Calderon (the Author). Copies (by any process) either in full, or of extracts, may be made only in accordance with instructions given by the Author. This page must form part of any such copies made. Further copies (by any process) of copies made in accordance with such instructions may not be made without the permission (in writing) of the Author.

15

Acknowledgements I am indebted to Professor Marc Cavazza, my mentor, for his friendship, guidance and support in this investigation. With his enthusiasm, his inspiration, and his great effort to explain things clearly and simply, he guided me into the right direction. Without him, this thesis would not have been possible. I would like to thank my director of studies, Professor Brian Hobbs, for giving me the opportunity of investigating the subject of this thesis, supporting me when I had to deal with difficult situations and helping me to complete this thesis. Postgraduates of the Virtual Systems Laboratory (Altion, Bob, Scott and Arnoud) and the University of Teesside (Steve and Fred) are thanked for numerous stimulating discussions, help with technical problems and general advice; in particular I would like to acknowledge the help of Andrew Fanning for his continuous support and Dr Daniel Diaz for his technical assistance in dealing with the mysteries of GNUProlog. As well, I would like to thank Dr Paul van Schaik for his help with the experimental setup. I am grateful to all my friends from the Virtual Systems Laboratory (VSL) and the University of Teesside, for being the surrogate family during the years I stayed there and for their continued moral support there after. From the staff, Professor Takeo Ojika and Dr Ryugo Kijima are especially thanked for their care and attention whilst I was at VSL. Finally, I am eternally grateful to my parents, Rosario and Carlos, my sister, Raquel, and the woman I love, Elisabeth, for their love, endless patience and encouragement when it was most required. To them I dedicate this thesis.

16

Chapter 1 Introduction 1.1

Background

Spatial configuration tasks can be defined as designing a physical or spatial problem using a set of pre-defined components or component types while taking into account a set of well-defined restrictions on how the components can be combined [Ald02]. Spatial configuration problems are present in many domains: manufactured products (machines, computers, furniture), networks (telecommunication, transportation systems), services (banking, travel), software (Enterprise Resource Planning Sofware, e.g Expandable II) and in the Architectural Engineering and Construction (A/E/C) industry (resource allocation, layout configuration, etc). Construction projects often deal with large amounts of 3D data which involve the resolution of spatial configuration problems in all the different stages of the construction process in different application domains . For instance, in building design, during the initial stages an example of spatial configuration problems would be the layout configuration of, for example, the ground floor. Similar examples of spatial configuration problems can be found in other construction applications such as rban planning (e.g. land allocation), design of construction operations (e.g. resource allocation), etc. Production industries have used computer modelling or virtual prototyping of components for many years where they can afford to invest in the technology because of the large numbers of products. However, the advances in hardware and software technology have enabled virtual modelling to take place to a 17

CHAPTER 1. INTRODUCTION

18

point where it is now possible to model, for instance, a complete building in a standard computer (PC). Therefore, in theory, with every building component modelled in every detail, if there is a problem the model will tell you. It would also be “visually” apparent what the problem is when the model is viewed [Nel99]. Consequently, 3D visualisation has been acknowledged as an “efficient” way of constructing the building before is physically built [OG96] [Nel99] [RR99] [Deb99]. Thus, spatial configuration tasks are present in many construction problems and 3D real-time visualisation technologies such as Virtual Reality (VR) provide the “natural” mechanisms to solve them interactively. Therefore, a virtual representation can well serve to specify the initial spatial configuration problem, visualiase the solution and interactively explore the solution space.

1.2

Motivation

Computer-Aided-Design (CAD) is an important tool for the industry, and the idea of using a virtual representation of a 3D object is nothing new [Kal93]. However, traditional CAD tools are inadequate for supporting interactive design and as a representation medium to convey design solutions to noneconstruction professionals [Lam96b]. For instance, faced with the difficulty of visualizing the spatial configuration in two dimensions, Chrysler and Sverdrup program management decided to developed a new 3D simulation software. They found that by visualizing the equipment layout as realistic 3D shaded images and running a routine in the software that automatically highlights interferences, Sverdrup designers were able to find major design problems that were impossible to see in the 2D design [PH98]. Similarly, in manufacturing once the computer model has been built, a physical model has to be built to confirm the design. A possible solution, to avoid building a physical prototype, is to input the computer model into a Virtual Reality (VR) system where it would be possible to it interact with various components and explore issues of manufacture and servicing [Vin98]. Therefore, VR can extend the domain created by CAD systems by adding value at all stages in the product life. For instance, VR systems could provide rapid prototyping of early concepts; a representation medium for users; reduce the need for detailed physical prototyping, etc.


19

This investigation focuses its attention in the development of interactive design tools which use VR techniques and can support the interactive resolution of spatial configuration tasks. In this research, the briefing stage in the construction process is used as an application domain. The briefing is a highly iterative and evolutionary process which involves regular feedback throughout the project between clients and the project team [CIB97]. This process involves the communication and collection of information (often 3Dimensional) and involves decision-making about the information collected by people of diverse backgrounds and orientation (i.e. client, advisers, project team). In a typical scenario, the design team (architects and engineers) proposes a possible design solution which complies with the design requirements in terms, for instance, of geometrical (such as minimum and maximum distances, etc) and engineering constraints (health and safety regulations, etc). At this stage, the project team is interested in the client or user exploring different what if scenarios in order to achieve a validated design (“frozen”) as quickly as possible, so as to move on to the next phase which is, usually, the production of construction drawings. From the client’s perspective, the problem with a construction project is that the clients are buying a product that cannot be seen until it is completed. Therefore, if the clients can be shown the proposed design for a building using “appropriate visualisation techniques”, the clients should be able to comprehend the end product and confirm that it satisfies their requirements reducing the likelihood of dissatisfaction with the end product [PF02].

1.3

Objective and research goals

The objective of this research is the development of new interactive design tools which use VR techniques and can support the interactive resolution of spatial configuration problems. The following research goals were identified in order to accomplish the above objective: • Study of the design process and its representations.


20

• Characterisation and State-of-the-Art of VR systems that support engineering design 1 . • Experimental evaluation of existing VR technology. • Investigation of new approaches to Virtual Design. • Demonstration the feasibility of a proposed new approach.

1.4

Thesis organisation

This thesis is divided into eight chapters: Chapter 1 introduces the research motivation and describes the methodology followed in the course of this investigation. Chapter 2 introduces the concept of spatial configuration problems and proposes a representation whose purpose is to relate the interactive resolution of spatial configuration problems to the specification of a VR system. The briefing stage in building design is also introduced as the application domain. In Chapter 3 the key features of Virtual Reality (VR) technology which support spatial configuration problems are identified. This chapter also presents a characterisation of VR systems that attempt to support design. This characterisation is used to relate the key features of VR systems to the proposed representation of the construction process. In Chapter 4 the use of “traditional VR” for spatial configuration problems is explored using an experimental approach. The limitations of VR, in its current form, are identified and new directions for a new generation of VR systems based on Intelligent Virtual Environments are proposed. In Chapter 5 a new approach for the use of Virtual Reality in spatial 1

A series of visits, to leading institutions in the field, and workshops complemented the literature review on the State-of-the-art of VR systems: VideoLab, University of La Coruna, Spain (20/12/98). Design Systems Group, University of Eindhoven, Holland (30/8/2000). Virtual Systems Laboratory, University of Gifu, Japan (13/10/1999). VR Techno Plaza and Softopia, Gifu Prefecture, Japan (12/10/1999). Advanced Telecommunications Research Laboratory (ATR), Kyoto, Japan (5/11/2000). Six months stay at Virtual Systems Laboratory, University of Gifu, Japan (1/10/2000 till 1/4/2001). Institute of Technology, Shimizu Corporation, Tokyo, Japan (21/03/2000). Workshop on evaluation techniques for Virtual Environments, IEEE VR 2001, Yokohama, Japan (13/03/2000). Workshop on Versatile Visualisation for building design, University College of London, UK (26/04/1999).


21

configuration problems in building design is proposed: Intelligent Virtual Environments (IVEs). This approach preserves the nature of VR in terms of interactive and active exploration but supports the expression of design knowledge in the VE and the interactive generation of design solutions. The main purpose of Chapter 6 is to demonstrate, using a designed example, that the proposed framework supports the interactive generation of design solutions and therefore, extends the capabilities of “traditional” VR towards fully interactive environments. Chapter 7 provides detailed examples of how the concept of a fully interactive VR system has been implemented. In this case, a reactive environment which automatically reconfigures itself as a consequence of the user interactions and which allows the exploration of alternative design solutions by the user. Consequently demonstrating that, the framework introduced in chapter 5 extends “traditional” VR towards fully interactive environments by introducing the idea of reactive environments which react/adapt to the user interactions while preserving the principles of traditional VR In Chapter 8 discusses how the proposed approach compares with previous work, conclusions are drawn and recommendations are made for future work Finally, in the appendices can be found a detailed description of the experimental protocol used for the study of VR in design (appendix 1) and the source code of the implemented Constraint Logic Programming (CLP) solver (appendix 2).

Chapter 2 Spatial Configuration Problems in Design 2.1

Introduction

This chapter introduces the concept of spatial configuration problems and proposes a representation whose purpose is to relate the interactive resolution of spatial configuration problems to the specification of a VR system (see section 3.7). The briefing stage in building design is used as a case study in the thesis. Hence, the main concepts with regards to the briefing stage are briefly introduced in the last section of this chapter.

2.2

Spatial configuration problems

According to Eastman [Eas72], many problems within the general class called design problems require metric and arrangement considerations. These problems involve the search for feasible or optimal solutions to spatial arrangement problems where performance is a function of distance, adjacencies, combined areas, proportions (e.g distance ratios), and other complex parameters. Such problems may be called spatial configuration problems. Spatial configuration problems are the focus of work by architects, urban designers, engineering designers, and, according to Eastman [Eas72], all others who currently solve problems using orthographic drawings.

22

CHAPTER 2. SPATIAL CONFIGURATION PROBLEMS IN DESIGN 23

2.2.1

Examples of spatial configuration problems

Spatial Configuration Problems include the arrangement of a building floorplan, the spatial arrangement of an electronic circuit, the site planning of a neighborhood, the solving of a jigsaw puzzle or its three-dimensional counterpart, the packing of equipment in a space and so on [Eas72]. Moreover, previous research projects have attempted the development of systems for the automatic resolution of spatial configuration problems in many real-world domains. These domains include: furniture layout [Pfe75], electronic circuit design [Ton88], office layout [Eno91], factory layout, cutting stock [Hen88] and commercial kitchen layout [Hon92]. A particularly well-described example of a spatial configuration problem is furniture or equipment layout . According to Pfefferkon [Pfe75]: ”This design task requires placing objects in a room while satisfying a set of given constraints. The objects for an office might be desks, file cabinets, and bookcases. The objects for a computer room might be a computer, memory modules, and I/O equipment (magnetic tapes, card readers, printers, etc). The constraints would require that physical objects occupy independent regions of space, that maintenance access areas be accessible, and that path, view, and distance constraints can be satisfied. Layout problems of this type are relatively simple, well defined, and characteristic of many design tasks in architecture, engineering, interior design and urban planning, which require manipulating two-dimensional representation of objects to create feasible or optimal solutions to problems with a set of metric and topological spatial constraints.” Pfefferkon [Pfe75] therefore defines the spatial layout problem as consisting of (1) objects such as desks and appliances, and (2) a restricted area such as a room or a parcel of land, and (3) constraints. The objective is to place the required objects in a restricted area whilst satisfying a set of constraints. Some example of constraints, according to Pfefferkon [Pfe75], are the following: • Distance: the distance between the elevator door and the card reader should be less than 20 feet. • Position: the computer should be in the left half of the room.


• Orientation: the desk should face the window. • Adjacency: the table should be next to the terminal’s left side. • Spatial: two pieces of equipment cannot occupy the same space • View: the window should be visible from the door • Path: all area should be accessible from the door Consequently, an example of a spatial configuration problem in design is to determine a spatial configuration of objects according to a set of criteria in an application domain (e.g. interior building design).

2.3

The design process in the interactive resolution of spatial configuration problems

In general, the design process is an interactive process which involves recognition, formulation and satisfaction of the design requirements arising from diverse engineering and management areas [SG92]. For this thesis, with regards to the characterisation of the design process for the interactive resolution of spatial configuration problems, the emphasis is placed on the prototyping aspects of the design cycle and how these relate to the requirements specification for the design of a VR system. Although it can vary from one terminology to another according to Lamounier [Lam96a] and Payne [Pay91], design is a process of concept proposal, concept definition, evaluation and modification at all levels down to the final detail, each level of detail giving information to the next (and in some cases vice versa). Consequently and according to Lamounier [Lam96a] and Payne [Pay91], the design process can be decomposed into the following major stages: design initiation, design development and design evaluation and rework. During the design initiation stage, the concept is drawn from a number of design concepts known to the design team by a combination of design requirements, experience and standard design techniques [Pay91]. According to Lawson [Law97], there are generators of design requirements (e.g. client, legislator, etc) and these requirements have a domain of concern, for instance,


building regulations. Therefore, in order to facilitate the acquisition and encapsulation of design knowledge into the VR system, a characterisation (such as the one proposed by Fleming et al [FF94]) of design requirements ought to be used to transform design requirements into a “suitable” form of design knowledge (see figure 2.1). In the design development stage, once the concept is selected, the designer uses his design methods to interact with design knowledge expressed in his/her design concept by, for example, adjusting the values of input parameters (e.g the spatial coordinates of the virtual environment’s objects which are part of the spatial configuration problem). This is an iterative process until the designer is satisfied with the results. It must be noticed that, in practice, many designs are not optimum because design alternatives cannot be explored during the design cycle[Pay91]. In the design evaluation stage, the proposed design solution should be validated. Ideally, the VR system ought to facilitate the validation process by allowing the evaluation of different design alternatives in order to select the appropriate solution. It is usually easier to define the criteria (e.g input the design knowledge into the VR system) for evaluating and comparing designs than to predict which will give the better solution. Figure 2.1 illustrates how the prototyping aspects of the design cycle for the interactive resolution of spatial configuration problems relate to the requirements specification for the design of a VR system.

2.4

Application domain: the briefing stage in building design

For the purpose of this study, the briefing stage in the construction process is used as an application domain. The definition of briefing used in this investigation is provided by the CoBrITe (Construction Briefing Information Technology) project is used [BA02]. As stated by Bouchlaghem [BA00], the definition is as follows: “The briefing is the process running throughout a construction project by which the requirements of the client and other relevant stakeholders are progressively captured, interpreted, communicated


Figure 2.1: Relationship between the specification of VR systems requirements and the interactive resolution of spatial configuration problems


to the design team and then confirmed (validated).” The definition emphasises the cyclic nature of the briefing activity and undermines the need for the involvement of the project client/users. With regards to the design knowledge, in this stage of the process, the clients/users’ requirements are acquired and interpreted. This study draws on previous investigations which focused on the development of models to characterise (acquire and encapsulate knowledge) building design requirements: Kamara [Kam99a], Fleming et al [FF94] amongst others have addressed this. In particular, for this thesis, the SEED (Software Environment for Support the Early Phases in Building Design) [FF94] has been adopted as a model to capture and translate design requirements into design knowledge. Once the design requirements have been “captured/characterised”, these are communicated to the design team which, in turn, produces a design solution:design cycle. This is an iterative process in which the initial concept/solution is developed base on: the design requirements, similar experiences and standard design techniques. Usually, the concept/solution is redefined by internal (within the team) appraisal until the team is satisfied [Lam96a]. Finally, the solution developed by the design team needs to be validated by the clients and/or users: validation. Current briefing practice tend to be solution-focused. Consequently, the solution proposed by the design team is used to validate the initial requirements of the client and/or user [Kam99a].

2.5

Summary

In this chapter the concept of spatial configuration problems has been introduced and a representation whose purpose is to relate the interactive resolution of spatial configuration problems to the specification of a VR system has been proposed. The emphasis of this characterisation is on the prototyping aspects of the design cycle and how these relate to the requirements for the design of VR systems.

Chapter 3 Characterisation of VR systems 3.1

Introduction

In this chapter, the key features of Virtual Reality (VR) technology which support spatial configuration problems are identified. This chapter also presents a characterisation of VR systems that attempt to support engineering design. This characterisation is used to relate the key features of VR systems to the proposed representation of the construction process (e.g design process). Initially in the chapter, the basic concepts with regards to VR systems are defined and a classification of VR systems is proposed. Both, the basic concepts and classification of VR system, provide the basics for an understanding of the existing State of the Art of visualisation techniques and tools in the design stage.

3.2

A Virtual Reality (VR) system

A Virtual Reality system is a combination of software and hardware components that are capable of generating real-time computer images of a simulated 3D environment that could be navigated and interacted with [Vin98]. In this context, real time means at least 30 frames per second; by navigation is implied the ability to move around and explore features of a 3D scene such as a building; whilst by interaction is understood the ability to select and move objects in a scene, for instance, a table. Furthermore, a VR system has to provide a user with a “first-person” view of the virtual world. A Virtual Environment(VE) is defined as the representation of a computer 28

CHAPTER 3. CHARACTERISATION OF VR SYSTEMS

29

model or database which can be interactively experienced and manipulated by the virtual environment participant [BF95].

3.3

Evolution in VR

There have been several characterisations of VR, depending on where the focus was placed on: simulation, user’s experience, interaction, content, etc. The following definitions of VR are some examples: • Initially, Ivan Suntherland, the VR pioneer, had a clear vision of VR as the ultimate medium [Sun65]: ”A display connected to a digital computer gives us a chance to gain familiarity with concepts not realizable in the physical world. It is a looking glass into a mathematical wonderland (..) There is no reason why the objects displayed by a computer have to follow the ordinary rules of physical reality (...) The ultimate display would, of course, be a room within which the computer can control the existence of matter ” [Sun65]. • In Zeltzer’s AIP cube [Zel92], virtual reality is an unattainable node in which the value of the three components (presence, interaction and autonomy) is unity (see figure 3.1).

Figure 3.1: The AIP cube


30

• Gigante [GJ93] defines/characterises VR in terms of the experience of immersion supported by I/O devices : ”The illusion of participation in a synthetic environment rather than external observation of such an environment. VR relies on three-dimensional (3D), stereoscopic, head-tracked displays, hand/body tracking and binaoural sound. VR is an immersive, multi-sensory experience.” • Similarly, Bryson [BV95] defines VR as follows: ”Virtual Reality is the use of various computer graphics systems in combination with various display and interface devices to provide the effect of immersion in an interactive threedimensional computer-generated environment in which the virtual objects have spatial presence.” However, VR technology has evolved into a variety of forms. For instance, the very recent explosion in the use of desktop VR for scientific research [LJ02] in areas such as story telling [CM02] has been prompted by the advances in computer games technology. The reason being that games engines provide fast realistic simulations coupled with highly interactive and sophisticated graphics running on a standard PC [LJ02]. Another example is the decline in the use of HMDs in favour of immersive displays (e.g CAVE TM ) [JH02].

3.4

Types of VR systems and performance

Most authors’ classification of VR systems is based on the level/sense of immersion provided by the system. Although it can vary from one terminology to another, according to Vince [Vin98], Kalawsky [Kal93] and others ([Per01]) most VR systems fall into three categories: non-immersive (desktop) systems, semi-immersive projection systems and fully-immersive head-mounted display Systems. In the following paragraphs a more detailed definition is given. • Non-immersive (Desktop) Systems: In a desktop system there is only one rendered image, and that is on the computer screen. Therefore, the virtual environment is viewed utilising a standard high-resolution


31

monitor. Interaction with the virtual environments can occur by conventional means such as keywords, mice and trackballs or may be enhanced by using 3D interaction devices such as a SpaceBall TM or a DataGlove TM . • Semi-Immersive Projection Systems: A semi-immersive system will comprise a relatively high performance graphics computing system which can be coupled with: a) a large screen monitor b) a large screen monitor system c) multiple CRT systems. Additionally, stereographics imaging can be achieved using some type of shuttered glasses in synchronisation with the graphics system [BV95]. • Fully immersive Systems: Fully “immersive” VR systems are often equipped with a Head Mounted Display (HMD). This is a helmet or a face mask that holds the visual and auditory displays. The helmet may be free ranging, tethered, or it might be attached to some sort of a boom armature [GJ93]. A recent variation of the immersive systems use multiple large projection displays to create a CAVE TM or room in which the viewer(s) stand. The CAVE (Cave Automatic Virtual Environment) provides the illusion of immersion by projecting stereo images on the walls and floor of a room-sized cube. Several persons wearing lightweight stereo glasses can enter and walk freely inside the CAVE. A head tracking system continuously adjusts the stereo projection to the current position of the leading viewer. A variety of input devices such as joysticks, data gloves, and hand-held wands allow the user to navigate through a virtual environment and to interact with virtual objects [Vin98]. It must be said that these implementations are not regarded as distinct boundaries. For example, it is possible to turn a desktop system into a semiimmersive system by simply adding shutter glasses and the appropriate software, or a fully immersive system by connecting a HMD. Finally with regards to the relation between performance and types of VR systems, Kalawsky [Kal93] explains that “it would be tempting to say that the immersive systems offers a higher degree of virtual presence than the non-immersive system. However, to make a scientific judgment of the degree of immersion it is necessary to define what we mean by immersion or virtual presence”. There is an entire research area devoted to define presence


32

and to determine what factors (the field of view, display resolution, level of physical interaction, etc) influence it. Researchers in this field argue ([She92] [Ste92] [SU93] [WS94] [Zel92] [Sch95]) that if they could define what is meant by virtual presence and actually specify how much immersion is required to undertake a specific task, then we would have a means of identifying what type of virtual reality system is required for a specific task/application. Therefore, in theory, depending on the task or design problem in hand, an increase in performance can be gained by using the right virtual reality system for that specific type of task or design problem. To compensate for the current inability (within the VR community) of making a scientific judgement on the degree of immersion of a VR system, Kalawsky [Kal96] provides a good set of qualitative performance indicators (see figure 3.2) for the selection of a VR system.

Figure 3.2: Qualitative performance of different VR systems (modified from Kalawsky [Kal96])

3.5

From VR to interactive design tools

In the context of thesis, an interactive design tool is a VR system which is capable of generating VEs to be used to support the design process. The main challenges for the development of interactive design tools lie in keeping the user-centred aspects of virtual reality: exploration/navigation and interaction in a 3D real-time computer generated environment. That is, using a firstperson view of the world, the user should be able to move around and explore


33

the virtual environment (e.g a building) whilst interacting with objects in the scene (e.g a desk) [Vin98]. In the section 3.7 of this chapter, a set of requirements for the implementation of VR systems (or interactive design tools) in the design process are defined.

3.6

Virtual Reality systems in the AEC Industry

3.6.1

Current practice

Virtual reality (VR) is used within the construction industry for a variety of reasons: for design applications, for collaborative visualisation and as a tool to improve construction processes[BL96]. However, the current primary use of VR applications is to visualise completed schemes, which are developed using expensive stand alone software packages, and allow walk-throughs [RW01]. That is, VR is mainly used as a visualisation tool with limited interactive capabilities (e.g interactive navigation) as a part of a sales package. For instance, in a typical commercial case the design team commissions a VR model as a marketing tool to show their preliminary design to the corresponding authorities who have the final decision over the project. For example, for the redevelopment of a brown field site in Darlington, Bussey & Armstrong (the Architects) commissioned a VR model of the site featuring both its current state: a contaminated site and the proposed redevelopments: a new a housing state and a park. Consequently, this VR model was used as a promotional material in the very early stages of the project, including a major presentation to Darlington Town Council who ultimately have the power to give the project the go ahead [RW01]. Similarly, Pera International [Hes97], one of the UK’s most advanced VR Centres, carries out a wide range of 3D modelling and visualisation projects to produce simulations of the manufacturing and office buildings and facilities. They are usually supplied with drawings or CAD data of the site to be modelled, and any available information on the equipment to be installed so that the team builds a VR model. Extra detail is added where appropriate by applying textures created from material samples or site photographs. For


34

instance, in the Norcroft Dynamics project (a new manufacturing facility for Norcroft), Norcroft commissioned the factory visualisation from Pera as part of its marketing efforts to persuade major car manufacturers. [Hes97]. Another example is Onuma & Associates [Hes97], an international firm of architects, based in Japan and the USA. They have used 3D modelling as part of the design process for real world construction projects, and have made increasing use of the world wide web for presentations to their clients, and for the interchange of design ideas between their offices. For instance, these ideas have been proved in the project named Webspace (Onuma’s office). In this project, they created a VR model embedded on a website to be used as a means of communication between different parties involved in the project. That is, team members and clients view the space in 3D prior to completion by using 3D models which allowed users to walk through the space in real time and comment on the progress [Hes97]. 3.6.1.1

Practical modelling approaches

As mentioned previously, the use of virtual reality in the construction industry tends at present to be, ad hoc. However, VR models are usually created either by re-modelling an existing design or by using data in a standard format (i.e DXF). The first approach implies that the design solution must be reentered manually in a form that can be read by the virtual environment (it is inefficient, time consuming and costly). The second approach, importing data in standard formats is more efficient, but if the user, or users, want to interact with individual design elements, it is impossible since all the geometric (semantic) information of the surfaces is lost during this conversion. The current process of translation from CAD into VR is normally a one-way or downstream process. The CAD model is translated into VR, either directly, or through the intermediate stage of a rendering package [WT00] (see figure 3.3). With regards to the creation of VR models, three different approaches have been identified in commercial applications and VR research projects [WT00]: these are to build a library of standard parts, to rely on imperfect model conversion through translators, and to use VR as an interface to a central database.


35

Figure 3.3: “Downstream” translation process (adopted from [WT00]) According to White [WT00], in a library-based approach, a library of virtual elements is employed to save and reuse information about both the geometrical nature of building components and the related processes [AKR97] [OdBB95] (see figure 3.4). A translation approach has been used where there are few repeated elements, geometric data predominates and there are few activities associated with it, or the design process is completed and the design is fixed [Bou97](see figure 3.3 and figure 3.4). Finally, in a database approach the building model is created in the central database and viewed through with the different applications, one of which is the VR package [LJ95] (see figure 3.4).

Figure 3.4: Approaches to the creation of VR models (adopted from [WT00])

3.6.2

Research projects

Different people understand different things by the term VR in the context of construction. For instance, the term VR has been used to refer to numerous computer-based visual activities that can be directly or indirectly used for


36

construction planning. These activities include, but are not limited to, the animation of construction schedules (i.e., 4D CAD [MF98]), design analysis of construction equipment in physical simulation environments (e.g., Working Model, a 4D commercial package from MSC Software), visualization of assembly sequences and real-time virtual interactive modeling of construction equipment (e.g., IV++ developed by Rodrigez et al [RO95]), scenario creation and visualization for interference analysis (e.g., PlantSpace Dynamic Animator a commercial package from MicroStation Ltd for 3D simulation), construction site model based information access over the internet using VRML (e.g Campbell’s case studie [Cam98]), and visualization of operations simulation. As previously stated, in the context of thesis, an interactive design tool is a VR system which is capable of generating VEs to be used to support the design process and therefore, a system capable of mantaining the user-centred aspects of virtual reality: free exploration and interaction in a 3D real-time computer generated environment using a first-person point of view of the world. A number of research projects (or “proof-of-concept” prototypes: [Oxm98], [SM99], [Cam98], etc) are studying the application of VR systems at different stages of the construction process to support interactive design. Therefore, this section reports on the most significant research projects which have used VR systems. However, in order to have an overall perspective of the State-ofthe-Art of VR in construction, these projects have been grouped around three different stages of the construction process: pre-construction phase, construction phase, and post-construction phase [KS00]. The pre-construction stage is a gradual process in which the client’s needs are transformed into an appropriate design solution. According to the construction process model [SA96], this stage is made up of three phases: outline conceptual design, full conceptual design and, coordinated design, procurement and full financial authority. The purpose of the outline conceptual design is to translate the selected option into an outline design solution according to the project brief. Within this phase the main research trend is the substitution of the hand drawings and sketching for a computational medium, a VR system, to support the generation of early design concepts. The work developed by Rivka Oxman [Oxm00]


37

[Oxm98], in The Faculty of Architecture in Haifa, Israel, attempts to produce a new computational medium to support the cognitive processes of visual reasoning, which are characteristics of sketching in early design. Donath and Regenbrecht [DR96] have also worked around the same idea by developing software (“Vox Design”) for 3D sketches in VR which supports the early phases of design process (Architectural sketching). Along the same line of work, COVIRDS (COnceptual VIRtual DEsign System) is a desktop VR system developed by the Department of Mechanical Engineering in the University of Wisconsin. This system allows the designer to create concept shape designs in a 3D environment by using natural interaction mechanism such as, voice commands and gestures. This results in the creation of 3D shapes with approximate dimensions. Once the concept shape design is complete, more precise dimensions can be assigned so that the part may be used for other analyses such as Finite Element Analysis (FEA). However, at the concept stage since the detailed geometry has not yet been created, only a preliminary analysis will be performed [TG95]. Pursuing the same concept, the creation of a new medium that it would support Architects’ visual reasoning, two different institutes of the Swiss Federal Institute of Technology (Architecture and CAAD and, the Laboratore d’Intelligence Artificielle) have developed an intuitive interactive modelling tool named SCULTOR. This system supports the designer by embedding autonomous agents in virtual environment. For instance the navigator agent helps the user (designer) to find locations, to compose tours through buildings or to generate a graph of all possible connections between rooms [SM99]. In the full conceptual design stage, the conceptual design should present the selected solution in more detailed form to include mechanical and electrical equipment (M&E), architecture, etc. Traditional research in this area focuses in the development of software tools (using conventional software engineering tools: C, C++,OpenGL,etc) to aid in the design of specific engineering aspects of the project, for instance, steel frames in multi storey buildings [Tiz98]. However, within this phase the main research trend is the integration of VR visualisation techniques with existing technologies (mainly with relational databases) which can support the assessment of design performance, resource allocations problems, etc at different stages in the construction process. For instance, in the area of urban planning, the work of the Department of Architecture and


38

Urban Design at the University of California, Los Angeles can be used to illustrate the use of 3D real time technologies (mainly MultiGen- Paradigm’s premier real-time products). The UCLA teams focused on creating a user interface for viewing and interacting with the selected urban solution (built of the drawings supplied by the contractors). This simulation interface enables mainly the retrieval of information from databases. For example, it enables the user to query an associated database (such as GIS) for object attributes (e.g parcel characteristics (ownership, type, etc.)) [Uni99]. An emerging area is the simulation of humans’ behaviour to support building design/town planning. For example, Dijkstra [DdV01] has developed simulation models of pedestrian behaviour to support planning decisions. An additional example can be found in multi-user immersive VR system developed by Hareesh [HS98] to simulate building evacuations. Another important research area is the utilisation of novel visualisation techniques used to visualise complex numerical process. An example can be found in the development of a Tunnelling Visualization Software (TVS). This system uses stereo vision to visualise three-dimensional multi-variable scalar fields such as the amount of damage in the rock mass [OB98]. An interesting application is the integration of Finite Element Analysis (FEA) models with VR techniques. For example, Connel [CT00] developed a software system capable of allowing a user to interactively make small modifications to a bridge model. Taylor [TC95] and Liverani [LH99] have also developed systems which integrate FEA models within a Virtual Environment. Direct simulation of HVAC (Heat, Ventilation, Air-Conditioning systems) during the design phase of a building has just started to find its place in practical engineering. The combined use of computational fluids dynamics (CFD) with VR techniques can be regarded as cutting-edge research. Khner [KK00] has addressed this by developing “VirtualFluids Vis”. This prototype makes possible the visualisation of flow data combined with building geometry in a stereo and multi-channel projection system. Similarly, Bjerg [BZ99] has developed a prototype to visualise airflow in a six-sided CAVE. The flow is visualised by arbitrary planes of velocity vectors and air temperature as well as streamlines and particles. The purpose of the coordinated design, procurement and full financial authority stage is to ensure the co-ordination of the design information. Obviously, the internet is the perfect vehicle to enable this. A representative


39

example would be Onuma & Associates [Hes97] and their use of 3D interactive web based models. As previously remarked, these 3D models allowed their worldwide client base to walk through the space in real time prior to completion and comment on the progress. Another example is the virtual design studio project developed at the Swiss Federal Institute of Technology [KJ98]. The project investigates how to coordinate collaborative work between different parties remotely located. The project shows that it is possible to work from a common database using a VRML model. It must be said that the research work carried out in the area of web-based collaborative environments have to rely on existing web-clients (e.g explorer) with limited capabilities. This, in turn, restricts the capabilities of the VR model in terms of lighting, interactivity, etc. On the other hand, distributed virtual environments for collaborative design require the development of complex procedures to ensure the integrity of information (design consistency). For instance, the users could send and retrieve information by using Tell/ Ask/BlockingAsk operations. The use of techniques in collaborative design for internet-based platforms has been investigated by Lottaz [LF99]. Table 3.1 summarises the research efforts in the pre-construction phase. Stage Pre-construction phase

Sub-Stage Outline Conceptual Design

Full Conceptual Design

Coordinated Design

Project Oxman [Oxm98] VOX DESIGN [DR96] COVIRDS [TG95] SCULTOR [SM99] Tizani [Tiz98] Uni. California[Uni99] Dijkstra[DdV01] Hareesh [HS98] TVS [OB98] Connel [CT00] Taylor [TC95] Liverani [LH99] Kuhner [KK00] Bjerb [BZ99] Onuma [Hes97] Virtual Studio [KJ98]

Table 3.1: VR research in the pre-construction phase.


40

The construction phase is only concerned with the production of the project solution. Within this stage, the initial research trend regarding the development of VR systems was to use VR as an interface to remotely retrieve information from a database. For instance, Campbell pioneered the use of VRML to create “hyperlinked” VR models to access detailed information with regards to , e.g., building regulations. For instance, the VR model was used an interface for accessing more detailed representations of the stairs as well as basic textual information necessary to the description/construction of the stairs [Cam98]. In similar fashion, the OSCON project used VR models as means of remotely accessing information stored within an integrated database. For instance, the designer can retrieve information about the specifications of a cavity wall, the QS can obtain cost information about the cavity wall, and the planner queries the model about duration of building the cavity wall [AB97]. Simarly, in the SPACE project [AF97], the VR model is used to access the data related to the project and write updated or newly created data back. However, the model has proved to be inefficient due to its limited capabilities and its lack of consistency (the model struggle to maintain the integrity of objects). More recent lines of research [RO95] [Kum97] follow the initial work developed by Opdenbosch [OdBB95] in which individual object behaviours are integrated in the virtual environment. For instance, a crane, a lorry, and a bulldozer can be added to the world with their corresponding autonomous behaviours. These behaviours are, for example, specific assembly instructions. Consequently, once the machines “know what to do”, the user can run a simulation cycle of that specific operation in the virtual environment. However, these type of simulations are not truly interactive because they do not cater for user intervention while the simulation is running. That is, these systems do not react in real-time to the user’s actions and consequently, do not preserve the principles of VR (they are the equivalent of running a pre-defined animation in the virtual environment). Table 3.2 summarises the research efforts in the construction phase. The post-construction phase aims to continually monitor and manage the maintenance needs of the constructed facility. However,in spite of the many practical uses of VR, the ability to travel through time (to study maintenance & operation of buildings) is an area that has been neglected by academics and developers alike (resulting in limited reference material). An illustrative example has been developed by Khosrowshashi [KR98]. The author developed


Stage Construction phase

41

Sub-Stage Project Campbell [Cam98] OSCON [AB97] SPACE [AF97] Opdenbosch [OdBB95] Retik [Kum97]

Table 3.2: VR research in the construction phase. a prototype which reflects the state of the building through time, by focusing on three aspects of building maintenance -lighting, paint and carpets- . This is achieved by generating the corresponding VR scenes for a given point in time. Hence, this prototype, as with most 4D simulations, fail to take into account the user’s intervention and consequently, do not preserve to key features of VR. Finally, there are existing research efforts which aim to develop integrated environments to support the construction process of an infrastructure from its initial design to its on-site construction, and maintenance during its lifetime. For instance, the FutureHome project [MF00] is a descriptive example. A virtual environment has been developed to support the “overall” construction process of buildings from prefabricated components. In this case, the VE is seen as the visualisation end of the construction process. This work is a continuation of the research developed during the OSCON project [AB97] based on sophisticated techniques previously used in the manufacturing domain [FT99] [FM94] [FD93] (see section 5.4.1.1). Similarly, the DIVERCITY project project has developed an integrated virtual reality system for all the phases: Client-briefing, Design Review, and Construction. For instance, for the construction phase, the DIVERCITY [SF02] project incorporates mathematical optimisation techniques for path optimisation, e.g, to select the best route. Similarly, the other components: lighting, Acoustic, Thermal and Heating also use simulation techniques within the virtual environment [AS02]. Table 3.3 summirises VR research in construction. All in all, the initial trend in the application of VR technologies in the construction domain was to use them as front end to databases. For instance, the OSCON project used VR models as means of remotely accessing information stored within an integrated database (usually a relational database, e.g.


Stage Pre-construction phase

Sub-Stage Outline Conceptual Design

Full Conceptual Design

Coordinated Design Construction phase

Post-construction phase Overall Process

42

Project Oxman [Oxm98] VOX DESIGN [DR96] COVIRDS [TG95] SCULTOR [SM99] Tizani [Tiz98] Uni. California[Uni99] Dijkstra[DdV01] Hareesh [HS98] TVS [OB98] Connel [CT00] Taylor [TC95] Liverani [LH99] Kuhner [KK00] Bjerb [BZ99] Onuma [Hes97] Virtual Studio [KJ98] Campbell [Cam98] OSCON [AB97] SPACE [AF97] Opdenbosch [OdBB95] Retik [Kum97] Khosrowshashi [KR98] FutureHome [MF00] DIVERCITY [SF02]

Table 3.3: VR research in construction. ACCESS TM database). More recent applications tend to use VR as an interface for various types of mathematical simulations (lighting, acoustic, etc). For instance, an illustrative example is the development of a Tunnelling Visualization Software (TVS) to visualise three-dimensional multi-variable scalar fields such as the amount of damage in the rock mass [OB98]. However, little work has been done to extend the initial work developed by Opdenbosch [OdBB95] in which individual object behaviours are integrated in the virtual environment. That is, the development of interactive design tools which support engineering design (e.g resolution of spatial configuration problems) by integrating, for instance, engineering knowledge into the virtual environment.


3.7

43

Characterisation of VR systems in design

As has been reported in section 3.6.2, there have been several attempts to develop VR systems that support design, mainly, by simulating construction operations in the virtual environment. The purpose of this section is to present a characterisation or set of requirements for the implementation of interactive design tools (see section 3.5) for spatial configuration tasks. Hence, these requirements have been related to the proposed representation of the design process for the interactive resolution of configuration problems (see section 2.3) as follows: 1. Elicitation of Background (Engineering/Construction) knowledge, or in other words, the ease to express engineering knowledge in the system: (a) Support for high-level representations of entities . That is, the system provides a high level representation to deal, for instance, with geometric and engineering requirements [Lam96b]. Geometric requirements are geometric relationships imposed on distinct geometric entities (e.g. minimum and maximum distance between objects). Engineering requirements are used to represent basic engineering principles which are mainly related to performance of an entity. For instance, the stress in a part, the valid luminosity levels for that entity, etc. Of course, both set of requirements can be seen as one. However, the distinction is useful since different systems could employ techniques which are more suitable for a particular type of requirement [Lam96b]. (b) Support for incrementally inserting design requirements into the system. The limitations for most systems are twofold: • For most systems, whenever a new design requirement is inserted, the system re-satisfies all the design requirements from scratch [SG92]. • There is also a limited use of graphical techniques [SB91]. Therefore, the user cannot directly manipulate entities (e.g objects) and thus explore under-constrained spaces. This results on a non-intuitive way of specifying a complete set of design requirements [Rol91].


44

2. Integration into the design cycle while maintaining the user-centred aspects of VR. There are two main restrictions for the integration of a VR system in the design cycle so that the user can interact with the underlying design knowledge expressed in the virtual environment: (a) The system has to solve the problem correctly and in a robust way or in other words, the system consistently finds the correct solution to the problem in hand. An example of unreliable systems are those which rely on analytical methods. These systems are based on numerical integration of, i.e, mechanical equations. The major disadvantages of these systems are that they often present convergence problems and the fact that they are computationally expensive. This means they cannot be made interactive and as a consequence, they are not suitable for interactive design[FD93]. (b) The system needs to solve the problem efficiently. That is, the resolution of the problem should not hinder the interactivity required in a virtual environment [AC01]. That is, the key principles of VR should be maintained: exploration and interaction in a 3D real-time computer generated environment. 3. Validation of design solution. As the design evolves, the number and type of design requirements can reach large numbers depending on the stage of the process and type solution sought. Therefore, the system is expected to handle the arising design problems in a correct, robust and efficient way which, in turn, guarantees a quick validation of the design solution. Ideally, the underlaying mechanisms in the system should enhance the user’s capabilities for exploring different design alternatives. That is, the system should not only validate a solution input by the user but, for instance, should also support interactive problem-solving by reacting to the user modification of a given configuration. Thus, it would allow the user to explore, the first, the best and all solutions [AC01]. That is, ideally, once a solution has been found, the system should allow the interactive exploration of the solution space in which design alternatives can be found.


3.8

45

Discussion

It is unclear that any increased in performance can be gained by using high-end VR systems (see section 3.4). This coupled with the the low cost of desktop VR have made desktop VR the most suitable system to support interactive design in the construction industry (see section 3.6.1). An additional advantage of a desktop VR system over the others is that all objects in the scene are viewable at once. This is important in, for example, spatial configuration tasks where the user has to take into account, for instance, the location of all objects in the virtual scene. As shown in section 3.6.1, existing commercial applications of VR for the construction industry are generally limited to the architectural modelling field and are used (ad-hoc and as an end product) for the presentation of completed building designs. That is, “traditional” VR is mainly used as a 3D visualisation tool with limited interactive capabilities (e.g interactive navigation). On the other hand, a number of research projects are studying [Oxm98] [SM99] [Cam98] the application of VR technologies at different stages of the construction process to support interactive design. However, it is unclear how VR technologies can be integrated in a fully interactive way at the early stages of the project [Bro99]. Therefore, it is important the identification of a set of requirements (see section 3.7) for the implementation of VR systems in the design process. With the type of VR system (desktop VR) selected and the set of requirements identified (for its implementation in the design process), in the next chapter, an experimental evaluation examines the appropriateness of the “traditional” VR as an interactive design tool.

3.9

Summary

In this chapter, the key features of VR which support the development of interactive design tools have been identified. This chapter has also presented a survey of recent progress in the application of VR systems (current practice and research projects) in the A/E/C industry to support interactive design. Finally, in this chapter, a set of requirements for the implementation of interactive design tools has been proposed.

Chapter 4 Experimental study of VR in design 4.1

Introduction

In this chapter, the use of “traditional VR” for spatial configuration problems is explored using an experimental approach. The limitations of VR, in its current form, are identified and new directions for a new generation of VR systems based on Intelligent Virtual Environments are proposed.

4.2

Objective

The experimental aim was to examine the appropriateness of “traditional” VR technology as an interactive design tool for spatial configuration tasks and to gain experience in the application and applicability of VR by conducting a qualitative/quantitative evaluation of VR technology. Empirical evidence gained by attending briefings and witnessing how users reacted to the presentation of purpose built VR models suggested that VR technologies could be used in the application domain in hand, the briefing stage in the construction process. For instance, the following anecdotal evidence was obtained from attending a briefing. To show the “potential” of VR to a group of potential users, a brief demonstration was organised: a fairly crude desktop VR model of the future building was shown to them and they were allowed to walk through it by giving appropriate instructions to the driver (an experienced person in VE 46

CHAPTER 4. EXPERIMENTAL STUDY OF VR IN DESIGN

47

navigation). This experience triggered a stream of reactions from the users on the proposed design and the experience of “interacting” with a VR model was very well received. The potential usefulness of VR suggested by the empirical evidence was confirmed by Dorta and Lalande [DL98] in their experiments. They showed that non-immersive VR is a more effective way of communicating design concepts than traditional tools. This finding is evidence for the hypothesis that desktop VR can be a good interactive design tool for the resolution of spatial configuration tasks. Consequently, if the hypothesis is supported by the the results of the experiment described in this chapter then, desktop VR in its current form could be used in our application domain.

4.3

Method

This section reports on the development of an experimental method, which is part of the overall experimental framework designed to test and gain an insight into the applicability of VR as an interactive tool in the design process. The experimental method consists of: • The experimental design • The experimental procedure • The selection of materials and scenario

4.3.1

Background: related experiments

To experimentally investigate the applicability of VR systems, the pioneering work “Is VR better than a workstation?” carried out by Mizell, Jones and Jackson [MJ95] for the Boeing company provides a good reference for the design of the experiment. Mizell et al. questioned the applicability of VR technology in a particular industrial environment: the design of aeroplanes. Their initial questions such as “Why do I need VR? What can I do in VR that I cannot do just as well on a workstation with fast graphics?” with regards to the applicability of VR in their domain translated into the following working hypothesis: “VR helps a user comprehend - build a mental model of - complex 3D geometry” [MJ95]. Furthermore, Mizell and his colleagues envisaged that


48

the ultimate payoff for VR is in its potential for interaction (e.g an engineer could, in a VE, move/allocate different objects to accomplish a design task with much more speed and understanding the consequences of each decision than in a CAD workstation). However, they hypothesized that “even if we limited ourselves to visualisation, in the absence of any sort of interaction capability, VR might outperform a 2D CAD workstation” [MJ95]. Mizell’s work has influenced a myriad of experiments in the area of “applicability” of VR systems, especially those experiments which try to assess the influence of immersive VR systems on performance [SU96] [SM98] [WS94] [MS99b]. In the experiment reported in this chapter, Mizell’s work has been influential in the selection and classification of variables which relate the hypothesis to the results (see section 4.4.1) and minor aspects of the experimental procedure such as the inclusion of a standard eye test for acuity. Similarly, within the building design context, there is also a number of recent studies which address fundamental questions in the understanding of the application of VR systems in the building design domain. As previously mentioned, Dorta and Lalande [DL98] studied the impact of Virtual Reality on the design process as a tool for conceptual design and as a communication medium. They found that VR, in its current form, had a significant influence on the activities of communicating 3D information in the design process. However, no significant difference was found between VR and traditional tools when VR was used as a tool for conceptual design. Their explanation was three fold: the project test was not complex enough; a larger population would have yielded different results; or, finally, VR in its current form is not a cure-all for design. Other researchers have opted to study the taxonomy of virtual environments (VEs), with the goal of making VEs applicable to the domain in hand, building design in this case. For instance, Bridges and Charitos [BC01] have proposed a framework for the design of space in VEs comprising a taxonomy of the spatial and space-establishing elements that a VE may consist of (the structure of these elements) and their significance for human wayfinding behaviour. For example, the aim of one their experiments was to investigate what impact certain formal elements, applied to the surfaces of path boundaries, would have on the impression of movement experienced by subjects who moved along these paths. Based upon this work, guidelines were produced


49

about the taxonomy of the virtual environment such as “the experience of movement in a VE is significantly enhanced by the use of dynamic textures”. In similar fashion, Oxman’s work [Oxm00] investigates the development of cognitive models which relate the internal mental representations, strategies and mechanisms of generic design to the representation medium, in this case, a virtual environment. This type of work [BC01] [Oxm00] is similar to the pioneering investigation carried out by Kirsh [Kir95] in which the author successfully provides a classification of some of the ways space is intelligently used. Although this type of experiment [Kir95] [BC01] [Oxm00] helps to indicate the way in which the resources available within a virtual environment can be re-arranged to obtain, using Kirsh’s term, “informationally structured environments” where capacities (such as reasoning, visual search, and so on) are improved by different mechanisms (e.g particular distribution of resources), they do little to gain an insight into the applicability of VR as an interactive tool in the design process. Consequently, for this experiment, it was decided to follow Mizell’s experimental design due to its similarity with regards to the hypothesis to be tested.

4.3.2

Experiment design

It was decided that the best approach was to simulate, in laboratory conditions, one cycle in the briefing process using “traditional” VR practices and realworld data: a live project. That is, VR was used as a visualisation tool with limited interactive capabilities (e.g interactive navigation) in a real building. In this case, the building was part of Teesside University: the Centre for Enterprise (CE), designed by DEWJOC partnership and in which, the client’s representative was the Estates Department of the University. Hence, in the experiment, participants were asked to assess a proposed design solution in a VR model of a building. A positive outcome of the experiment would be that VR technology can be used and facilitates the briefing process. That is, during the design review process, users and/or clients need to be able to better understand the design of the proposed building. The proposed design is expressed in the geometrical layout, texture, form, colour, light, scale, etc of the different building components. Therefore, the experiment was set up to qualitatively assess (gain an insight) if VR technology facilitates this design review process, in general, and for spatial configuration


50

tasks, in particular. For instance, for the Drop-in centre one of the user’s requirements was to create a sense of openness in the room. This was addressed by the design team by proposing glazing windows towards the corridor (see figure 4.1). Thus, in one of the experimental tasks the participants were asked to assess the sense/feeling of openness of the room and explain his/her answer verbally stating the building features which create that “feeling” (if any). Consequently, a successful answer was the one which accepted the proposed design and identified the correct building features. For instance and following with this example, a successful answer would be something like this one extracted from the experimental data: “ I wouldnt say this room was claustrophobic / there is plenty of views..ah..out into the corridor / or out to the outside world...”. Similarly, one of the design requirements for the reception room was to be able to see who is coming into the building without leaving the room. Consequently, the design team proposed a spatial arrangement of the elements involved in the configuration, in this case, the window towards the outside, the stairs (to go up to the next floor) and, the interior glazing window. Thus, as before, the participants were asked to assess the solution. A successful answer to the question: “Could you tell me how would you see if someone were coming into the building? Please, assess the solution proposed in the building (if any) and, explain your answer. Additionally, you can propose alternatives to the presented configuration” was the one that mentions the solution proposed by the design team, identifies the elements of the configuration and/or proposes alternatives.

Figure 4.1: Building layout: ground floor. It should be noted that for this experiment, the proposed design solutions


51

presented to the user were delivered in agreement with the design team (e.g architects). That is, prior to the experiment, the development of the VR model was carried out according to the architects’ criteria at that stage of the briefing process. Thus, the developed experimental framework was based on VR techniques to convey the proposed design solution and behavioral research methods [GG89] [ES83]to capture and analyse the user’s input. The experimental design follows Mizell’s experiments and it is organised as follows: a) A set of tasks was selected to support the evaluation b) A system or method was designed for data collection c) A scoring system was devised to measure the participants’ completion success when performing the tasks. In other words, each task had its own goal which had to be broken down into components (key variables). Once, they had been identified it was necessary to decide its relative importance and to have a measurement method to quantify them d) A statistical analysis was carried out to obtain the results and, consequently, to be able to infer the conclusions (see figure 4.2). In this case, as in Mizell’s original experiments [MJ95], there were no independent variables or factors such as level of immersion (workstation or immersive head-tracked display). Consequently, the analysis and conclusions were based on, using Mizell’s terminology, explanatory and response variables

4.3.2.1

Tasks

The definition of the tasks was regarded an essential part of the investigation to gain qualitative experience in the application and applicability of VR. Hence, an understanding of the internal “radical constraints” (design requirements) of the building, because the target group were the potential end-users, was considered the key consideration for the identification of an appropriate set of tasks to carry out the assessment. Radical constraints are those which deal with the primary purpose [Law97] of the building and need users’ monitoring and eventually approval. Therefore, in order to obtain these constraints, interviews (knowledge acquisition) were held with the architects and the users’ representatives.


52

Figure 4.2: Experimental methodology. By means of a semi-structured interview with a representative of the design team, the proposed design solutions which address specific user’s main requirements were identified. For instance, in the syndicate room, the requirement was to design a room which had a feeling of openness. Consequently, the design team proposed a glazing windows towards the corridor and towards the outside to create a feeling of openness. Thus, in the experiment the participants were asked to assess the feeling of openness of that room and explain his/her answer by verbally stating the building features which create that feeling. The process of identifying user requirements process was repeated for the rest of the parts/rooms of the building. As a consequence of this, the following types of tasks were defined: • Appreciation tasks: a participant had to express his/her opinion to


53

appreciate the solution proposed by the designer. • Problem-solving tasks: a participant had to assess the solution proposed in the design by solving a proposed spatial configuration problem.

Part of the building Syndicate room

Drop-in centre

Drop-in centre Reception

Corridor

Requirement Feeling of openness

Solution Glazing panels to the corridor and windows to the outside Feeling of openness Glazing panels to the corridor and windows to the outside Feeling of being secure Roller Shutters Feeling of openness Glazing panels to the corridor and windows to the outside Ease of moving through Glazing panels between corridor and rooms and, the distribution of pillars

Table 4.1: Appreciation tasks. Tables 4.1 4.2 summarize the experimental tasks carried out by the participants in the experiment. Part of the building Reception

Computer Laboratory

Requirement Solution To be able to see Window towards the who is coming into outside, stairs the building without and, interior leaving the room glazing window To be able to monitor Dividing wall both labs at any , interior window time and location of tables

Table 4.2: Problem-solving tasks. In conclusion, a summary was obtained of the “radical” building requirements of various spaces in the building for a cycle of the briefing process.


4.3.3

54

Participants

The participants, 7 in total, (3 research students, 1 technician, 1 lecturer, 1 project officer and 1 industrial liaison). They were unpaid volunteers and recruited through an internal e-mail list. The mean age was 32.8 with a SD of 8.6; five were male and two female. The mean number of hours a week spent using computers was 35.6 with a SD of 18.1; the most frequent uses were: office applications (mean = 21 hours/week), Internet applications (mean=7.1 hours/week), and programming (mean=5.3 hours/week). Games and visualisation software were only used, two hours a week each, by one person. None of the participants use screen magnification software. Based on similar experiments [AdV98] [Won99], it was decided to carry out the experiment with 7 different end-users. Furthermore, recent studies aimed to evaluate the effectiveness of Virtual Reality (VR) technology at presenting architectural design during the client design review stages of a construction project have also used similar number of participants [PF02].

4.3.4

Materials

A digital video camera with headphones and microphone was used to show the thinking-aloud procedure to the participants and for recording their task performance. The desktop VR system used is illustrated in figure 4.3. The experimental room was a VR laboratory. 4.3.4.1

Scenario

As mentioned before, the proposed design solutions presented to the participants were delivered in agreement with the design team (e.g architects). For instance, it was decided to use neutral colours instead of textures in order to avoid diverting the participant’s attention towards the materials. The model was constructed from the CAD drawings and in collaboration with the architects. There are approximately 35,000 polygons in the model and it uses approximately 4 MB of texture memory. When running the model in the VR system, it was attained a frame rate of 30 frames per second in all areas of the model (see figure 4.3).


Figure 4.3: Experiment set-up: VR system.

55


4.3.5

56

Procedure

Consequently, to carry out the experiments in a structured and systematic manner an experimental procedure was developed. The procedure consisted of a detailed set of written instructions for both experimenter and participant on how to perform during the experiment. The instructions were written so that the participant and the experimenter had a clear understanding of the task entrusted (see appendix 1) . This set of instructions was divided into three parts: (i) Screening of human factors. Participants filled in a series of questionnaires to measure general state of health, age, confirmation of visual capabilities, amount of weekly computer use, extent of spatial navigation and training experience and physiological status information. (ii) Performing tasks using the VR model. The participant was asked to carry out a series of tasks using a Virtual Environment to convey the design solutions proposed by the design team. Additionally, the participants were given as a reference two 2D drawings of the building (the ground floor and the first floor). Consequently, this generated an explanatory variable: percentage of time spent on looking at two dimensional drawings or VR model which, helped to qualitatively gauge the “effectiveness” of the VR model for certain tasks. Behavioral research methods were used to capture the participants’ input and therefore, to validate the design solutions. In particular, while carrying out the tasks the participants are required to think aloud: a procedure commonly used to analyse usability problems of new software [Nie93]. A more detailed description on how the data was collected and analysed can be found in section 4.3.6 and4.4 respectively. Thus, in order to ensure a systematic approach, the experimenter provided written instructions to the participant on how to perform a particular task. Therefore, each task had its own set of instructions. Prior to carrying out any task, the participants were prepared to make them aware of what they were required to do in order to produce “rich” verbal protocols, both passively by watching a video and actively through two practice tasks in another VR model. (iii) Post-trial questionnaires and debriefing. The participants were asked to answer further questions regarding his/her experience within the VR model


57

of the building. The questionnaire results were used as another source of information to complement and confirm the results derived from the participants’ task performance.

4.3.6

Data collection

Thanks to modern technology, observational data are much easier to collect than to analyse. Analysis is often time consuming and, as in this case, it is not obvious what type of data should be analysed, what form the analysis should take and what techniques can be used. In this case, it was opted to use ESDA (Exploratory Sequential Data Analysis) techniques. A term coined by Penelope Sanderson [SF94] to refer to the many techniques that already exists in the behavioural and social sciences for handling observational data and for performing sequential analyses. In order to obtain the raw sequences of data, the experimental sessions were recorded on videotape (with sound). The following steps were taken in order to pre-process the data so that it could be analysed and interpreted: firstly, each of the sessions was transcribed so that it could be analysed. This was done by two independent investigators. As a result of this process, the investigators obtained the verbal transcriptions plus the physical movements or actions of a participant (e.g when h/she is looking at the drawings or the virtual environment the code LD was annotated). Secondly, the verbal transcriptions (data) were segmented. That is, the investigators had to aggregate adjacent data that he/she viewed as coherent. Again this operation was done separately and then an agreement was reached. Thirdly, the segments were coded/labelled. Codes were labels which were linked to data segments. For instance, when the code QL was linked to a data segment, this means that a “qualitative judgment” to a concrete design requirement had been stated by the user. For example, while carrying out one of the experimental tasks, a participant was asked to assess the feeling of openness of the drop-in centre. Consequently, before proceeding with the analysis as such, his/her answer was transcribed, segmented and coded (see table 4.3). Therefore, the segment “I wouldnt say this room was claustrophobic” was linked to the code QL and the corresponding physical actions annotated, e.g LS means h/she is looking at the screen. It must be noted that, in accordance with ESDA research [SF94], the development of the coding scheme was an iterative process which was intimately related to the


58

scoring system and, in turn, to the analysis.

/ ... these are windows / ..SP PS . but they are quite high up it seems ... in relation to where we are / ..ah ... now weve got a large blank wall / ...ah with no detail on it / ... and were continuing to revolve / SP ... now weve got a PS ceiling to floor glass windows SP / and weve got a large ah a very large opening / with..PS and what I imagine is hm SP an ascending grille / .. and then PS SP a blank wall / l ... ah LT I wouldnt say LS this room was claustrophobic [QL] / therere is plenty of views..ah..out into the corridor / or out to the outside world ...ah .LT LS ./

Table 4.3: Pre-processing data: transcription, segmentation and coding. Finally, in order to facilitate the subsequent analysis by a Visual Basic application that was developed for data analysis, all the necessary information was grouped in the right format in a text file.

4.4

Data analysis

As previously remarked, a scoring system was needed to measure the participants’ completion success when performing the tasks.

4.4.1

Response variables

For this experiment, the response variables were the codes or labels which were linked to the data segments. For instance, a successful answer when the user was asked to judge the openness of, for example, the drop-in centre would be something like this one extracted from the real data: “ I wouldnt say this room was claustrophobic / there is plenty of views..ah..out into the corridor / or out to the outside world...”. Consequently, the data segment: “I wouldnt say this room was claustrophobic” is associated with the code QL(S,+-). This means that the user is satisfied with solution proposed (S) and, identify the correct building features but it is not absolutely certain (+-). An example of


59

a certain answer would be the following (also extracted for the data): “/.... you don’t get the feeling of being enclose/”. The code associated would be QL(S,+). Moreover, in the situation in which the participants expressed more than judgement or solution, all of these were coded and counted independently. This process was repeated for all the appreciation and problem-solving tasks in order to measure the participants’ completion success when performing the tasks. These key codes were developed iteratively in order to ensure that the coding scheme adequately described the data. In other words, a few tasks were initially analysed to produce descriptive codes. Therefore, in appreciation tasks, the investigators looked mainly for quantitative judgements (estimation), qualitative judgements (feelings - claustrophobic, spacious, secure - and spatial movement understanding), justification of judgements and alternatives. In problems solving tasks, the investigators looked mainly for solution, assessment, alternatives and justification of solutions and alternatives. Table 4.4 summarises the key codes or response variables. Key code Qualitative judgement

Notation QL(i,j)

Solution

SL(i,j)

Description i = S, U, ? S: successful solution U: unsuccessful solution ?: unable to judge j = +, +-, -, NA +: certain +-: somehow certain -: uncertain i = C, I, ? C: correct solution I: incorrect solution ?: unable to judge j = +, +-, -, NA +: certain +-: somehow certain -: uncertain

Table 4.4: Response variables.


4.4.2

60

Explanatory variables

In addition to the response variables, explanatory variables were also measured to provide further information. In particular, when the user was performing an experimental task, the percentage of time spent by the user on looking at two dimensional drawings or VR model and the frequency of using either the VE or the drawing were logged in order to provide an “indicative” measurement of the “appropriateness” of the VR model (see table 4.5). Action Code Looking at VR model LS Looking at Drawing LD Table 4.5: Explanatory variables.

4.4.3

Statistical analysis

Two types of statistical results were produced: descriptive statistics to reflect trends embedded in the data and inferential statistics to draw conclusions based on statistical probability theory. The following example is an illustration of how the descriptive analysis was carried out on the data. For instance, when a participant was asked to assess the feeling of openness of the syndicate room, the frequency distributions were calculated for the response variables, QL codes in this case. That is, once the data segment, for example,: “I wouldnt say this room was claustrophobic” has been associated to following code QL(S,+-), its frequency is calculated over the task for all the participants. In other words, if the QL(S,+-) is encountered 3 times in that task and the total number of answer for all the participants is 10, then, the relative frequency is 30%. Table 4.6 shows the frequency distribution obtained for the example in hand. To speed up the process of analysing the data, and make it more reliable, a Visual Basic application (see figure 4.4) was developed to carry out the following operations: calculate the frequency distributions of response variables and the indicators (explanatory variables): time spent on looking at screen or drawings and, frequency of looking at screen or drawings. Table 4.7 shows the median and semi-interquartile range for the frequency and percentage of


QL S + 39.29% +46.43% 0.00% NA 0.00% Total 85.71%

U 4.76% 4.76% 0.00% 0.00% 9.52%

61

? Total 0.00% 44.05% 0.00% 51.19% 0.00% 0.00% 4.76% 4.76% 4.76% 100.00%

Table 4.6: Descriptive statistics for response variable QL. time spent on looking at the screen (LS*) or drawings (LD*). It must noted that whilst performing the tasks the participants spent time on, for instance, reading the task card. Therefore, LS*+LD* does not add up to 100%. All the calculations were made per task per participant.

Figure 4.4: Visual Basic application. However, in order to draw conclusions a descriptive statistical analysis is not enough. Hence, an inferential analysis was conducted to test against the possibility of producing answers at random. For the response variables, a chi square (χ2 ) test of distribution was used with the significance level set at 0.05 (α = 0.05). The χ2 test, tests distribution of a response variable (in this case, the distribution of successful answers (S) versus other types of answer) against an equal distribution (50% in this case). For instance, as shown in table 4.6, the percentage of successful answers is 85.71 %, the test tests this distribution against the equal distribution. Thus, a positive test results means that the


Median SIQR*

LD*(fr) 3.00 0.75%

LD*(%) 5.40% 6.17%

Median SIQR*

LS*(fr) 7.00 1.25%

LS*(%) 80.47% 0.15%

62

Table 4.7: Descriptive statistics for explanatory variables. distribution of successful answer is “statistically” different from the 50% and therefore, different from random. This test was used because the response variables are categories (nominal level of measurement) rather than numbers. On the other hand, the Wilcoxon matched-pairs signed-ranks test was used for the explanatory variables with α = 0.05. This test compared the % of time spent looking at the two different representations (the drawing and the VR model) and also, tested if the frequency of looking at the drawing was statistically different from zero. Thus, in the first case, a positive result means that the participants have spent “statistically” more time looking at the VR model than to the drawing. In the second case, a negative result means that the number of times the participants looked at the drawing was “statistically” different from zero. Hence, the drawing was used. For instance, as shown in table 4.7, the participants, in a particular task, spent significantly more time looking at the VR model than at the drawing. The Wilcoxon test show that this difference was significant, p fd_domain(D, DMin, DMax) ; D = Dist ), member(Wall, LWall), % creates a choice-point set_wall_cstr(Wall, D, X, Y). one_cstr(power(Dist), _, _, Seq) :power_point(LXY), member(A/B, LXY), % creates a choice-point a_b_to_seq(A, B, Seq1), dist_le(Seq, Seq1, Dist). one_cstr(luminosity(Min..Max), X, Y, _) :luminosity(LVRect),

205

APPENDIX B. CLP SOLVER: SOURCE CODE

select_imposs_rect(LVRect, Min, Max, LRect), set_imposs_rect(LRect, 0, X, Y). one_cstr(temperature(Min..Max), X, Y, _) :temperature(LVRect), select_imposs_rect(LVRect, Min, Max, LRect), set_imposs_rect(LRect, 0, X, Y).

set_imposs([], _). set_imposs([A/B|LAB], Seq) :g_read(size_y, SizeY), K is SizeY * A + B, Seq #\= K, set_imposs(LAB, Seq).

set_imposs_rect([], _, _, _). set_imposs_rect([A1/B1-A2/B2|LRect], Dist, X, Y) :X #< min(A1, A2) - Dist #\/ X #> max(A1, A2) + Dist #\/ Y #< min(B1, B2) - Dist #\/ Y #> max(B1, B2) + Dist, set_imposs_rect(LRect, Dist, X, Y).

set_min_distance([], _, _). set_min_distance([A/B|LAB], Dist, Seq) :a_b_to_seq(A, B, Seq1),

206


207

dist_gt(Seq, Seq1, Dist), set_min_distance(LAB, Dist, Seq).

set_imposs_path([], _, _, _). set_imposs_path([R|LPath], Dist, X, Y) :set_imposs_path1(R, Dist, X, Y), set_imposs_path(LPath, Dist, X, Y). set_imposs_path1(A/B1-A/B2, Dist, X, Y) :- % optimize vertical paths !, X #< A - Dist #\/ X #> A + Dist #\/ Y #< min(B1, B2) #\/ Y #> max(B1, B2), dist(X, A) + dist(Y, B1) #> Dist, dist(X, A) + dist(Y, B2) #> Dist. set_imposs_path1(A1/B-A2/B, Dist, X, Y) :- % optimize horizontal paths !, X #< min(A1, A2) #\/ X #> max(A1, A2) #\/ Y #< B - Dist #\/ Y #> B + Dist, dist(X, A1) + dist(Y, B) #> Dist, dist(X, A2) + dist(Y, B) #> Dist. set_imposs_path1(R, Dist, X, Y) :- % default case (unoptimized) points_of_segment(R, LAB), set_imposs_path2(LAB, Dist, X, Y).

set_imposs_path2([], _, _, _).


set_imposs_path2([A/B|LAB], Dist, X, Y) :dist(X, A) + dist(Y, B) #> Dist, set_imposs_path2(LAB, Dist, X, Y).

set_poss_path(R, Dist, Seq) :points_of_segment(R, LAB), member(A/B, LAB), a_b_to_seq(A, B, Seq1), dist_le(Seq, Seq1, Dist).

points_of_segment(A1/B1-A2/B2, [A1/B1|LAB]) :FA1 is float(A1), FB1 is float(B1), FA2 is float(A2), FB2 is float(B2), setof(X/Y, one_point(FA1, FB1, FA2, FB2, X,Y), LAB).

one_point(A1, B1, A2, B2, X, Y) :abs(A1 - A2) =< 1, abs(B1 - B2) =< 1, !, X is round(A2), Y is round(B2). one_point(A1, B1, A2, B2, X, Y) :MA is (A1 + A2) / 2, MB is (B1 + B2) / 2,

208


(

one_point(A1, B1, MA, MB, X, Y) ; one_point(MA, MB, A2, B2, X, Y)).

set_wall_cstr(A > (B1-B2), Dist, X, Y) :!, X #= A + Dist, Y #>= B1, Y #=< B2. set_wall_cstr(A < (B1-B2), Dist, X, Y) :!, X #= A - Dist, Y #>= B1, Y #=< B2. set_wall_cstr((A1-A2) > B, Dist, X, Y) :!, Y #= B + Dist, X #>= A1, X #=< A2. set_wall_cstr((A1-A2) < B, Dist, X, Y) :!, Y #= B - Dist, X #>= A1, X #=< A2.

select_imposs_rect([], _, _, []). select_imposs_rect([V = _|LVRect], Min, Max, LRect) :-

209


210

V >= Min, V =< Max, !, select_imposs_rect(LVRect, Min, Max, LRect). select_imposs_rect([_ = Rect|LVRect], Min, Max, [Rect|LRect]) :select_imposs_rect(LVRect, Min, Max, LRect).

/* --- Cache file -------------------------------------------------------- */ read_cache_file :file_exists(’veplace.cache’), open(’veplace.cache’, read, _, [alias(cache)]), repeat, read(cache, T), ( T = end_of_file -> ! ; assertz(T), fail ), close(cache). read_cache_file.

show_cache_file :-


211

file_exists(’veplace.cache’), open(’veplace.cache’, read, _, [alias(cache)]), repeat, read(cache, T), ( T = end_of_file -> ! ; T = static_dom(Obj, LSeq), format(’~n~a = ’, [Obj]), member(Seq, LSeq), seq_to_a_b(Seq, A, B), format(’ ~w’, [A/B]), fail ), close(cache). show_cache_file.

write_cache_file :open(’veplace.cache’, write, _, [alias(cache)]), Cl = static_dom(_, _), clause(Cl, _), format(cache, ’~w.~n~n’, [Cl]), fail. write_cache_file :close(cache).

/* --- Objects and associated constraints -------------------------------- */


/* Object names and default number */ object(vm, 1). object(atm, 2). object(desk, 2). object(sofa, 2). object(fire_ext, 3). object(bin, 4).

/* default min and max distance between 2 objects */ distance_constraint(vm, vm, 15, 1000). distance_constraint(atm, atm, 15, 1000). distance_constraint(desk, desk, 6, 12). distance_constraint(sofa, sofa, 6, 12). distance_constraint(fire_ext, fire_ext, 20, 1000). distance_constraint(bin, bin, 15, 1000). distance_constraint(desk, bin, 8, 1000).

212


213

/* min and max distance for any other objects */ distance_constraint_others(8, 1000).

/* constraint specific to each object */ constraint(vm, [furniture(1), path_no(1), heat(2), duct(1), wall(1), power(3)]). constraint(atm, [furniture(1), path_no(1), heat(2), duct(1), wall(0..1), power(3), queue_area(0)]). constraint(desk, [furniture(6), duct(3), power(3), luminosity(300..500), temperature(19..24)]). constraint(sofa, [furniture(4), duct(4), wall(2..6), temperature(19..24), queue_area(3)]). constraint(fire_ext, [furniture(0), duct(0), path_yes(6), wall(0), counter(0)]). constraint(bin, [furniture(0), heat(2), path_yes(5), wall(0), queue_area(0)]).

/* --- Room description -------------------------------------------------- */ /* grid_size(SizeX, SizeY). source_of_heat([X/Y,...]) ventilation_duct([X/Y,...]) power_point([X/Y,...])


trap([X/Y,...]) furniture([X1/Y1-X2/Y2,...]) (X1/Y1-X2/Y2 path([X1/Y1-X2/Y2,...]) (X1/Y1-X2/Y2 wall([X or (X1-X2) > or < Y or (Y1-Y2),...] luminosity([V = X1/Y1-X2/Y2, ...]) (X1/Y1-X2/Y2 temperature([V = X1/Y1-X2/Y2, ...]) (X1/Y1-X2/Y2

214

is a rectangle) is a segment) is a rectangle) is a rectangle)

*/ grid_size(36, 36). source_of_heat([7/0, 0/6, 35/6]). ventilation_duct([0/0, 6/0, 35/0, 35/7]). power_point([1/0, 31/0, 35/2, 0/4, 35/10, 0/11, 0/24, 35/26, 11/4, 17/4, 23/4, 11/10, 17/10, 23/10]). trap([]). furniture([13/13-26/22, 0/27-27/27, 10/31-35/31, 29/35-34/35]). path([30/33-5/33, 5/33-5/29, 5/29-31/29, 31/29-31/24, 31/24-4/24, 4/24-2/18, 2/18-3/8, 3/8-15/8, 4/24-15/8, 2/18-15/8, 15/8-17/4, 17/4-15/2, 17/4-23/0, 15/8-30/8, 15/8-35/15, 30/8-30/0, 30/8-30/18, 30/18-31/24, 30/18-35/18]). queue_area(0/25-35/35). counter(6/35-28/35). wall([0 > (0-12), 0 > (23-35), 35 < (0-12), 35 < (23-35), (0-35) > 0, (0-35) < 35]). luminosity([200 = 0/0-5/5, 200 = 35/0-30/5, 200 = 0/35-5/30,


200 = 30/30-35/35]). temperature([18 = 3/10-0/25, 18 = 32/10-35/25]).

215