Distributed Simulation Environments among Different Platforms

Page 1 of 5

Distributed Simulation Environments among Different Platforms

Oren Koler, M.S.,

Military research Branch,

Weapon Research and Development,

Israeli Defense Force, ISR

koler@012.net.il

Rahamim Rokah, B.Sc,

Military research Branch,

Weapon Research and Development,

Israeli Defense Force, ISR

rami.rockah@gmail.com

ABSTRACT

The rapid changes in technologies of virtual reality (VR) systems change the way we think of simulation experiments.

Improvements in home computers (faster graphical processing units (GPU) and multi processers) made previous super

computers almost obsolete and strengthened the notion of distributed simulation. In the upcoming years, monitors and

classical control interface devices (mouse and keyboard) might be replaced by VR headsets, gloves and motion sensors.

Software firms are continuing their simulation development and the gaming industry is an increasingly growing partner.

This paper presents the results of an experiment that was conducted with two different graphical platforms running

simultaneously on the same VR urban terrain. Running both platforms in the same environment caused many

irregularities (mainly of data integration) that demanded much effort in sustaining them. Each platform demonstrated

attributes missing in the other thus the final results showed that it is feasible but not advisable to use different platforms

with similar capabilities in the same VR environment for urban scenarios.

This paper may help potential users choose their platforms in a single distributed virtual environment.

ABOUT THE AUTHORS

Oren Koler, M.S. is head of the computer generated forces (CGF) team in the Israeli Defense Force (IDF) Ground

Forces Command (GFC) Battle Lab (BL). His current projects include enhancing autonomies behaviors for combatant

virtual entities in urban environments, virtual terrain improvements for urban ground forces experiments, scenario

outcome analysis and development of distributed modeling systems. Previously earned his M.S. in artificial intelligence

from Bar-Ilan University and served in the IDF armored infantry division.

Rahamim Rokah, B.Sc, is a senior researcher and a product manager in the IDF GFC BL. His current projects include

development of future combat simulation systems and leading experiments focused on future systems and concepts for

the ground forces. Rahamim is an operation research M.S. student at Tel-Aviv University and earned his B.Sc in

Applied Mathematics from Bar-Ilan University.

Distributed Simulation Environments among Different Platforms

Page 2 of 5

Distributed Simulation Environments among Different Platforms

Oren Koler, M.S.,

Military research Branch,

Weapon Research and Development,

Israeli Defense Force, ISR

koler@012.net.il

Rahamim Rokah, B.Sc,

Military research Branch,

Weapon Research and Development,

Israeli Defense Force, ISR

rami.rockah@gmail.com

INTRODUCTION

There are many types of simulation platforms used by the Military for conducting virtual experiments & trainers. These

platforms include many building blocks such as graphical and scenario generating engines, after action review, etc…

Different firms develop these platforms with the capability of working in a distributed environment by using the

Distributed Interactive Simulation protocol (DIS) or High level architecture (HLA). Some firms specialize in creating

extensions for other platforms, for instance, a radar sensor for a graphical engine or an urban path finder for a Computer

Generated Forces (CGF) platform. Choosing a platform for an experiment should be based on the platforms self-

capabilities and its capabilities to work with other platforms. This paper demonstrates that in urban scenarios, the

synchronization between platforms is crucial and that using the same netwrok protocol and terrain, is not enough to

achive the needed synchronization.

About the Battle Lab

The Israeli Defense Force (IDF) Battle Lab (BL) is the human research center of the Israeli Ground Forces (IGF)

combat systems department. Its main purpose is to examine ideas for new weapons and concepts intended for the IGF

future Battle Field (BF). The BL uses Commercial of the shelf (COTS) products to virtually demonstrate weapon

systems and try them in scenarios. The research objective is to understand the systems contribution and suggest

improvements before construction.

In June 2014 the BL examined a new system capable of aiding the ground forces in dense urban hostile environments.

Although the BL has over 15 years of experience in open area combat simulations, as part of the system examination,

the BL also examined new platforms for future urban scenario experiments.

Platform types and their organizations

There are many tools and application needed for conducting an urban scenario experiment in the BL, the two most

important are the visualization and the CGF platforms. (1) The visualization platform is used as the development basis

for the infantry simulator and should be capable of rendering immersive visuals with high-performance. (2) The CGF

platform is used for simulating autonomous units in the urban environment with unit missions and adaptive behaviors.

Other platforms include: (3) communications services for voice communications with realistic environmental

degradation, (4) a collision detection and Rigid Body dynamics library for movement and weapon modeling, (5) a

terrain generation platform capable in creating extreme scale virtual terrains with realistic urban environments in high

level of detail necessary for tactical ground simulators, (6) a suitable platform for simulation networking

allowing interaction and engagement between entities modeled by external simulations in a distributed simulation

environment using standard Modeling & Simulation protocols (DIS & HLA), (7) a tool for capturing and replaying

simulation data, (8) a data analysis platform for on and after action reviews. This paper will focus on the first two.

The BL works in a dynamic environment allowing it to switch its simulation platforms depending on its experiments. It

prefers using COTS products (from various firms) as its infrastructure and only develops systems that are classified or

don’t yet exist in the market.

Distributed Simulation Environments among Different Platforms

Page 3 of 5

An all in one (AIO) COTS product means it has most of the platforms needed for conducting an experiment already

built in it and thus does not require integrating other platforms from other companies. The product is highly reliable do

to it unified architecture in all of its platforms and is tested to work in optimal performance. But there are only a few

AIO products and they are usually suitable for specific environment. For instance a flight simulator AIO product cannot

be used as an infantry simulator. Other Difficulties occur when the features in the product don’t meet the demands,

