Design Patterns for Augmented Reality Systems

For documentation and development of augmented reality (AR) systems, we propose the use of design patterns. Patterns are structured descriptions of successfully applied problem-solving knowledge. They describe a specific design problem, the particular design context, and a generic solution scheme. The solution scheme specifies the involved components, their responsibilities, relationships and the way they cooperate. We see design patterns as the right abstraction for the documentation of AR systems. A common language based on design patterns allows the use of common, well-known terms among developers of AR systems. Examples are terms such asscene graph-based rendering andnetworked trackers . With a catalogue of patterns, developers of AR systems can more easily identify existing solutions to design problems. For this, we must identify relations and dependencies among individual patterns. The goal is the systematic ordering of the individual patterns into a system of patterns. Such a pattern system shows the interdependencies among the patterns. For example, aVRML web pluginenables easy embedding of AR content into web documents, but in turn requires a web server , which is unsuited for autonomous systems. This paper is the continuation of a discussion we started at the STARS 2003 workshop [13]. We have already identified some 30 design patterns for AR. Most of the patterns will also be relevant for mixed reality systems. In this paper, we present our existing catalog of design patterns and discuss the findings. In particular, we consider it as important to find the right name for each pattern, to bring forward discussion in the developer community. INTRODUCTION The discussion and comparison of different software architectures for Augmented Reality (AR) is often difficult because of the different ways the developers document them. They use different notations, different abstraction levels, and have different intentions. Often a specific application belongs to a class of applications, thedomain. For each domain, there are specific functional and non-functional requirements which are mapped to common functions. In each architecture, these functions are implemented by subsystems. And for the implementation of a subsystem, a developer uses a particular approach. In a given domain such as augmented reality, similar or identical approaches are used by various developers. Often this stems from the common use of software components or libraries that implement the same functionality, e.g. OpenInventor. The result is a vocabulary of common terms that are understood by most augmented reality developers. This enables discussion and comparison of software architectures. To classify the approaches, we extracted an abstract generic architecture for augmented reality systems [14] from the descriptions of existing systems. A software architecture for AR can be described by the set of approaches used in the system. While a set ofapproachesallows us to discuss existing augmented reality systems, it is only of little use for the design of new systems. For this, we must measure each approach within a certain context. The catalogue of known approaches then can mature to a system of known patterns. Each pattern must state the context where it is used, the problem it solves and the solution. In software architecture, patterns are structured descriptions of successfully applied problem-solving knowledge. Each pattern is described by name, goal, motivation, description, usability, consequences, and known use, as in [7, 16]. In this paper, we present the current state of our catalog of AR design patterns. In order to fulfill its goal of improving communication and collaboration between AR researchers, this system of patterns requires extensive discussion within the AR research community. We have set up a web site for this purpose 1 and invite members of the AR research community to join us in improving and extending the patterns. AN AUGMENTED REALITY REFERENCE MODEL A study of the various augmented reality systems [12] revealed that in spite of being quite different in detail, most augmented reality systems share a common basic architectural structure. In addition, many basic components and subhttp://wwwbruegge.in.tum.de/projects/ lehrstuhl/twiki/bin/view/ARPatterns