Software Engineering of Virtual Environments:Integration and Interconnection
D. Welch,James M. Purtilo
1998-10-15
Abstract:Virtual Environments(VEs) are proving to be valuable resources in many elds, and they are even more useful when they involve multiple users in distributed environments. Many useful VEs were designed to be stand-alone applications, without consideration for integrating them into a distributed VE. Our approach to connecting VEs is to de ne an abstract model for the interconnection, use integration tools to do as much of the work automatically as possible, and use a run-time environment to support the interconnection. With our experiences to date, we are learning that certain classes of techniques are common to all solutions using this approach. We have summarized these in a set of requirements and are building a system that features these techniques as rst class objects. In the future you will be able to solve these interconnection problems cheaply, plus engineers of future VEs will have some guidance on how they should organize their implementations so that interconnection with other VEs will be easier. In this paper we coin the phrase software engineering of virtual environments (SEVE) to describe the above activities. INTRODUCTION Virtual Environments (which include virtual reality, simulation, and telepresence) are being applied successfully to many di erent applications. As we found with other computer applications, VEs are even more powerful when they cooperate over networks. Currently distributed multi-user VEs, can be built from scratch or from existing VEs by manually integrating them into a distributed VE. A system developed from the start as a distributed VE will have many advantages, and there are a number of software engineering tools to make this task easier. However, the cost of developing new code is high even with software engineering support and may not always provide low-enough cost products. There are real advantages to re-using existing code. However, due to the complexity of VEs the process of manually integrating legacy systems is laborious and ripe with opportunities for error. The resulting system is still not guaranteed to be any easier to integrate the next time. Many of the VEs currently in use were built without any consideration to integrating them with other systems into a distributed VE. Design decisions for stand-alone VEs were made to optimize that one system; as a result VEs can have very di erent architectures. If distributed VEs are going to become widespread, then SEVE must make it easier to build them and reuse existing code. Universal standards and interpreted languages may solve this problem once and for all in the future, but there are too many existing systems to write them all o just yet. Most of the research on building distributed multi-user VEs concentrates on designing the distributed VEs from scratch. The EM toolkit and DIVE environment are two of the best known systems. They provide an environment for building the entire VE to include interconnection.[WGS95] [Gre94] Virtual Design is another complete VE software engineering environment that also focuses on using a wide array of input data and hardware.[AFM93] DoD's Distributed Interactive Simulation (DIS) de nes a standard for how VEs interact, but not how to meet that standard. There are tools developed to help developers meet that standard, but not to retrot existing VEs.[Com94] BrickNet uses an interpreted language to facilitate sharing object behaviors between VEs.[SSP+95] VRML is also an interpreted language that as of version 1.0 does not support connected VEs. There has been little research on how to retro t legacy systems into distributed VEs.[DPCS96] REQUIREMENTS FOR VE INTEGRATION In this section we lay out the functional requirements for SEVE. The non-functional requirements have been discussed elsewhere [DPCS96] and are beyond the scope of this paper. We use a running example to illustrate the requirements for a SEVE environment. Our example takes two existing simulators and integrates them into a distributed simulation to give the soldiers being trained the challenge of ghting a human opponent, vice a simulated opponent. The rst is a ight simulator for an Apache attack helicopter. The simulator has two users, a pilot and gunner and is a stand-alone system. Most of the C code is devoted to simulating the ight dynamics of the Apache and controlling the displays in the simulator. The second simulator is a Bradley Infantry Fighting Vehicle simulator (BIFV). It is designed to work with other BIFV simulators so that crews can train in the sim1 ulators as a group. The ground soldiers that ride in the back have head mounted displays and can move outside the BIFV as they can in real life. The Ada code controls the shared virtual environment of the BIFVs as well as the virtual reality in the simulation. They each have their own events, data model, etc. The Apache has behaviors of interest to the BIFVs scattered throughout its code. This integration is tedious and fraught with risk. Maintain the Object Hierarchy/Groupings When information is passed between VEs, the runtime environment must keep track of the objects that the information pertains to. In our example, such an association might be between soldiers and vehicles: when the squad is riding in a BIFV the members move as the BIFV moves, and when they dismount their locations must be tracked separately from the BIFV. Translate the Reference Frames In a VE there may be multiple reference frames, e.g. object, observer, or world. Applications may use entirely di erent coordinate systems. There are numerous world coordinate systems to choose from when using geographic coordinates. In addition, coordinates are commonly speci ed in meters or some other physical measure. The translation must be invisible to the individual VEs. When the Apache launches a Hell re missile, the Apache tracks the missile's ight using its own reference frame and coordinate system. To render the missile the BIFV requires information in its world reference frame. The BIFV simulator must not have to know about the Apache's reference frame and coordinate system to render the missile. Abstract the Communication VEs can have varied communication requirements and the engineer must be shielded from the implementation details. In most cases fast transmission time is key, but sometimes reliable communication is required. As an example, when a BIFV rotates its turret, that change can be sent by a fast-unreliable message. If the message is lost, then the next update will bring the system to the correct state. However, when the Apache joins the simulation, the passing of initial states must be done reliably, but speed is not as important. The type of message (light-weight object, network pointer, heavy-weight or real-time stream) as well as the recipients of the message (multi-casting) must be accessible to the programmer as a simple abstraction. [BMZ95] [MZP+95] If VEs are only to receive pertinent messages, the run-time environment must have the logic to decide which entities get which messages. In a simulation such as this example, multi-casting is not critical, but if there were a brigade's worth of BIFVs instead of a platoon the Apache would not have to know about the turret direction of every BIFV, only those within 10 kilometers of it. The multi-cast groups the Apache must monitor change as the Apache moves about the simulated battle eld. The logic to handle these changes is best handled in the run-time environment and not the existing code. Provide Concurrency Control Objects that are shared by multiple VEs must be protected to insure consistency. When a Hell re missile is approaching a BIFV that is taking evasive action, without concurrency control the last action (maneuver or hit) would be the resulting state in the system. This is the opposite behavior from what we would like. The concurrency control must have ne enough granularity to protect di erent aspects of an object such as degrees of freedom. This allows cooperative behavior to exist in the distributed system. When the soldiers dismount in our scenario, two may push on an obstacle at the same time. Concurrency control must insure that the obstacle reacts realistically. Collision detection between objects from di erent VEs must also be handled in the run-time environment. Not only should the run-time be able to stop two objects from occupying the same virtual space, but it should also stop objects from passing through each other due to unequal or inadequate update rates. Rounds red from the BIFV's 20mm cannon will cover large distances between updates. The system cannot let the Apache avoid hits because at t0 the round was 15 meters short of the Apache and at t1 it was 15 meters beyond it. Translate Behaviors The behaviors that objects exhibit and constraints imposed on those objects can be very complex. The behaviors and constraints that are needed in a connected VE should not have to be completely rewritten in that VE. The code to 2 simulate the behavior of the BIFVs smoke grenades is very complex and would not previously exist in the Apache simulator. Such characteristics as the location, size and density are too complex to be passed as a message, so the behavior will have to be coded into the Apache simulator and just the parameters passed during the simulation. Since the two simulators use di erent programming languages and graphics packages, translating the behavior is not just cut and paste. The integration environment must give the software engineer as much help as is possible with this task. Direct translation of object methods such as CORBA architectures provide is not always appropriate. In our smoke grenade example, the BIFVs would need accurate (and computationally intensive) simulation of the smoke screen for a good training environment. In the Apache simulation a much rougher approximation would be appropriate, so as to not take the cpu cycles needed for the ight dynamics. Translate Data Distribution Models There ar