|
VR-Engage
2.2
|
|
|
VR-Engage
2.2
|
VR-Engage is a multi-role virtual simulator that enables users to operate as human characters, vehicle crew members, drone operators, or aircraft pilots within distributed military training exercises.
VR-Engage operates as a distributed system with separate frontend and backend processes. The frontend handles visualization and user interaction through an application based on VR-Vantage, while the backend manages simulation logic through an application based on VR-Forces. This architectural separation influences component design, development workflow, and debugging strategies.
VR-Engage executes as two distinct processes that communicate over network connections:
flowchart LR
subgraph Frontend["Frontend (vrEngage.exe)"]
direction TB
FE[Input / UI / Rendering]
end
subgraph Backend["Backend (vrEngageSim*.exe)"]
direction TB
BE[Physics / Sensors / AI / Network]
end
Frontend -->|Commands| Backend
Backend -->|State Updates| Frontend
Both processes depend on external data sources and services:
flowchart LR
VRE["VR-Engage Processes"]
VRTW["VR-TheWorld Server"]
SMS["Simulation Model Set"]
Scenario["Scenario Files"]
DISNet["Simulation Network"]
VRTW -->|Terrain Data| VRE
SMS -->|Entity & Role Definitions| VRE
Scenario -->|Initial State| VRE
VRE <-->|DIS/HLA Protocol| DISNet
The frontend process (vrEngage.exe) handles user interaction and visualization. It processes input device events, renders the visual environment, manages the user interface, and coordinates role selection. Frontend components prioritize responsiveness—input latency and frame rate matter for the operator. The frontend maintains minimal simulation state—only what is necessary for immediate display and user interaction.
The backend process (vrEngageSim*.exe) performs physics simulation, entity behavior logic, damage assessment, sensor modeling, and network protocol handling. The asterisk indicates protocol variant—vrEngageSimDIS.exe for DIS exercises or vrEngageSimHLA1516e.exe for HLA Evolved federations. Backend components prioritize accuracy—physics and sensor models must remain consistent regardless of display performance. The backend maintains authoritative simulation state and coordinates with other simulation participants.
This separation also provides resilience: if the frontend crashes, the backend keeps running and can accept a reconnection without losing simulation state.
VR-Engage builds upon three MAK SDK products. Understanding this foundation helps developers locate appropriate APIs and documentation for their development tasks.
VR-Vantage provides the graphics and application platform for the VR-Engage frontend. The frontend process extends VR-Vantage, inheriting:
VR-Engage extends VR-Vantage with player station management, role-based component loading, and simulation-specific UI frameworks. The VR-Vantage entity facade classes handle 3D model display while VR-Engage components control what state those models represent.
When developing frontend extensions, developers use VR-Vantage APIs for graphics, UI, and input device integration. The VR-Vantage Developer's Guide provides detailed API documentation.
VR-Forces provides the simulation engine for the VR-Engage backend. The backend process extends VR-Forces, inheriting:
VR-Engage extends VR-Forces with player-controlled entity support, actuator components that respond to frontend commands, and role-specific system configurations. The same entity types can be AI-controlled by VR-Forces or player-controlled by VR-Engage.
When developing backend extensions, developers use VR-Forces APIs for entity behavior, physics integration, and simulation state access. The VR-Forces Developer's Guide covers the simulation API.
VR-Link provides network middleware for distributed simulation. Both processes use VR-Link for protocol abstraction—the same application code supports DIS and multiple HLA versions through build-time selection.
VR-Link handles entity state publication, interaction processing (weapons fire, communications), and dead reckoning. VR-Engage components interact with the network through VR-Forces' event manager rather than calling VR-Link directly. Because protocol handling is isolated this way, the same frontend role definitions work across any supported protocol. The VR-Link Developer's Guide documents network integration.
VR-TheWorld provides streaming terrain data to both frontend and backend processes. The frontend uses terrain for visual rendering and collision detection with the camera. The backend uses terrain for physics simulation, line-of-sight calculations, and ground-following.
VR-Engage integrates with the MAK products at runtime:
flowchart TB
subgraph VREngage["VR-Engage"]
Frontend["vrEngage.exe<br/>(Player Interface)"]
Backend["vrEngageSim*.exe<br/>(Simulation)"]
end
subgraph Products["MAK Products"]
VRV["VR-Vantage<br/>(Graphics Engine)"]
VRF["VR-Forces<br/>(Simulation Engine)"]
VRL["VR-Link<br/>(Network Middleware)"]
VRTW["VR-TheWorld<br/>(Terrain Server)"]
end
subgraph External["External Federates"]
OtherSim["Other Simulations"]
Stealth["VR-Forces GUI"]
Logger["Data Logger"]
end
Frontend --> |extends| VRV
Frontend --> |uses| VRL
Backend --> |extends| VRF
Backend --> |uses| VRL
Frontend --> |terrain data| VRTW
Backend --> |terrain data| VRTW
VRL <--> OtherSim
VRL <--> Stealth
VRL <--> Logger
VR-Engage participates in exercises with other simulation applications through standard protocols. Common configurations include:
VR-Forces Command: VR-Forces GUI controls AI entities while VR-Engage provides player stations. Both share the same Simulation Model Set for entity consistency.
Mixed Federations: VR-Engage backends join HLA federations alongside third-party simulators. VR-Link's FOM mapper handles attribute translation.
After Action Review: VR-Engage exercises generate standard DIS/HLA traffic that logging tools capture. MAK Data Logger and third-party tools process this data for debrief.
VR-Engage implements functionality through discrete, composable components. This architecture enables reuse (common components like radio systems work across vehicle types), customization (vehicle-specific components extend base behavior), and modularity (components can be developed and tested independently).
Frontend components execute in vrEngage.exe and manage the player's interface. They inherit from DtPlayerComponent or its derivatives like DtEntityControlLogic. Responsibilities include processing input device events and generating control commands, rendering HUD elements and cockpit instruments, and managing UI state and player interaction flow.
Common frontend component types include control logic components (DtDriverControlLogic, DtPilotControlLogic) that process user input, observer updaters that manage camera position and view control, display components that render instruments, and input logic that handles specialized input devices.
Backend components execute in vrEngageSim*.exe and implement simulation logic. They inherit from VR-Forces base classes such as DtSimComponent. Responsibilities include calculating physics responses to control commands, modeling sensor behavior and generating detection data, and implementing autonomous entity behaviors.
Common backend component types include actuator components that translate control commands to physics forces, sensor components that model detection and tracking, behavior components that implement AI logic, and system components that represent subsystems like weapons and engines.
Frontend and backend components communicate through messages rather than direct method calls. The DtVreMessageManager provides publish/subscribe messaging for decoupled communication. This separation allows frontend and backend to run on different machines, enables frontend reconnection after crashes without losing simulation state, and decouples development so frontend changes don't require backend rebuilds.
For implementation details on developing components, see Player Station Framework.
VR-Engage uses declarative configuration files to define behavior without code changes. Understanding what each configuration type controls helps developers modify the right files for their requirements.
| Configuration Type | Location | Controls | Process |
|---|---|---|---|
| Role definitions (Lua) | data/simulationModelSets/VR-Engage/roles/ | Frontend components, UI layout, input mappings | Frontend |
Entity definitions (.entity) | SMS entities/ | Physics properties, system attachments, available roles | Backend |
System definitions (.sysdef) | SMS systems/ | Sensor parameters, weapon characteristics, subsystem behavior | Backend |
| Input mappings (Lua) | data/input/ | Device-to-action translations | Frontend |
Configuration files define what components to use and how to parameterize them. Code defines how components behave. This separation means adding a new vehicle type typically requires only configuration changes, changing how a control system works requires code changes, and most customer customizations can be achieved through configuration alone.
The following diagram illustrates how configuration flows to runtime behavior:
flowchart LR
subgraph Configuration["Configuration Files"]
Role[Role Definition
Lua]
Entity[Entity Definition
.entity]
System[System Definition
.sysdef]
end
subgraph Runtime["Runtime Objects"]
FrontendComp[Frontend Components]
BackendComp[Backend Components]
SimObject[Simulation Object]
end
Role --> |instantiates| FrontendComp
Entity --> |instantiates| SimObject
System --> |configures| BackendComp
Entity --> |references| System
Entity --> |references| Role
When a player selects a role, the frontend framework parses the role's Lua configuration, instantiates the specified component groups, and applies initialization parameters. The backend, having already loaded the entity definition, provides the simulation object that the frontend role controls.
For details on role configuration, see Role Configuration.
VR-Engage provides several extension mechanisms for adding custom functionality.
Both frontend and backend support runtime-loaded plugins. Frontend plugins register new component types with the player station factory. Backend plugins register new simulation components with the VR-Forces entity system. Plugins load from the plugins64/ directory based on build configuration.
Developers typically extend VR-Engage in these ways:
New Vehicle Roles: Create role configuration files that combine existing components in new ways. This requires no code changes—only Lua configuration.
Custom Instruments: Develop frontend components that display specialized information. These inherit from DtPlayerComponent and use Qt or GL Studio for rendering.
New Sensor Types: Implement backend components that model detection characteristics. These integrate with the VR-Forces sensor framework.
Custom Input Devices: Create input handlers that translate hardware signals to VR-Engage input events. These use the SDL-based input abstraction.
For implementation guidance, see Toolkit Fundamentals.
See also
