Multi-Resolution Modeling with MAK ONE
by Dan Brockway
Maybe you already know that VR-Forces can simulate at both the Entity-level and the Aggregate-level. But did you know that VR-Forces can simulate both models at the same time — in the same exercise?
To be sure, simulating across the boundary between Entity and Aggregate levels is an advanced modeling concept that is very much at the forefront of Modeling & Simulation. First let’s look at the power of abstraction to understand the value of each level of modeling, then take a look at why people want to use both together, and finally how VR-Forces supports users who want to take this leap.
The Power of Abstraction
Abstractions are good, they give us the ability to concentrate on essential aspects in a context, ignoring characteristics of less importance. This ‘ignoring’ translates to both performance and ease of use. Let’s take wargaming as the prime example. When trying to understand the effect of various courses of action with large military structures the ability to abstract thousands of individual soldiers (entities) into units such as Platoons, Companies, Battalions, Brigades, or Divisions, allows planners, analysts, and decision-makers to focus on the dynamics that affect the outcomes of their choices. Instead of having to manage 10 to 15 thousand individual soldiers as simulation objects, a Division-level exercise can focus on the 100 or so simulation objects that represent the Brigades, Battalions, and Companies. This makes the job of managing the complexity of the exercise possible by humans and it also saves lots of computer power, which translates to increased speed and number of iterations of any exercise.
Of course, when training as individual soldiers or operators of individual platforms, the Entity Level is the appropriate abstraction, where each soldier or vehicle platform and munition is modeled with a simulation object. This level of simulation has practical limits on the scale of an exercise. In terms of both the number of people that need to be involved and on the performance of the simulation infrastructure.
Have a look at this video made by one of MAK's engineers demonstrating a Lua script that converts Aggregates to individuals then reconstitutes Aggregates from those Individuals.
Why Multi-Resolution Modeling
The Aggregate Wargaming Case
In the case of Wargaming, there are instances where specific individual entities have a disproportionate effect on the outcome on the course of action. A good example is the use of sensor assets hosted on unmanned vehicles. A sensor feed, which needs to see the situation at an Entity level, is increasingly of value to higher echelons in decision-making. In this case, it would be useful to model the activity of individual entities to render the sensors video. Another example is where the fidelity of the Aggregate model doesn’t adequately address some important phenomenon. Imagine a case where an airfield is rapidly being resupplied. Maybe the local traffic is important to the success of the outcome. In this case, it might be beneficial to have the area surrounding the airport modeled as individual vehicle entities.
The Large-Scale Entity Simulation Case
The power of computer simulations is expanding at such a rapid pace that some believe that it would be possible, and useful, to model the entire Brigade at the Entity level and potentially train soldiers and commanders at all levels together. And while the trend is clearly in this direction there are still many technological challenges to be overcome. We at MAK have proven with our Legion project that the simulation interoperability can be scaled into the millions of entities. But no one has solved the challenging issue of planning out useful behavior for tens of thousands of Computer Generated Forces (CGF) entities, much less millions. And the compute power to run that many is substantial and not cost-effective for most training applications.
The concept of multi-level modeling is attractive as a way to have some of both benefits, lots of individual entities along with the rest of the flanking and opposing forces modeled in the Aggregate.
The Simulation of Terrain Metaphor
In both cases, there is a useful analogy in the way we have solved the terrain problem. We can have a high-resolution terrain model suitable for first-person interaction anywhere, and everywhere, on planet Earth. Just not all at once. The terrain problem is very large, huge even. The number of high-resolution tiles needed to represent the whole planet is astronomical. But, not to worry, it turns out that there is no need to experience all of it, not ever. The solution is not to build all of it in glorious detail and store it on some massive cloud storage device. The solution is to only build it when, where, and to the resolution it is needed.
This same solution may just be the path forward in multi-resolution modeling. The trick is mastering disaggregation.
How VR-Forces Supports Multi-Resolution Modeling
At its core, VR-Forces has a general-purpose simulation engine that uses a Simulation Model Set (SMS) to tell it which models to use. The SMS defines which simulation objects are available, the parameters that describe the objects, and the models that define their capabilities. These models include the physical characteristics of the object, dynamics models that describe how the objects move within the synthetic environment, sensor models that describe the abilities of the object to detect, and therefore ‘know about’ other objects in the synthetic environment, weapons models, logistics models, and so on.
This is true for individual Entities as well as Aggregate units. The difference is in the specific characterizations of the objects and the particular models that operate on each type. For example, Entities exist at a point in space and are defined by some basic size and shape parameters. They can have a 3D geometry model to represent them visually and a set of Icons to represent them symbolically on the terrain or a map. Whereas an Aggregate has parameters to describe its footprint that differs when the unit is different postures (Travel, Reconnaissance, Attack, Defense, etc.).
The way individual Entities engage in combat is also different than Aggregate units. Entities fire individual weapons that detonate on or near targeted entities. The targeted entities use their damage models to determine the effect of the attack then adjust their state to indicate if they have been damaged or destroyed. It’s a very personal one-on-one engagement.
Aggregates engage other Aggregate units by using probabilities based on their posture, their combat capabilities, their defensive capabilities, and other parameters. The result is attrition of personnel, equipment, weapons, and other resources to both Aggregates.
Out of the box, VR-Forces comes with several SMS files, particularly EntityLevel.sms and AggregateLevel.sms. Usually, customers use one or the other, or derive their own customized version of one or the other. This makes perfect sense since all the object definitions and models are designed specifically to address the interactions at each level, respectively.
An Aggregate doesn’t have Individuals for an Entity to shoot at, for example. And Entities don’t have the same resources to attrit in combat with an Aggregate. Even though both levels of models can run in VR-Forces at the same time, there is no semantic understanding between them. The models ‘talk’ about different things.
So how can models at different levels interact?
The simple answer is that because VR-Forces is a platform that can run both models at the same time and because it has a powerful Lua scripting language built in, customers can use VR-Forces as a platform for innovation. In each case, the customer will have to define what type of interactions make sense in their context. One example is to use a Lua script to watch for Aggregates that cross a phase line or enter an area or any other such trigger. The Lua script then uses the parameters of the Aggregate to spawn an appropriate number of Entities of the types defined by the Aggregate’s then-current state. Then delete the Aggregate, thereby changing the state of the synthetic environment to no longer having an Aggregate, but now having its disAggregated entities. The Lua script can also take advantage of VR‑Forces’ Entity-level organizational capabilities to build the appropriate echelon hierarchy and to give the parent unit a task that will affect all the subordinates. For example, if a Company was in a Traveling posture following a route into town, the new collection of entities could also be given the task to follow the route into town.
Later, another trigger could cause the Lua script to delete all the entities that it previously created and recreate an Aggregate with parameters indicating the number of individuals that survived their time existing as individual Entities.
This approach is elegant because no changes to VR-Forces are needed to develop meaningful interactions across the Entity to Aggregate modeling boundary.
If you would like to discuss the possibilities for Multi-Resolution Modeling, please reach out at
