Multipath Dual Object Creation

Description

This mechanism uses a core template function, createMultipathDualBase, to generate "dual" Transmitter or Receiver objects. These dual objects represent the geometric reflection of an original radar object via a defined MultipathSurface. The process mirrors key properties from the original object to its dual, creates a corresponding dual Platform if one doesn't already exist for the reflection, and handles attached objects (e.g., in a monostatic pair) recursively. These dual objects allow the main simulation loop to calculate single-bounce multipath interactions using the standard simulation functions, simply by treating the dual object as another radar entity located at the reflected position.

Assumptions

• The provided MultipathSurface* surf pointer is valid and points to a correctly configured surface definition.
• The corresponding Platform::createMultipathDual function correctly generates the reflected platform geometry (position and orientation).
• Appending "_dual" to the original object's name results in a unique name within the simulation world.
• dynamic_cast correctly identifies Transmitter or Receiver types for attached objects during recursive creation.
• The recursive creation process for attached objects terminates correctly (i.e., no circular attachments exist in the configuration).

Limitations

• Raw Pointer Ownership: The function returns ownership of the created dual object via a raw pointer (dual.release()). This requires careful handling by the caller (typically World::processMultipath) to avoid memory leaks or dangling pointers. Modern C++ practice would favor returning a smart pointer (e.g., std::unique_ptr).
• Manual Property Cloning: Key properties (like associated Antenna, Timing, Signal, PRF, etc.) are manually copied from the original object to the dual within the createMultipathDualBase function. If the Transmitter or Receiver classes are modified to add new properties relevant to the dual's operation, this function must be manually updated to include them in the copy process, making it potentially brittle.
• Implementation Complexity: The implementation uses constexpr if for type-specific property copying (distinguishing Tx/Rx properties) and std::stack with const_cast for managing the recursion on attached objects. This adds some complexity to the code compared to alternative approaches.

Related Components

• Radar, Transmitter, Receiver classes (specifically the createMultipathDual wrappers defined in their headers)
• Platform class (createMultipathDual method)
• MultipathSurface class
• World::processMultipath (the primary caller of this functionality)
• radar_obj.cpp::createMultipathDualBase (core template implementation)
• Multipath Model
• World Multipath Initialization

Validation Status

• Needs Verification: Yes. While the feature is implemented and used for the multipath model, the correctness of the property cloning, recursive handling, and memory management requires specific validation.
• Key Areas for Validation:
  • Verify that all necessary properties (including flags, settings, associated objects like Antenna/Timing) are correctly copied from the original to the dual object for both Transmitter and Receiver types.
  • Confirm correct handling of attached objects (specifically monostatic pairs) during recursive creation, ensuring the attachment is mirrored correctly in the duals.
  • Ensure the _dual naming convention consistently produces unique names in typical scenarios, especially if multiple multipath surfaces were ever implemented (though currently limited to one).
  • Validate the memory management around the returned raw pointer within World::processMultipath to ensure no leaks occur.
  • Test with various platform motion and rotation types (especially interpolated ones) to ensure the geometric reflection logic within Platform::createMultipathDual interacts correctly with the object property cloning performed here.
• Priority: High (Core logic enabling the current multipath simulation approach)