Battle Explorer: VRML Technology for Replaying and Analyzing DIS Exercises

Eric W. Johnson , Michael R. Kappel, Julia J. Loughran

Institute for Defense Analyses

1801 N. Beauregard St.

Alexandria, VA 22311

ejohnson@ida.org , mkappel@sentel.com, jloughran@ida.org

 

Keywords:

VRML, DIS, simulation, 3D visualization

 

ABSTRACT: The Virtual Reality Modeling Language (VRML) is a new technology for building, transporting, and displaying interactive 3D worlds.  A dynamic VRML world can be stored in a relatively compact ASCII file that can be replayed on a variety of platforms and made available over the World Wide Web. The replay and analysis of Distributed Interactive Simulation (DIS) exercises is a promising application area for VRML.  Traditionally, applications which replay DIS exercises in 3D have required high-end hardware and specialized software.  The rapid increase in the computing power of PCs together with the development of VRML make it possible to replay and analyze DIS simulations using readily available hardware and software. The fact that VRML worlds are accessible over the World Wide Web makes VRML an excellent medium for distributing DIS simulations to analysts and trainers.  This paper describes work conducted at IDA to build Battle Explorer, a prototype VRML application for replaying and analyzing DIS exercises.  The report discusses both the advantages and limitations that we found during our experiments with Battle Explorer.

 


1.                 Introduction

The Virtual Reality Modeling Language (VRML) is a new technology for building, transporting, and displaying interactive 3D worlds.  This report describes work conducted at IDA to build Battle Explorer, a prototype VRML application for replaying and analyzing Distributed Interactive Simulation (DIS) exercises.

1.1     Introduction to VRML

The development of VRML can be seen as part of the evolution of the World Wide Web to incorporate increasingly diverse forms of multimedia content.  Initially, the content available on the World Wide Web consisted primarily of text and static images.  Later, standards were developed to enable web sites to include sound, video, and software applications written in Java and JavaScript. VRML makes it possible for Web sites to contain virtual worlds. 

The person viewing a VRML world is immersed within a synthetic three-dimensional space.  Using on-screen navigational aids, the person viewing a VRML world can fly through the world and "look around" to see 3D objects from any perspective.  VRML worlds are dynamic: objects can move along preset trajectories or under the control of software scripts associated with each object.  VRML also includes facilities for creating terrain, for mapping textures onto objects, and for associating sounds with objects.

VRML 1.0, a specification describing only static worlds, was recognized by industry leaders as a standard in the spring of 1995.  The VRML 2.0 specification describing dynamic worlds was accepted as a standard in the fall of 1996.  The experiments described in this report were conducted using Cosmo Player, a VRML 2.0 browser produced by Silicon Graphics.  At the time our experiments were conducted, a beta version of Cosmo Player was available as a plug-in module for Netscape Navigator.  Late in the spring of 1997, Cosmo Player became a standard component distributed with Netscape Communicator.   In this report, we will use the term VRML to refer to the VRML 2.0 specification.

1.2     Viewing VRML Worlds

VRML worlds are stored as ASCII files which can be viewed in several different ways:

·   A web browser capable of viewing VRML files can be used to explicitly load a VRML world.

·   Links to VRML files can be included in HTML documents.  For example, an HTML document could include a statement such as "to see visualization X, click here."  When a reader clicks on "click here," a VRML-capable web browser will open a new window displaying the VRML visualization.

·   At the time our experiments were conducted, several commercial projects to build ActiveX VRML controls were close to completion.  When these controls are available, it will be possible to incorporate VRML visualizations into Microsoft Word and PowerPoint files.

2.                 Battle Explorer

As part of an earlier task, IDA developed data collection, reduction, and analysis techniques to assist in the analysis of simulation training data from the Virtual Training Program at Fort Knox [[1]].  As part of that effort, IDA developed software to reduce binary SIMNET logger files into a standard ASCII file format which we call Leaf (Logged Event Analysis Format) [[2]]. Leaf files are typically more than 50 times smaller than the corresponding binary logger files¾the reduction in size is achieved by extracting only the information that is likely to be needed to support after action reviews and simulation analysis.

Using internal research and development funds, IDA developed Battle Explorer, prototype software which converts the set of Leaf files describing an exercise into a set of VRML files that can be viewed using a VRML-capable web browser. 

