Add parallelization to RadiationSystem.GridCast

[Naxel11]

About the PR

This PR significantly optimizes the RadiationSystem to handle hundreds (maybe thousands?) of radiation sources without causing server lag. The system has been redesigned to use parallel processing in combination with a two-stage selection strategy, significantly reducing its impact on performance.

Why / Balance

The previous implementation had a computational complexity of O(Sources × Receivers). In scenarios with a large number of radiation sources (e.g., widespread tritium fires), this led to the system's update time exceeding 20ms, causing noticeable server-side lag and impacting the game's tick rate.

This change is purely a performance optimization. The underlying radiation mechanics and final calculated values remain identical, ensuring no change to game balance. It simply allows the system to perform as intended under heavy load.

There was a TODO for this

Technical details

1. Incremental, Event-Driven Architecture:

• A new fundamental change is that the system no longer queries all sources and receivers every tick. It now maintains persistent collections that are updated reactively via entity lifecycle events (ComponentInit, ComponentShutdown, MoveEvent, etc.). This eliminates the performance cost of collection building from the main update loop, ensuring UpdateGridcast is extremely lightweight.

2. Parallelization by Receiver: The main loop now iterates over radiation receivers in parallel using an IParallelRobustJob. Each thread is responsible for calculating the total radiation for a single receiver.

3. Two-Stage Culling: To avoid the expensive O(S×R) complexity, each parallel task performs a two-stage culling process for its assigned receiver:

• Broadphase (Spatial Culling): The broadphase is now handled by a persistent DynamicTree which stores all active radiation sources. For each receiver, a fast QueryAabb is performed to get a small list of potentially relevant nearby sources. After this initial spatial culling, a cheap distance check is performed using the pre-calculated maxRange (Intensity / Slope) to further refine the candidate list.
• Narrowphase (Raycasting): Only the small subset of sources that pass the broadphase check are then processed with the more expensive Irradiate method, which performs the actual grid intersection tests and raycasting.

4. Thread Safety:

• Each parallel task uses its own local List<Entity<MapGridComponent>> for grid intersection checks, completely eliminating race conditions that were present in earlier parallelization attempts.
• Additionally, a Gather-Apply pattern is now used to ensure safety with other game systems. The parallel job only calculates radiation values and stores them in a results array (the "Gather" phase). The application of these results (updating components and raising events via IrradiateEntity) is then done sequentially in the main thread (the "Apply" phase), preventing race conditions with non-thread-safe systems called via OnIrradiatedEvent.

Media

A result of 1.5 - 2.5 ms update time was achieved for 51 receivers, 628 sources.

Requirements

• I have read and am following the Pull Request and Changelog Guidelines.
• I have added media to this PR or it does not require an ingame showcase.

Breaking changes

None

Changelog

🆑 Naxel

• fix: Heavily optimized the radiation system to prevent severe server lag when a large number of radiation sources are active.

[Naxel11]

Need for tritium fire PR

[metalgearsloth]

2ms for that little to process still seems goofy to me?

[metalgearsloth]

Realistically radiation was never built with performance in mind but if we actually want to use it more the first thing to do is to use b2dynamictree for radiation sources then iterate every receiver in parallel.

[Naxel11]

Comparison on a laptop 8 GB RAM, 2.60 - 3.80 GHz
master:
~28 ms, 138 receivers, 962 sources, 5692 rays

RadiationSystem-Gridcast-rework:
~8 ms, 137 receivers, 957 sources, 4896 rays

[southbridge-fur]

Read through the code. Looks good just got a couple style changes. Still need to test in game.

[southbridge-fur]

Also possible testfail fake

[Naxel11]

Realistically radiation was never built with performance in mind but if we actually want to use it more the first thing to do is to use b2dynamictree for radiation sources then iterate every receiver in parallel.

Good thing. I used it with the difference that I didn't use B2DynamicTree directly, but its wrapper DynamicTree (DynamicTree.cs line 76)

[southbridge-fur]

A couple other minor changes

[southbridge-fur]

Looks good and thank you for contributing!

[JrInventor05Next]

second approve is true...