firms usually don’t expertise in developing all types of platforms, and for instance, a firm could have an expertise in

graphical engine development but not in distributed communication. The product is also usually a complex system,

closed or hard for further development by client users and most importantly, prevent model validations; this is a major

disadvantage for statistical analysis done in the BL experiments.

Using platforms from different organizations allows working with the best platforms in the market and easily switch a

platform if a better one is found but a great deal of development and maintenance is needed for integrating between

then. Using the platforms tech support for solving integration problems are ineffective due to lack of the organizations

compliance to solve integration errors, for instance, if a message did not arrive from one platform to another, was it the

senders fault or the receivers? Although, COTS products are tested extensively with other platforms before

deployment, they can't be tested with all the platforms in the market, this means that there is a possibility of purchasing

two COTS products that have never been tested together before and even if they succeed in working together, it

probably won't be with optimal performance.

Battle Lab Experiment

The BL used three main platforms:

1. VT-MӒKs - VR-Forces (VRF) 4.2 – A CGF platform for synthetic environments.

2. Presagis - Vega Prime (VP) 5.3 – A visualization toolkit for game visuals.

3. Bohemia Interactive simulations - Virtual Battlespace (VBS) 2.15 – A simulation training solution for scenario

training.

All platform use extensions from other organizations for additional capabilities such as DIS communication,

visualization of human characters, vegetation and advanced Artificial Intelligence. All three are capable of handling

dense urban close combat infantry scenarios.

These platforms were chosen on the basis of the BL's prior experience with VP and VRF and previous experimentation

on VBS.The following paragraphs describe the incompatibilities found between the platforms. These incompatibilities

are divided into two groups; terrain and simulation.

Terrain incompatibilities

Having a different understanding of the terrain could cause many abnormalities between platforms. All of the platforms

could have worked with an international terrain format but for dense urban scenarios, they had to work with their own

format for optimal performance using their own tools for creating there preferred virtual terrain. The BL created an

initial terrain and converted it to three specialized formats hoping that this approach would decrease terrain

abnormalities. The terrain was constructed from a high resolution digital elevation model, high resolution terrain photos,

vector data on vegetation (trees and grass), walls, roads and building. A portion of the buildings were modeled with

inner rooms, stairs and windows allowing movement and combat from within them.

The following are some of the incompatibles found between the platforms using different terrain formats;

Distributed Simulation Environments among Different Platforms

Page 4 of 5

Vegetation is a highly important feature in a ground simulation. A virtual human character uses the vegetation as a way

to reach a destination without being detected or for cover while in battle. Due to different algorithms used by the

platform tools for vegetation placement; trees in all formats were placed in the same location but with different tree

models (differences in size and texture). Grass was placed in different locations and in one of the platforms did not even

exist.

Terrain elevation is the used for determining a characters ground height in a specific location. The height in certain

areas of the terrain did not match between platforms. Once again, some platform tools did terrain corner smoothing,

mostly near roads and buildings; this caused characters from other platforms to seem floating above the ground or in it.

Terrain texture enrichment was also done based on terrain color, this caused rendered different visual displays between

simulators that were based on different platforms. One platform also had a dynamic terrain mechanism causing ground

explosions to create potholes in the ground and buildings to collapse due to heavy bombardment; other platforms did

not have this mechanism causing irregular situations were simulators could seemingly fire threw walls.

Simulation incompatibilities

Virtual human character appearance and animation have a great effect on urban scenarios. A characters appearance

include uniform (civilian or enemy), posture (standing, crawling, surrendering), weapon type (AK47, M-16, RPG),

weapon state (in fire position or just deployed), damage state, tactical signs and more; the models are used depending on

life-forms character type.

VP and VRF used DI-Guy (of different version) while VBS used its own modeled characters. Platforms using DI-Guy

characters in a DIS environment use DI-Guy messages for life-form locations and animations. The fact that VBS did

not work with these messages caused location and animation incompatibilities. For instance, the initial VBS life-form

characters location in a VP viewer was in a significant offsets in; fixing this problem demanded extensive tech support

and code rewriting.

In the DIS protocol a life's form posture and animation is also determined by its primary and secondary weapon state.

DI-Guy's posture and animation mapping was different than VBS's mapping causing many posture incoherence's

(crawling entities in one platform would appear standing in another).

Character models from DI-Guy and VBS character library were chosen based on their similarity between platforms, this

meant that only a few character models were used with only a few animations and postures within each character.

Capabilities like strafe and peak (which use animations) were removed, entities with different weapons used the same

model preventing them to be distinguished from one another.

Each platforms had different playing capabilities, this included weapons statistics and ballistics, damage models, types

of scopes, indoor movement and speed, sound and explosion effects, different illumination algorithms (such as

shadows), visual and computational performances and entity ground clamps. The performance of each subject was

highly effected by the platform it used and not just by the subject's capabilities.

SUMMARY

In our opinion it is not recommended to use platforms from different companies in close combat urban area scenarios.

The disadvantages of incompatibility in terrain and simulation exceed the advantages of the diverse simulation

environment. This does not indicate that this approach is not suitable for other kinds of simulations such as open area or

aircraft simulation.

Distributed Simulation Environments among Different Platforms

Page 5 of 5

In order to conduct this kind of experiment, much knowledge was needed in understanding how each platform worked.

It was not possible to reach the terrain compatibility needed for micro tactics encounters and much effort was put in

integrating between the products.

It appears that there will always be terrain incompatibility issues between different organization platforms. For this

reason alone, for close combat urban experiments, it is advisable to use as much platforms as possible from the same

organization and if needed, use other platforms for unimportant capabilities in the experiment.