Once the VRML files produced by Battle Explorer are loaded into a browser, the user can replay the exercise in interactive, dynamic 3D.  The VRML browser handles such tasks as rendering the terrain, producing smooth motion for vehicles, and recomputing the scene each time the viewer's location  changes.

In our current prototype, users can pause and restart the replay of an exercise and can choose to watch the replay from a number of different predefined viewpoints.  In future versions of Battle Explorer, it might be possible for users to jump to arbitrary times in an exercise and perhaps to particular key events as well.

3.                 Applications of Battle Explorer

The VRML technology prototyped in Battle Explorer can potentially be applied in a number of areas related to simulation-based training and analysis.  Some potential applications for Battle Explorer are as follows.

3.1     Enhanced Training Feedback

Currently at Ft. Knox's Virtual Training Program, a Take Home Package consists of an Excel spreadsheet which provides assessments (either Train to Sustain or Train to Improve) for each task in each exercise that was trained.  A Take Home Package also includes a Word document which provides written comments about a unit's performance.  An HTML/VRML Take Home Package or a Word/ActiveX/VRML Take Home Package could include visualizations of key events from the exercises that are being reviewed.

If sample VRML exercises were available over the World Wide Web, units could prepare for upcoming training sessions by reviewing both positive and negative examples of the execution of each training exercise.

3.2     Enhanced Instructional  Materials

Manuals describing tank platoon doctrine currently rely primarily on static line-drawings to illustrate complex platoon operations and maneuvers.  Using the technology prototyped by Battle Explorer, printed training materials could be augmented with interactive documents in which platoon maneuvers are demonstrated using VRML visualizations.  The VRML visualizations for such training materials could be created by experienced tank platoons using the simulation facilities at a virtual training site such as Fort Knox.

The ability to include VRML visualizations within electronic documents could also be useful to analysts writing reports about simulation-based experiments.  For example, a report about a particular exercise could contain a comment such as "Notice that tank 3 failed to come on line when the battle began [see visualization 1]."  When a reader clicked on "see visualization 1," the reader would enter a 3D world in which the reader could navigate around to see exactly where tank 3 was at the relevant point in the exercise.

3.3     Distance Learning

Interactive VRML instructional materials could be made available to students inexpensively and conveniently via the World Wide Web.  A number of projects are currently underway in the VRML community to extend VRML to allow participants at multiple sites to interact within a single VRML world. These new technologies will make it possible for an instructor and student  at different sites to both be "present" within a VRML visualization.  Using these technologies, for example, a teacher could point out key events in a simulation to students at remote sites.

3.4                    New Kinds of Analysis Tools

In the VRML visualizations produced by Battle Explorer, we added a feature that uses 3D, color-coded bars above each vehicle in an exercise to indicate the vehicle's shots, hits, and kills.  Other kinds of visual measures that could be added to a visualization include the speed of vehicles, the range of shots, gun turret scanning areas, and indications of when red vehicles become visible to blue vehicles. 

The interactive 3D programming facilities supported by VRML provide a flexible environment for experimenting with new visualization and analysis techniques.

4.                 File Sizes and Performance

The VRML terrain file containing the 10,000 elevation points needed to specify a 10-kilometer by 10-kilometer patch of the National Training Center terrain at 100-meter intervals requires approximately 180 Kbytes of ASCII storage. 

The exercises that we received from the Virtual Training Program at Fort Knox typically last for about 15 minutes and contain about 12 tanks. The SIMNET binary logger files for each exercise typically contain about 25 Mbytes of  data when compressed and 125 Mbytes of data when uncompressed.

Not counting the 180 Kbytes needed for the terrain file, the set of VRML files needed to replay a 15-minute, 12-vehicle exercise typically requires less than 200 Kbytes of ASCII text.  Consequently, the complete set of files needed to replay an exercise typically requires less than 400 Kbytes of uncompressed ASCII text.  Since multiple exercises can use the same terrain file, this means that it might be possible to place up to six exercises on a single floppy disc. 

Cosmo Player did an excellent job of rendering the 10,000 elevation points in our map as smooth, naturally shaded terrain.  The VRML visualization created by Battle Explorer for each exercise allows a user to watch the exercise from  four different types of  viewpoints:

