1. 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.

2. 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.

3. 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;

4. 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.

5. 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.