Skip to content

engine-integration.md

Latest commit

 

History

History
46 lines (36 loc) · 3.05 KB

engine-integration.md

File metadata and controls

46 lines (36 loc) · 3.05 KB
Raw

Engine Integration

Unity Adapter

  • Convert Unity scene data into WorldState.
  • Push agent positions, navmesh availability, events to middleware.
  • Fetch batched AgentCommands from middleware.
  • Apply moves, animations, interactions in Unity.
  • Optional debug overlay for goals, LOD, and current action visualization.

Adapter API (Conceptual)

// Initialization and shutdown
bool InitSimulation(int maxAgents);
void ShutdownSimulation();

// Main simulation step
void StepSimulation(float deltaTime, ref MarshaledWorldSnapshot marshaledSnapshot,
                    [Out] AgentCommand[] agentCommands, ref int commandCount, int maxCommandCapacity,
                    Vector3 cameraPosition);

// Agent management
int AddAgent(Vector3 initialPos, Quaternion initialRot, int initialGoal, int initialState);
void RemoveAgent(int agentId);
int GetAgentCount();

// Debug data retrieval
void GetAgentData([Out] AgentDebugData[] agentData, ref int count);

Notes

  • Avoid per-agent callbacks to engine for performance.
  • Batch movement and events to minimize frame overhead.
  • Design for expansion to Unreal or Godot.

Integration with Other Engines (Conceptual)

Integrating AgentSimMiddleware with engines beyond Unity (e.g., Unreal Engine, Godot Engine) will follow a similar adapter-based architectural pattern. The core principle remains isolating the engine-agnostic C++ simulation logic from engine-specific data handling and rendering.

General Approach:

  1. Engine-Specific Adapter Layer: A new adapter layer (e.g., UnrealAdapter.cpp/.h or GodotAdapter.gdns/.gd for scripting APIs, or C++ for native integrations) would be developed for each target engine. This layer acts as the primary interface between the engine's world state and the C++ core.
  2. World State Marshaling: The adapter would be responsible for gathering relevant world data (e.g., entity positions, obstacle geometry, event triggers) from the engine's API and marshaling it into a WorldSnapshot structure that the C++ core can understand. This process is analogous to how UnityAdapter.cs currently populates WorldSnapshots.
  3. Command Translation: After the C++ core's StepSimulation method processes the WorldSnapshot and updates agent logic, it generates AgentCommands. The engine-specific adapter would then receive these commands and translate them into native engine calls (e.g., moving an Unreal Actor, playing a Godot animation, triggering an event within the engine).
  4. Debugging & Visualization: Just as with Unity, the adapter would provide mechanisms for exposing C++ core debug data back to the engine's editor or debugging tools for visualization (e.g., agent paths, current goals, LOD states).
  5. Build System Integration: The C++ core, being CMake-based, can be easily integrated into other engine's build pipelines (e.g., as a module for Unreal Engine or a GDExtension for Godot).

This modular approach ensures that the high-performance C++ simulation logic remains reusable and decoupled, while engine-specific concerns are confined to their respective adapters.