·   Looking directly ahead from any of the tanks in the exercise (the commander's viewpoint).

·   Looking along the gun of any tank (the gunner's viewpoint).

·   Looking forward from approximately several meters behind and slightly above any of the tanks in the exercise (the tethered viewpoint).

·   Looking down from 100 meters directly above any of the tanks in the exercise (the bird's-eye viewpoint).

As long as the user was attached to one of the four viewpoints described above, Cosmo Player was able to replay exercises at a natural speed on a 100 MHz 486 PC running Windows 95 with 32 Mbytes of memory. 

As discussed earlier, VRML browsers are designed to support "free flight" mode in which a user uses navigation controls in the browser to fly around the virtual world.  Unfortunately, we were not able to get free flight mode to work with Battle Explorer, even on a 200 MHz Pentium Pro.  We suspect that our inability to get free flight mode to work was due to some sort of bug in the version of Cosmo Player that we used. 

We plan to make a demo of Battle Explorer available over the Web.  Please see http://www.ida.org/vtr for details.

5.                 Details of the Experiment

5.1     Terrain

VRML provides a language primitive, ElevationGrid, to model 3D terrain.  Based on a 2D grid of elevation values, the VRML browser renders the 3D terrain.  In our experiments, we used  a 10-kilometer by 10-kilometer patch of the National Training Center terrain sampled at 100 meter increments¾larger terrain samples could not be handled at reasonable speeds on a 100 MHz 486 PC with 32 Mbytes of memory. 

By making minor modifications to the ModSAF source code, we developed a utility which converts terrain data from the format used by ModSAF into an ASCII file of elevation values in VRML format. Even without the remaining pieces of Battle Explorer, the ability to visualize  ModSAF terrain using a VRML browser is a potentially useful capability.

Two approaches to coloring  the terrain were tested.  In the first approach, colors representing different soil types were obtained from the ModSAF terrain database and output in VRML format.  In the second approach, a bitmap image of the ModSAF Plan View Display was captured that included soil type regions, road networks, grid lines, and rivers.  The bitmap was used to specify a VRML texture map which Cosmo Player draped across the landscape. 

VRML features for rendering blue sky and sunlight were used to add realism to the simulation.

5.2     Vehicles

A VRML model of a tank was constructed using VRML shape primitives such as cylinders, boxes, and spheres. In a Battle Explorer visualization, tanks move smoothly and gun turrets scan back and forth smoothly based on position and gun turret data extracted from the Leaf files discussed earlier.

Tanks are animated using the VRML constructs PositionInterpolator and OrientationInterpolator.  Clock tick events generated by the VRML TimeSensor are routed into the interpolators to position and orient each tank's hull and gun turret.

5.3     Fire Events

In a Battle Explorer visualization, two fireballs are created for each tank¾one for representing fire events and the other for representing impacts.  (The fireballs are created by combining several VRML cones.) After each fire event, a VRML script positions one of the two fireballs at the end of the gun turret for three seconds and then moves the fireball off-screen.  After a two-second delay (a more exact time could have been calculated), the other fireball is positioned at the impact point and after three more seconds moved off-screen.

5.4     Time

Because it is easy to encode cycles within VRML, Battle Explorer VRML files are designed to replay a simulation exercise over and over again indefinitely.  In our first prototypes, when a VRML file was loaded, an exercise would start at an apparently random point¾the point where it would have been if the simulation had kept running while the world wasn't loaded.  Later, we wrote a VRML script to filter clock activation events to compensate for this problem.

It is interesting to note that VRML applications typically use real world rather than relative time in order to give the impression that events within a VRML world continue to evolve even when the world isn't loaded in a browser.  VRML is designed to make it easy, for example, to design a world that cycles through four seasons during a year of real world time. Users who happened to load the world into a browser during the real world month of January would see snow.  Users who happened to load the world during the real world month of July would see green grass. 

5.5     Controlling the Simulation

Silicon Graphics has developed an External Authoring Interface (EAI) that is designed to allow a Java or

JavaScript program running in a web browser to control a VRML world by calling VRML scripts that are part of the world that is being viewed. At the time our experiments were performed, however, communication between Cosmo Player and the Netscape browser in which it was running didn't seem to be fully implemented.

Our first solution to the problem of controlling a simulation was to add a 3D cube to each simulation that would start and stop the simulation each time the cube was clicked by a user.  Later, we replaced the start/stop cube by associating a touch sensor which each tank so that a user could start and stop an exercise simply by clicking on a vehicle.

In our first prototypes, the VRML clock would continue running even when a simulation was stopped. Once the simulation was restarted, the simulation would jump to the point where it would have been if it had never been stopped.  As was the case with starting and stopping the browser, we wrote VRML scripts to compensate for this problem.

5.6     File Structure

A Battle Explorer visualization consists of four VRML files¾the main exercise file, the tank definition file, the explosion definition file, and the terrain file. The tank definition file provides a generic definition of the appearance and behavior of a tank.  The explosion definition file describes a generic 3D fireball. Each main exercise file instantiates numerous tanks by referencing the tank file and specifying the set of position coordinates, orientations, and shot data for each tank.  (The generic tank and explosion definition files together require approximately 11 Kbytes of ASCII text.)

The tank, explosion, and terrain definition files are static and single copies of these files can be used by multiple exercise files.  A browser running Battle Explorer over the Web could potentially cache the static terrain, tank, and explosion definition files and thus avoid transferring them each time a new exercise is played.

6.                 Limitations Encountered

6.1     Terrain

Cosmo Player creates smooth terrain by interpolating between elevation posts that in our experiments were 100 meters apart. Cosmo Player simulates smooth motion for vehicles by interpolating between position readings that in our experiments were approximately 5 seconds apart.  The fact that terrain and vehicle interpolations are done independently means that on occasion Battle Explorer visualizations show tanks traveling underground or flying just above the surface.

More experiments will be needed to solve this problem.  One solution might be to increase the resolution of the terrain and the number of position readings provided.  A problem with this approach is that increased terrain resolution may require more performance than lower-end PCs can provide, thus limiting the number of people who can use the technology.

6.2     Development Environment

At the time our experiments were conducted, only a beta version (version 1.0, beta 3a) of Cosmo Player was available.  We encountered a number of problems and limitations with Cosmo Player that made the development of our prototype more difficult.

The Cosmo Player VRML interpreter did little or no checking for syntax errors and a debugger wasn't available.  Constructs that worked in one context failed to work in another context that seemed semantically equivalent.  For example, a VRML script could reference a property of a VRML object if the object was declared locally but couldn't if the object was declared externally.  We hope that many of the limitations and inconsistencies in Cosmo Player which we encountered in our experiments will be remedied in future releases.

7.                 Future Work

While our own work in building the Battle Explorer prototype is essentially complete, there are many ways in which Battle Explorer could be extended:

·   Adding sounds to simulations.  VRML supports the incorporation of sound into a VMRL world.  It would be relatively easy, for example, to make an explosion sound occur each time a shot is fired.

·   Adding the ability to replay radio traffic.  The SIMNET logger files that we received from Fort Knox included digital recordings of the radio traffic during an exercise.  Futher experiments are needed to determine whether it would be feasible to convert these recordings into VRML audio format.

·   Building an HTML or Java Graphical User Interface for Battle Explorer.  Using the External Authoring Interface described earlier, it would be possible to build a control panel for Battle Explorer that could be accessed from within a web browser.  The control panel could be built using a combination of  HTML and JavaScript or could be a Java applet. As a first step, the control panel might support start and stop buttons, the ability to jump to arbitrary times, and perhaps a list of key events in an exercise that a user could jump to.

 



[[1]] J. Loughran, E. Johnson, M. Kappel, and M. Stahl: "TARGET: An Analysis Environment for Aggregated Simulation Training Data."  In Proceedings of the 1997 Spring Simulation Interoperability Workshop, 1997.

[[2]] E. Johnson and M. Stahl: "Logged Event Analysis Format¾A Proposed Standard File Format for Simulation Analysis."  In Proceedings of the 1997 Spring Simulation Interoperability Workshop, 1997.

Author's Biographies

ERIC JOHNSON is a Research Staff Member at the Institute for Defense Analyses.  At IDA, Eric Johnson has worked in the areas of expert systems, database systems, and simulation analysis.

At the time these experiments were conducted, MICHAEL KAPPEL was a Research Staff Member at the Institute for Defense Analyses, specializing in the development of prototype software to support analysis tasks.  Michael Kappel currently works for SENTEL Corporation.

JULIA LOUGHRAN is a part-time Research Staff Member at the Institute for Defense Analyses, specializing in simulation analysis. Julia Loughran is also a cofounder of ThoughtLink, Inc., a consulting company that specializes in data analysis, data visualization, and support for collaboration.