Collision Zone Performance Refactor [SYNTH-132]

[azaleacolburn]

Task

SYNTH-132

Symptom

Performance tanks when robots and pieces enter zones. Generally zones cause poor performance.

This is due to the way in which ZoneSceneObjects handle collisions. Basically, each one creates a sensor, then subscribes to every collision between all Jolt bodies, this is horribly expensive for two reasons:

1. Not every zone should care about every object, e.g., scoring zones only care about game pieces. So the zones have to filter through a lot of information they don't care about.
2. A lot of Jolt body collisions happen, so for complicated robots like 2471's 2018 bot, each zone has to deal with each body's collision with the zone's sensor.

Solution

Each sub-class of ZoneSceneObject now implements a function called checkObjectsInZone, which is responsible for manually going through every object that the zone cares about and checking if they are in the zone, then performing the needed actions given that information.

Instead of listening for collisions, these functions (in ScoringZoneSceneObject and ProtectedZoneSceneObject) draw bounding boxes around every object they care about (e.g. each robot), then check if that bounding box overlaps with that of the zone.

Verification

We don't have standardized performance benchmarks, but the lag that used to be present when a robot enters a protected zone is gone. Try this with 2471's 2018 bot, the difference is actually huge (on my machine).

The performance for game pieces in scoring zones is gone, however on some fields (e.g. 2023), there complicated jolt bodies around the scoring zone, which can cause placed bodies to lag slightly. However, other parts of the scoring zone are unaffected.

Tests have been updated to match the new way zones work.

---

Before merging, ensure the following criteria are met:

• All acceptance criteria outlined in the ticket are met.
• Necessary test cases have been added and updated.
• A feature toggle or safe disable path has been added (if applicable).
• User-facing polish:
  • Ask: "Is this ready-looking?"
• Cross-linking between Jira and GitHub:
  • PR links to the relevant Jira issue.
  • Jira ticket has a comment referencing this PR.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[AlexD717]

For me it looks like the bounding boxes are still a bit off (when enabling DBEUG_BOUNDING_BOXES), and the collision also behave weirdly.

[rutmanz]

I would also note that spawning additional robots moves the bounding box of the other robots

[azaleacolburn]

Gang I promise the bounding boxes were tightly fitting before 😭

[AlexD717]

Minor debug bounding box duplication glitch, but otherwise lgtm.

[AlexD717]

lgtm

[rutmanz]

Up to you if you make this a separate ticket, but the boxes are not currently recalculated on joint motion

[azaleacolburn]

Up to you if you make this a separate ticket, but the boxes are not currently recalculated on joint motion

@AlexD717 and I already had a conversation about that this morning. The plan is to handle that when it actually matters in SYNTH-228.

[rutmanz]

Up to you if you make this a separate ticket, but the boxes are not currently recalculated on joint motion

@AlexD717 and I already had a conversation about that this morning. The plan is to handle that when it actually matters in SYNTH-228.

Technically it's not just for the dimension tracker that it matters, a robot that has a deployable intake is inside a protected zone when the pre-deploy bounding box (bumpers) are not. As long as it gets fixed later/is tracked though