Dylan T. 9b3b45258a
Optimise collision box checks by caching some basic info (#6606)
This PR significantly improves performance of entity movement calculation.

Previous attempts to optimise this were ineffective, as they used a cache to mitigate the cost of recomputing AABBs. Entities tend to move around randomly, so the non-cached pathway really needed to be optimized.

This change improves performance on multiple fronts:
1) avoiding Block allocations for blocks with 1x1x1 AABBs and with no AABBs (the most common)
2) avoiding Block allocations and overlapping intersection checks unless a stateID is specifically known to potentially exceed its cell boundaries (like fences)
3) avoiding overlapping AABB checks when overlaps can't make any difference anyway (cubes)

Together, these changes improve the performance of World->getBlockCollisionBoxes() by a factor of 5. In real-world terms, this shows up as a major performance improvement in situations with lots of entities moving in random directions. Testing with item entities showed an increase from 400 to 1200 moving items with the same CPU usage.

This change is built on the assumption that `Block->recalculateCollisionBoxes()` and its overrides don't interact with any world. This is technically possible due to the crappy design of the `Block` architecture, but should be avoided. As a world is not available during `RuntimeBlockStateRegistry` initialization, attempting to interact with a world during `recalculateCollisionBoxes()` will now cause a crash.

This turned out to be a problem for `ChorusPlant`, which was fixed by 70fb9bbdfd06c7eda00b4cd2c2c3840755e6b8f6. The correct solution in this case was to use dynamic states similar to how we currently deal with fence connections.
2025-02-06 15:42:10 +00:00
..
2025-01-06 22:44:16 +00:00
2025-01-06 22:44:16 +00:00
2025-01-06 22:44:16 +00:00
2023-09-08 17:19:06 +01:00
2025-01-06 22:44:16 +00:00
2023-09-08 17:19:06 +01:00
2025-01-06 22:44:16 +00:00
2025-01-06 22:44:16 +00:00
2024-07-07 15:20:45 -05:00
2025-01-06 22:44:16 +00:00
2022-12-19 15:22:09 +00:00
2023-09-27 17:07:02 +01:00
2025-01-06 22:44:16 +00:00
2025-01-06 22:44:16 +00:00
2025-01-06 22:44:16 +00:00
2024-12-01 15:01:41 +00:00
2025-01-06 22:44:16 +00:00
2025-01-06 22:44:16 +00:00
2025-01-06 22:44:16 +00:00
2023-09-07 19:38:29 +01:00
2023-09-07 19:38:29 +01:00
2023-09-08 17:19:06 +01:00
2025-01-06 22:44:16 +00:00
2023-10-24 11:56:51 +01:00
2025-01-06 22:44:16 +00:00
2023-09-07 19:38:29 +01:00
2023-09-07 19:38:29 +01:00
2025-01-06 22:44:16 +00:00
2025-01-06 22:44:16 +00:00
2025-01-06 22:44:16 +00:00
2025-01-06 22:44:16 +00:00
2025-01-06 22:44:16 +00:00
2025-01-06 22:44:16 +00:00
2025-01-06 22:44:16 +00:00
2025-01-06 22:44:16 +00:00
2023-09-08 17:19:06 +01:00
2025-01-06 22:44:16 +00:00
2023-09-07 19:38:29 +01:00
2025-01-06 22:44:16 +00:00
2025-01-06 22:44:16 +00:00
2023-09-08 17:19:06 +01:00
2025-01-06 22:44:16 +00:00
2025-01-06 22:44:16 +00:00
2022-07-20 16:12:58 +01:00
2022-07-09 20:18:22 +01:00
2025-01-06 22:44:16 +00:00
2025-01-06 22:44:16 +00:00
2025-01-06 22:44:16 +00:00
2023-09-08 17:19:06 +01:00
2025-01-06 22:44:16 +00:00
2025-01-06 22:44:16 +00:00
2023-09-08 17:19:06 +01:00
2023-09-08 17:19:06 +01:00
2023-01-04 20:10:46 +00:00
2025-01-06 22:44:16 +00:00
2025-01-06 22:44:16 +00:00
2025-01-06 22:44:16 +00:00
2025-01-06 22:44:16 +00:00
2023-09-08 17:19:06 +01:00
2023-09-07 19:38:29 +01:00
2023-09-07 19:38:29 +01:00
2023-09-07 19:38:29 +01:00
2023-09-07 19:38:29 +01:00
2023-09-07 19:38:29 +01:00
2023-09-08 17:19:06 +01:00
2025-01-06 22:44:16 +00:00
2022-07-06 23:01:17 +01:00
2025-01-06 22:44:16 +00:00
2025-01-06 22:44:16 +00:00
2023-09-08 17:19:06 +01:00
2023-09-07 19:38:29 +01:00