Framework Architecture for Virtual Environments - PDF document

1 FAVE Framework Architecture for Virtual
FAVE Framework Architecture for Virtual Environments Use case; visualisation of online CFD simulations Daniel Patel, Inge Kristian Eliassen, Tor Langeland Christian Michelsen Research P.O. Box 6031 Postterminalen N-5892 Bergen, Norway {daniel, ingekr, tor}@cmr.no 1 The FAVE framework Immersive Virtual Reality (VR) is an aid to mastering spatial complexities by

2 facilitating improved understanding of 3
facilitating improved understanding of 3D data and offering new modes of 1 . Figure 1 A possible configuration for a CAVE. Picture from http://eve.hut.fi/ 1.1 The controller building blocks FAVE consists of a collection of different controller classes. This collection can be looked upon as a toolbox for creating a VR application. What is special about t

3 he framework is that the classes in the
he framework is that the classes in the toolbox are not combined with each other in ordinary C++ fashion using aggregation and inheritance; i.e. creating new classes with controllers as members or by overloading their functions. In fact you don't need to know any programming language to create an application in terms of the objects in the toolbox. We have developed our own simple

4 language in XML to express which contro
language in XML to express which controllers to be instantiated and how they will communicate with each other. You don’t need to look at the code in the controllers to use them. A controller’s core functionality is to offer functions for other controllers to call and to create events, typically after a user interaction on the controller, for instance clicking on a butt

5 on controller. 2 The subscrip
on controller. 2 The subscription-list attribute specifies which events in other controllers will result in a function call in this controller. If the event contains arguments, the arguments will be input to the function. This is specified in a list where each element consists of the name of a controller that sends an event and the name of a function in this controller

6 that wants the event (if the sending co
that wants the event (if the sending controller sends more than one event, the event name must also be specified). We then say that the function in this controller listens to the sending controller. If a function in a controller needs to listen to many different controllers it is not necessary to list up all of them, one can instead specify in their attributes that they are part

7 of a common group and specify that the
of a common group and specify that the function listens to that group. Visually, the subscription-list will define lines connecting outports from controllers with inports of other controllers if they were drawn as in Figure 2. Figure 4 An XML setup. The NavigationController listens to (the event sent from) a walk and a fly button. 1.3 Creating new controller t

8 ypes In case the user wants an event to
ypes In case the user wants an event to call a function that is not already implemented in a controller, a new controller must be implemented with that function, or an existing controller must be extended with that function. This might seem awkward, but it forces the programmer to think object oriented. The easiest thing would be to extend an existing controller, so the programm

9 er first checks if the new function natu
er first checks if the new function naturally belongs in any of the existing controllers, if not a new controller must be created. Doing this is easy. By inheriting from the controller class all the behaviour from the 5 advantages over the first alternative; We are creating the GUI for the scenario items by using the controller building blocks. The blocks are assembled into

10 ‘aggregate objects’ using XML,
‘aggregate objects’ using XML, not by creating new C++ classes. The blocks are created at runtime, changing their looks doesn’t require recompilation. To add new or change existing scenario items is done by changing the transformation. Figure 7 The controllers and configuration needed to represent a pressure relief panel. Gray ellipses represent controlle

11 rs. The two arrows from the menu control
rs. The two arrows from the menu controller point to the two controllers the menu consists of. Dashed boxes represent events. The figures below controller mp, sl and dd represent their graphical appearance. This setup can be described in terms of FAVE XML. 9 Figure 11 Internal view of a gas leakage. Both visualisation techniques shown. 3 Conclusions This paper presents

12 FAVE and a VR application built upon it.
FAVE and a VR application built upon it. The toolbox of controllers together with the XML specification language offers a strong degree of configurability even by nonprogrammers. A higher level of configurability has been achieved by creating XML transformations from an XML document describing the looks of scenario items into the XML specification language describing these items

13 in terms of the controllers in the toolb
in terms of the controllers in the toolbox. An application communicating with CFD simulators and presenting their results has successfully been made with the FAVE framework. Links: [1] http://eve.hut.fi/cavews2003/favePerfAppPaper.pdf [2] http://www.research.att.com/sw/tools/graphviz/ [3] http://www.computit.no/ [4] http://www.gexcon.com/index.php?src=flacs/flacs.html