Explorative Construction of Virtual Worlds: An Interactive Kernel Approach Jinseok Seo and Gerard Jounghyun Kim Virtual Reality Laboratory, Department of Computer Science and Engineering, Pohang University of Science and Technology (POSTECH) San 31, Hyoja-dong, Nam-gu, Pohang, Kyungbuk, 790-784, Korea
[email protected] [email protected]
Abstract Despite steady research advances in many aspects of virtual reality, building and testing virtual worlds remains to be a very difficult process. Most virtual environments are still implemented using traditional programming language tools like compilers and debuggers. What makes virtual environment construction more difficult is that, on top of having to tackle with the traditional computational and logical errors, it is also an exploration task. Developers must find the right combination of various types of constituents of the virtual environment like the objects, display and simulation details, interaction and modalities, etc. Unlike ordinary programming tasks, for VR, the execution and development environments are different, not just in the temporal sense, but also in the physical sense. We propose that an interactive kernel approach can partly solve this problem and promote higher efficiency in VR content development. Developers can try out and explore different configurations of the constituents of the virtual environment and immediately see their impact (within the virtual world in construction) and optimize the content along the dimensions of performance, interaction usability, realism, and presence. The interactive kernel is part of “PiVOT-2 (POSTECH Virtual reality system development Tool 2),” a collection of tools that support a VR system development methodology called the “CLEVR (Concurrent and LEvel by Level Development of VR System),” previously proposed by the authors [Seo and Kim 2002]. CLEVR/PiVOT-2 is based on a flexible virtual object model called “POM (PiVOT Object Model),” that clearly segregates the aspects of form, function and behavior and the interactive kernel allows the developers to dynamically configure the respective attributes within the virtual world in construction. In this paper, we describe the details of how POM was designed, and demonstrate the effectiveness of using the interactive kernel in constructing virtual worlds. Keywords: Interactive kernel, Virtual world construction, Authoring CCS Categories: D.2.2 [Software Engineering]: Design Tools and Techniques – CASE, I.3.7 [Computer Graphics]: Three-
Dimensional Graphics and Realism – Virtual reality, I.6.5 [Simulation and Modeling]: Model Development – Modeling methodologies
1 Introduction While often touted as the next generation media for the past decade, virtual reality still has not caught on the main stream of digital media. One of the major obstacles is the lack of methodologies and tools for VR content development. Building and testing virtual worlds remains to be a very difficult process, despite steady research advances in many aspects of virtual reality. Unlike objects in other software systems, VR objects have outer appearances (form), possess basic functions and exhibit complex behaviors. However, many VR developments are based on procedural programming languages and tools like compilers and debuggers. Recent object oriented application programming interfaces (API) only provide abstractions for the system functionalities (device handling, display, etc.) However, artists and content developers (vs. programmers) like to work with “concrete” virtual objects, through reuse and composition of their forms, functions and behaviors. What makes virtual environment construction more difficult is that, on top of having to tackle with the traditional computational and logical errors, it is also an exploration task. Developers must find the right combination of various types of constituents of the virtual environment like the objects, display and simulation details, interaction and modalities, etc. However, unlike ordinary programming tasks, for VR, the execution and development environments are different, not just in the temporal sense, but also in the physical sense. Many VR systems are unusable simply because the developers are literally tired of switching back and forth between the development (e.g. desktop) and execution environments (e.g. immersive setup with HMD, glove, trackers, etc.), and fails to fully test and configure the system for usability. We propose that an interactive kernel approach can partly solve this problem and promote higher efficiency in VR content development. Developers can try out and explore different configurations of the constituents of the virtual environment and immediately see their impact (within the virtual world in construction) and optimize the content along the dimensions of performance, interaction usability, realism, and presence. The interactive kernel is part of “PiVOT-2 (POSTECH Virtual reality system development Tool 2),” a collection of tools that support a VR system development methodology called the “CLEVR (Concurrent and LEvel by Level Development of VR System),” previously proposed by the authors [Seo and Kim 2002]. CLEVR/PiVOT-2 is based on a flexible virtual object model called “POM (PiVOT Object Model),” that clearly segregates the
aspects of form, function and behavior and the interactive kernel (See Figure 1) allows the developers to dynamically configure and reuse the respective attribute models, and thus design and test virtual objects within the virtual world in construction.
of behavior specification in this work). Gaskell and Phillip’s [1995] Executable Graphical Specification (EGS) system uses the Data-Flow Diagram (DFD) notation to describe functional models. These formalisms can be executed in an interactive manner for the functionality of the system to be observed and checked. VRML also adopts this data-flow model in terms of “routes” [Hartman and Wernecke 1996]. However, these data-flow approaches are only suitable for establishing relationships among the functional modules and cannot express complex and concurrent object behaviors very well. Jacob et al. [1999] proposed a fine grained software model (and a language) for describing and programming non-WIMP (Window, Icon, Menu, Pointer) style user interactions. Jacob’s model expresses user interactions as a combination of a graph of functional relationships among continuous variables (e.g. input devices) and a set of discrete event handlers. Marigold’s [Willians and Harrison 2001] specification formalism is also designed with the notion of combining the continuous data stream (from devices) and generating meaningful discrete events for user interaction. Using the Marigold toolset, users supplement the specification with code segments, and implementation can be produced in C/Maverik [Hubbold et al. 1999]. However, these specification formalisms lack the notion for depth (e.g. hierarchy) or modularity, and so the specification can quickly become too complex to handle. Moreover, it is difficult to express synchronized behavior of interacting objects. The (simplified) semantics of the Statecharts used in PiVOT-2 can handle both hierarchical abstraction and synchronized behavior.
Figure 1. A snapshot of the interactive kernel in use. In this paper, we describe the details of how POM was designed, and demonstrate the effectiveness of using the interactive kernel in constructing virtual worlds. In the next sections, we first review work related to our research and briefly introduce the CLEVR methodology as a background for our approach. Then, we explain POM, its functionality and the design of the interactive kernel. We illustrate, with an example, how contents can be designed more intuitively using the interactive kernel and other related supporting tools. Finally, we conclude the paper with a summary and directions for future work.
2 Related Works Many researchers have proposed methodologies and tools that can ease the difficult development process for general software systems [DeMarco 1979; Fowler and Scott 1997]. For software systems that involve 3D graphics and simulation, Kim et al. [1998] developed a CASE tool called ASADAL/PROTO that seamlessly integrated constructs to specify form, function, and behavior. In fact, ASADAL/PROTO was later extended to the CLEVR/PiVoT [Seo and Kim 2002] (described later in the next section), as VR systems had additional requirements to consider such as interaction and presence. There have also been approaches to using software engineering and formal techniques for specification and verification of behaviors and functionalities of computational objects. Harel [1990] developed a graphical CASE tool, called STATEMATE, for specification, analysis, design, and documentation of large and complex reactive system. In this tool, he proposed to use “Statecharts” as a visual formalism (which is also used as a way
Behavior or function authoring using script languages has also been attempted in many tools and products, because scripting enables developers to build virtual worlds easily and rapidly. This script-based approach is best exemplified in Alice [Carnegie Mellon University 2003]. Alice also provides a predefined set of functions applicable for any generic objects which can be reused to create high-level behaviors. However, because the major objective of Alice is to design interactive 3D graphics, it lacks support for VR specific features (3D multimodal interaction, rigorous performance issues and presence). In the area of entertainment, many 3D gaming engines have also adopted this scripting approach [Conitec Corporation 2003; Radon Labs GmbH 2003; Tyberqhein 2003]. Scripts are usually associated with an interactive environment in which it is executed. Such interactive programming saves a lot of time and labor. We can confirm the potential utility of such an interactive kernel approach from the great debate about LISP vs. C as a prototyping language [Gat 2000], but more so from the proliferation of many visual RAD (Rapid Application Development) tools for 2D WIMP userinterfaces and game prototyping examples. Similar approaches in the area of virtual reality applications have also been tried. In [Bowman and Hodges 1995; Butterworth et al. 1992; Liang and Green 1994; Mine 995], users can model 3D geometric objects and arrange objects in virtual environments using 3D interaction techniques. PIP system [Lee 2001] used “programming-bydemonstration” approach [Cypher 1993] for modeling behaviors of virtual objects within the virtual environment. In this system, simple behaviors were specified and composed together through 3D interactions within the virtual environment in construction.
3 CLEVR Methodology The work described in this paper originated from an effort to establish a systematic engineering approach for VR systems called the CLEVR. The three philosophies that underlie the
CLEVR are (1) concurrent consideration of form, function, and behavior, (2) hierarchical and incremental development (exploration), and (3) the spiral development process that addresses performance, interaction modeling and presence enhancement in turn. PiVOT-2 refers to a collection of tools that would support the aforementioned engineering philosophies and the interactive kernel introduced in this paper is one of the many tools being developed for PiVOT-2. The interactive kernel is based on the clear separation of form, function and behavior (philosophy (1)), which in turn promotes reuse (mixing and matching) of object components at this level dynamically and incrementally (philosophy (3)). Thus, to understand the use of the interactive kernel, the concept of form, function and behavior must be made clear. One of the main difficulties in VR system development lies in the management of complexity. For instance, the application developer must “design” three things that are interrelated, namely, “form,” “function,” and “behavior” at the same time. Form refers to the outer appearance of virtual objects, their structure (for composite objects) and the scene structure of the virtual world. Other physical properties (which may be required for physical simulation) such as mass, material property, velocity, acceleration may be added as a part of the form information. Function refers to encoding what virtual objects do (i.e. primitive tasks) to accomplish their behavior, whether autonomously, or in response to some external stimuli or events, while behavior refers to how individual virtual objects dynamically change and carry out different functions over a period of time, usually expressed through states, exchange of events, and inter-state transitions. Most VR applications are developed in the sequence of form design, followed by function/behavior programming. The result is an unstructured code in which information regarding function, behavior, and constraints among them are all mixed in together, not readily visible for easy future maintenance and reuse. Furthermore, construction of a virtual world often requires many revisions, and changing one aspect of the world will undoubtedly affect other aspects. For instance, different shapes and configurations (positions and orientations in space) can result in different dynamic behaviors. A jet fighter has different aerodynamic characteristics from that of a passenger airplane. Form can also affect functionality. For instance, two different robot manipulators differing in size may have different work volumes and capabilities. Such a development cycle is difficult to handle when working in a single level of abstraction and considering these design spaces in isolation. A clear conceptual and computational separation among form, function and behavior helps the user explore and evolve an object by considering them in a concurrent fashion. Since virtual environment construction is a design and explorative task, the usual hierarchical and incremental approach is even more fitting than for the conventional softwares that are more algorithmic in nature. Moreover, employing the hierarchical style in the incremental development process promotes a performance conscious design by forcing the developer to focus on the more critical features in the form, function/behavior in a top-down manner. Intermediate models obtained from the hierarchical modeling approach can be used for LODs as well. At each abstraction level, in order to validate the models (e.g. behavioral correctness, visual effect, performance) and carry out further refinements, they must be simulated or executed.
4 Interactive Kernel Through the interactive kernel, developers can interactively build virtual objects and deploy them in the execution environment directly in an interpretive way using a script language (we chose “Python” [Python Software Foundation 2004]) without compilation. Although this interpretation method is slower than compilation methods, the overall performance drop is minimized by various optimization techniques [Dawson 2002]. As an analogy, it is little known that LISP programs (that are usually developed and run in an interpretive environment) can run as fast as the C counterpart contrary to many people’s belief, which is realized by code and memory management optimization techniques [Gat 2000]. Thus, for instance, we wrote most time critical part of the kernel such as the scene graph traversal, behavior simulation, and collision detection in C++ and provided abstraction through the Python language. In addition, the performance drop attributed to using scripting languages is no longer significant with the Giga-hertz processors available nowadays.
Figure 2. The overall structure of PiVOT-2 interactive kernel. The kernel can take script commands interactively or offline. It can also interpret mark up language style specifications called the PVML. Figure 2 shows the overall structure of the PiVOT-2 interactive kernel that provides the basic core for the integrated development environment (IDE). The IDE includes many support tools such as the (simplified) Statecharts editor, performance monitoring tools, and various 3D widgets such as menus and buttons. Currently, on-line and off-line Python scripts and an XML based mark up language called the PVML can be used to specify virtual objects and construct a virtual world. While it is possible that the whole virtual world be constructed interactively (using the Python script) from scratch, the usual recommended practice is to start with a static world with the basic objects and mature specifications using the off-line PVML first, then carry out the detailed design for the part that are not fully specified interactively. Note that the above IDE is not just a development environment, but also an execution environment of the same virtual world.
4.1 PiVOT object model: POM In our interactive kernel, all the objects are POM (PiVOT Object Model) objects and even the overall world is also a POM object.
In other words, all virtual objects are instances of PVObject which is the topmost class among the POM classes and the world is an instance of PVWorld, which is a subclass of PVObject. Users can create (or reuse) new (or old) POM objects by instantiating this topmost class PVObject (or extending it). There must be only one instance of the PVWorld. This instance becomes the root node of the scene graph and all other POM objects form the remaining parts of the scene graph tree as sub-nodes. Figure 3 shows the structure of a POM object as an integration of form, function, and behavior. As you can see in this figure, a POM object has its own form, functions, and behavior and exchange events with other objects. Each function does its own primitive task by manipulating and accessing the attributes of the same object’s form. Behavior invokes functions of the same object according to its states and transitions. As a result, the specification of each aspect (form, function, and behavior) of an object is dependent on one another (their representations are clearly segregated, however). These clear representations of dependent relationships among the three aspects enable the PiVOT-2 kernel to detect any inconsistency easily.
creation and a variety of geometry file formats can be imported. One POM object can have a form hierarchy using a mixture of primitive geometries and database files. Functions can access and manipulate the form (i.e. nodes in the form hierarchy).
4.3 Dynamic function programming The PVObject (the topmost class of POM class hierarchy) provides predefined primitive and useful functions (or methods) to save development time (similarly to Alice [Carnegie Mellon University 2003]). These primitive functions include manipulation of the form attributes of the object and basic animation routines (e.g. move and turn). Currently, the PVObject has seven attributes to control the position, orientation and scale. They are x, y, z, h, p, r, and scale, and their names themselves become the setter and getter functions. For example, a statement “z = object.z” invokes the getter function and “object.z = 3” does the setter, internally.
Figure 4. Adding a user-defined function to an object interactively.
Figure 3. The structure of a POM object. In the PiVOT-2 interactive kernel, there is no central procedure like the “main()” function in C or C++, and each object has its own behavior. The collaboration between objects is achieved through exchange of events as specified in their behaviors. Therefore, there is no need to insert additional code snippets into the main simulation loop in order to control the behavior of or collaboration among the objects, when new objects are created. This high-level abstraction of virtual objects leads to higher reusability in comparison to the conventional programming method.
4.2 Form modeling In this paper, we only focus on the specification of the function/behavior aspect within the realm of interactive construction of virtual worlds. This is because, as for form construction, many VR-based CAD systems have been developed [Bowman and Hodges 1995; Butterworth et al. 1992; Liang and Green 1994; Mine 1995] which are equivalent to addressing interactive form construction. In the current PiVOT-2 kernel, several primitive geometries (such as cube, sphere, cone, and cylinder) are available for direct
Thanks to the dynamic binding feature of the Python language [Python Software Foundation 2004], developers can write their own functions by composing these primitive functions (or from scratch). When writing new functions, it is also possible to utilize rich standard libraries that Python already provides. These userdefined functions can be added to the existing objects or classes, and also replace existing functions. Figure 4 shows an example of using the Python language. In this script, the new function move_and_turn is created by composing existing functions (move and turn) and added to an object duck interactively. The addFunction is also a predefined function of PVObject and this function can add additional instance methods to an object using __setattr__ and instancemethod functions that Python provides. The addition of a new function to the exiting class can be done by invoking the class function addClassFunction of PVObject.
4.4 Behavior authoring using Statecharts The behavior part of an object can be specified using a simplified version of Statecharts formalism [Harel 1990] and it manages the lifecycle of an object from its construction to destruction. This behavior specification is translated into a hierarchy of instances of PVSTM, PVState, PVTransition, and PVEvent classes. The PVSTM objects have a set of PVState objects, and can have links to a set of PVSTM objects. In this way, the behavior of an object can express parallelism and hierarchy, which are the highlighted features of the Statecharts (and underlying philosophies of the CLEVR). A PVState object has three attributes: onEnter, onDuring, and onExit. Each attribute is defined through a function call. The function on the onEnter attribute and the one on the onExit attribute are invoked only once, when a transition to this state occurs and when transition to another state occurs, respectively. The function on onDuring is executed at every simulation tick. Though the state transition formalism in Statecharts is more complex, the PVSTM only currently supports event based transitions. There are four types of events: message, timer, collision, and button (e.g. buttons of mouse, keyboard, and other
devices). We are planning to add more types of events and logical operators.
Figure 5. An example of a simplified Statecharts (in diagram only, when using PiVOT-2, the above specification would be made either through the interactive scripts or through PVML syntax). Figure 5 is an example of a simplified Statecharts (in diagram only, when using PiVOT-2, the above specification would be made either through the interactive scripts or through PVML syntax as illustrated later). In this particular case, there is only one state living except the two default states (Initial and Final.) There are two transitions from Initial to living and from living to Final, but there are no events. It means that the transitions occur without any events at the next simulation tick. The onEnter of living indicates that the init_position function must be invoked right after the transition from Initial to living occurs.
5 Example In this section, we demonstrate a more complete example application which is developed using the interactive kernel feature of the CLEVR/PiVOT-2. In this application, a number of ducks are navigating in the sea. One of them is controlled by the user with the keyboard, but others move automatically and change their orientation when they go beyond a certain preset boundary. For this simple application, we first wrote the PVML for the basic scene graph and the outlined the rough behavior of the ducks. Using the interactive kernel, the scenes were made richer in content and the behaviors of the objects (the main one being the duck’s) were further refined and detailed. The syntax of the scripts (or the PVML) for specifying the statecharts of the duck’s behavior is rather difficult, although still easier and good for future maintenance compared to coding using conventional programming languages. A preferred method is to specify statebased behaviors using a visual tool (which is one of our planned future work). Figure 10 shows the Statecharts behavior specification of the automatically navigating ducks. The largest state living is the topmost state and all the other states are sub-states of this state. When the living state is activated, the function init_position() in the onEnter attribute is invoked. In init_position(), a duck is positioned at a random position on the sea. Figure 10 also shows an example of concurrent states. The left part specify the basic movement of ducks, and the right, the rolling movement. When we import the file “ducksworld.pvml” (see Figure 6) that includes the initial specification of Figure 10 into the interactive kernel, we can immediately see the ducks navigating on the sea. Now, we are ready to further refine the behavior of ducks interactively as we observe the overall scene. First, we wanted the ducks to make a pitch motion in order to express effects of the
Figure 6. Part of “ducksworld.pvml.” (we have intentionally omitted and folded some part due to limited space). In this file, the Duck class is defined with a form node, few functions, and two parallel “stms” (the one corresponding to the right part of Figure 10 is folded). waves. Pitching motion can be achieved by appropriately setting the z coordinates of objects. But, what values would be appropriate? In conventional compilation methods, we would choose an arbitrary value, compile the code, and verify the result. If the result was not satisfactory, we would have to repeat the above process many times. Such explorative trials are made easier with the interactive method. PVObject has three attributes (x, y, and z) to control the position. Therefore, just typing a script “duck.z = 1.5” for instance immediately shows the effect. After few trials, we decided that the maximum and minimum z values should be 1 and -1. Then, we used the sine function to make the movement more natural. In order to achieve this, we defined two functions. Figure 7 shows the code of the two functions. The first function init_angle assigns the initial value 0 to the member variable of ducks self.angle. The second function change_height
changes the height of ducks (by assigning new values to the attribute z) while calculating the sine function and incrementing self.angle. We verified the pitching movement by invoking change_height a number of times. However, in order to verify the result of this type of animation more exactly, change_height function should be invoked very quickly and many times. Therefore, we refined the going (see Figure 8) state and added a sub-state waving. init_angle() was assigned to onEnter of the new state and change_height() was assigned to onDuring. A new transition from the initial state to waving is also added to subPVSTM of going. Because of this transition has no event, the transition occurs automatically. We can now see ducks pitch up and down repeatedly.
progress is domain customization. While the interactive kernel is powerful in its capabilities, to be attractive to content designers, further abstractions must be made for small restricted domains.
Acknowledgments This work was supported in part by the BK 21 program of the Korean Ministry of Education, ITRC program of the Korean Ministry of Information and Communication, and the POSTECH Internal Research Initiative Program.
References BOWMAN, D., and HODGES, L. 1995. User Interface Constraints for Immersive Virtual Environment Applications, Technical Report of Graphics, Visualization, and Usability Center, Georgia Institute of Technology, GIT-GVU-95-26. BUTTERWORTH, J., DAVIDSON, A., HENCH, S., and OLANO, T. M. 1995. 3DM: A Three Dimensional Modeler Using a Head-Mounted Display, In Proceedings of Symposium on Interactive 3D Graphics, pp. 135-138. CARNEGIE MELLON UNIVERSITY. 2003. Alice: Free, Easy, Interactive 3D Graphics for the WWW, Retrieved Dec. 16, 2003 from the World Wide Web: http://www.alice.org.
Figure 7. Two new functions for ducks.
CONITEC CORPORATION. 2003. 3D GameStudio, Retrieved Dec. 16, 2003 from the World Wide Web: http://conitec.net/a4info.htm. CYPHER, A. 1993. Watch what I do: programming by demonstration, MIT Press. DAWSON, B. 2002. Game Scripting in Python, GDC Proceedings. DEMARCO, T. 1979. Structured Analysis and System Specification. Yourdon, New York. FOWLER, M., and SCOTT, K. 1997. UML Distilled: Applying the Standard Object Modeling Language. Addison Wesley, New York. GAT, E. 2000. Lisp as an alternative to Java, Intelligence, 11, 4, 21-24.
Figure 8. Refinement of “going” state.
GASKELL, C., and PHILLIPS, R. 1995. Software Architecture of the executable graphical specification tool EGS, Software-Concepts and Tools, 16, 3, 124-135.
In current “ducksworld,” ducks are changing their orientation when they go out of range. We wanted the ducks to turn when they collided with others. We only have to add two more transitions from going to changing in this case. Figure 9 shows the script command to add the two transitions. Figure 11 is the resultant specification of all the refinements.
HAREL, D. 1990. STATEMATE: A Working Environment for the Development of Complex Reactive Systems, IEEE Transactions on Software Engineering, 16, 4, 403-414.
Figure 9. Two additional transitions from the “going” state.
7 Conclusion and Future Works In this paper, we presented an interactive kernel for explorative virtual world construction, as part of our VR system development methodology CLEVR/PiVOT-2. The kernel is based on a flexible object model (POM), and when used appropriately with off-line mark up specification like the PVML, it can help fine tune the virtual world in construction fast. The POM reduces the inherent complexity of virtual objects by providing an integrated and highlevel object model for virtual objects and formalizing behavior through the use of Statecharts. Our goal is to build easy-to-use visual tools such as Statecharts drawer and other tools to support the CLEVR. Another work in
HARTMAN, J. and WERNECKE, J. 1996. The VRML 2.0 Handbook, Addison Wesley. HUBBOLD, R., COOK, J., KEATES, M., GIBSON, S., HOWARD, T., MURTA, A., WEST, A., and PETTIFER, S. 1999. GNU/MAVERIK: A microkernel for large-scale virtual environments, Proceedings of ACM Symposium on Virtual Reality Software and Technology, 66-73. JACOB, R., DELIGIANNIDIS, L., and MORRISON, S. 1999. A Software Model and Specification Language for Non-WIMP User Interface, ACM Transactions on Computer-Human Interaction, 6, 1, 1-46. KIM, G. J., KANG, K. C., KIM, H. J., and LEE, J. Y. 1998. Software Engineering of Virtual Worlds, Proceedings of the ACM Symposium on Virtual Reality Software and Technology, 131-138. LEE, G. A. 2001. Modeling Virtual Object Behavior within Virtual Environment, Master thesis, Division of Electrical and Computer Engineering, POSTECH, Pohang, Korea. LIANG, J., and GREEN, M. 1994. JDCAD: A Highly Interactive 3D Modeling System, Computer & Graphics, 18, 4, pp. 499-506. MINE, M. R. 1995. ISSAC: A Virtual Environment Tool for the Interactive Construction of Virtual Worlds, Technical Report of Dept. of Computer Science, UNC Chapel Hill, CSTR95-020.
PYTHON SOFTWARE FOUNDATION. 2004. Python Programming Language, Retrieved Mar. 8, 2004 from the World Wide Web: http://www.python.org.
TYBERQHEIN, J. 2003. Crystal Space 3D, Retrieved Dec. 16, 2003 from the World Wide Web: http:// crystal.sourceforge.net/tikiwiki/tikiview_articles.php.
RADON LABS GMBH. 2003. The Nebula Device, Retrieved Dec. 16, 2003 from the World Wide Web: http://www.radonlabs.de/nebula.html.
WILLIANS, J. S., and HARRISON, M. D. 2001. A toolset supported approach for designing and testing virtual environment interaction techniques, International Journal of Human Computer Studies, 55, 2, pp 145-165.
SEO, J. S., and KIM, G. J. 2002. Design for Presence: A Structured Approach to Virtual Reality System Design, Presence: Teleoperators and Virtual Environments, 11, 4, 378-403.
Figure 10. The Statecharts of Duck class.
Figure 11. The refined Statecharts of Duck class.
