A Visit to the Dresden Frauenkirche and Peter D
Total Page:16
File Type:pdf, Size:1020Kb
Reza Jalili A Visit to the Dresden Frauenkirche and Peter D. Kirchner IBM Research Division T. J. Watson Research Center Yorktown Heights, NY 10598 Abstract Jorge Montoya and The Frauenkirche was destroyed when Dresden was bombed by the Allied forces Feb- Stephen Duncan ruary 13-14, 1945. The church is now being reconstructed in an effort led by the Research Triangle Institute Foundation for the Reconstruction of the Frauenkirche. The VRDECK software package Research Triangle Park, NC 27709 developed at the IBM T. J. Watson Research Center was used to view and walk through a model created from the original church plans. A Polhemus tracker and a cus- Luc Genevriez tom-built joystick using the Logitech 3D mouse were used for six-degree-of-freedom I I Rue Ledru-Rollin input to the application. The interactive fly-through of the church is in an immersive 92500 Rueil-Malmaison, France environment. One can navigate around the model wearing a head-mounted display, sitting in front of a standard monitor, looking at a stereo image produced on a stereo James S. Lipscomb monitor, or standing before a projection screen displaying a stereo image of the scene. Robert H. Wolfe The system was developed for and exhibited at the IBM booth in the CeBIT fair in Han- and nover, Germany in March 1994 with funding from IBM Germany. Christopher F. Codella IBM Research Division T. J. Watson Research Center I Introduction Yorktown Heights, NY 10598 The Frauenkirche was destroyed when Dresden was bombed by the Al- lied forces February 13-14, 1945. The church is now being reconstructed in an effort led by the Foundation for the Reconstruction of the Frauenkirche (Whit- ney, 1994). The original plans were used to create a computer model of the church to aid the reconstruction effort. From that model, a more elaborate and aesthetically accurate model was developed. Those models were then made available for the project that is described in this paper. The goal of the public exhibit was to produce a realistic experience of being inside the church as it would have looked before the war. The Frauenkirche exhibit made use of the best technology available to us to produce such an im- mersive walkthrough experience. In Section 2 we briefly describe the software architecture used to build the distributed application. 2 VRDECK Software 2.1 General Overview The Frauenkirche virtual reality exhibit was developed using two worksta- tions, each handling part of the necessary tasks. The VRDECK software was used to distribute, define, invoke and monitor, and control the tasks. This section reviews the design and operation of the VRDECK, Virtual Re- et Presence, Vol. 5. No. I. Winter 1996. 87-94 ality Distributed Environment and Construction Kit (Codella al., 1993) de- © 1996 by the Massachusetts Institute of Technology veloped at the IBM T. J. Watson Research Center. Ease of use was emphasized Jalili et al. 87 Downloaded from http://www.mitpressjournals.org/doi/pdf/10.1162/pres.1996.5.1.87 by guest on 23 September 2021 88 PRESENCE: VOLUME 5, NUMBER I both for the application builder and the toolkit extender. mie ExampleRuleName when(DataTypeA InEvent) Under an extensible architecture, the system supports produceCDataTypeB OutEvent) the distribution of and the processes building of mul- { tiuser shared environments. Specialized I/O devices are // some C++ code which can read data from InEvent supported with prebuilt exécutables for interfacing with // some C++ code which can write data to OutEvent gloves, three-dimensional (3D) position sensors, sound if (condition) produce(OutEvent); }; generators, speech recognizers, and 3D graphics dis- plays. Virtual world environments are created using a • ExampleRuleName is the name of this particular rule. mixed object-oriented and event-based paradigm for • DataTypeA and DataTypeB are built-in or user defined types (classes or structs). behavior. defining system • InEvent is the identifier of the input or triggering event whose data type is DataTypeA Basic units, called modules, represent entities in the • OutEvent is the name of a possible output event whose data type is DataTypeB. world such as objects, operations, functions, or users. Modules are always separate exécutables, and can be dis- Figure I. An example showing the rule syntax. tributed across a network. Modules communicate with each other by producing and consuming events, and are defined at a high-level using rules written in C+ + that determine how events are handled. The toolkit includes vices and simulators. Extensive run-time support trans- a development environment consisting of C+ + class parently handles event queuing, matching of events to libraries for module construction, communication, and rules that process the events, intermodule event and data device support. The intermodule and intramodule event transport, networking support, I/O device support, and communications are handled transparently by the interfaces to the X Window System®. This run-time VRDECK code. support, contained within C++ class libraries, is de- The run-time environment includes a GUI control signed to relieve the world designer from low-level sys- panel for dynamically constructing an application from a tems issues. It also provides the toolkit extender with a collection of modules, allocating processes among hosts, rich set of facilities upon which to enhance the base sys- saving configurations, and monitoring application op- tem. eration. A set of modules for various devices and a li- A module's rules describe (1) events of interest, (2) brary of classes for common operations facilitate applica- events it may generate, and (3) code to implement the tion construction. behavior of the module (see Fig. 1). When a module receives an event, it determines which of its rules have an interest and the event to those rule for 2.2 Modules, Rules, Events passes objects processing. When passed an event, a rule determines Modules can be thought of as the building blocks whether it is triggered by that event. If so, the rule ex- of a virtual world. They usually represent discrete objects ecutes its body ofC+ + (or C) code, which may itself or collections of objects, specific services (like I/O device cause the production of new events. An event's data type servers), or functions that can be encapsulated (like information is checked when it is received by a module simulators). Intra- and intermodule communication oc- to ensure that the type of the event matches the type of curs via events. Events are defined as discrete occur- the data expected by the rules. This helps prevent errone- rences broadcast to other modules. In addition to an ous interpretation of the data. identifier or name, an event carries a strongly typed data Events may be produced outside of rulesets by object (possibly void). The external view of a module is explicitly calling the ModuleClass member-function defined by the events it produces and consumes. ProduceEventQ with the event name, data type, and event A module, at its highest level, is a collection of rules to data and size. Rule bodies can, therefore, call subrou- handle the processing of events generated by the mod- tines that produce events. Moreover, input device drivers ule, other modules, or external sources such as I/O de- use this ProduceEvent method to package data into events. Downloaded from http://www.mitpressjournals.org/doi/pdf/10.1162/pres.1996.5.1.87 by guest on 23 September 2021 Jalili et al. 89 Events received and produced may be either built-in Network Connection types (e.g., int, float, char), or user-defined types (i.e., classes or structs). In the simplest cases, built-in types can be used and their value assigned or read just as with normal variables ofthat type. If no data are to be associ- ated with an event, the type may be specified as "void." Events of type "void" are often simply used as flags to rules. trigger Workstation 1 Workstation 2 In a rule definition, the when() clause (see 1) lists Fig. RS-232 a group of input events that must be received before the Serial Line code in the rule body will be executed. At least one input event must be specified. If only one event is specified, as (Tracker Hardware Stereo Monitor in the rule time an event with Figure 1, triggers every Head-mounted Joystick Hardwan the specified identifier is received. If more than one event Display is a conditional function must be specified, provided, Large-screen indicating the condition under which the rule will be Stereo Projector Head Four-button The built-in conditional functions are triggered. and, Position Joystick then, and followed by. They may not be mixed within Sensor the same when() clause. Figure 2. System diagram of the Frauenkirche walkthrough application. Software components are represented as elipses. Hardware components are represented by blocks. 3 Building the Walkthrough Application 3.1 Application Overview Application Tracker VRDECK was used to put together a set of soft- ware components that as a set form the Frauenkirche walkthrough application. The complete system is made up of some specialized hardware and software. Figure 2 shows a block diagram of the system components. Fig- ure 3 shows module connections. These connections happen to use sockets and communicate via TCP/IP. The process of building the Frauenkirche application can be outlined as shown below: • Translate the model (geometry, textures, materials, and lighting) from the TDI format to one usable by the Performer library. • Preview the model.1 Figure 3. The application is connected to the tracker module and also • model as until is Simplify necessary performance to the joystick module. maximized. • Write a renderer to load and display the model in • Write a VRDECK ruleset to handle the tracker stereo.