Collision/Explosion optimisations #153
Conversation
The old collision patch assumed that all VoxelShapes could be boiled down to a list of coalesced AABBs. This was not true, and as a result had some slight collision differences with Vanilla. The new collision patch has been designed with the assumption that most shapes are either a single AABB or an ArrayVoxelShape (typical voxel bitset representation). Like previously, single AABB shapes are treated as AABBs. Unlike previously, the VoxelShape class has been changed to carry shape data that ArrayVoxelShape would, except in a discrete manner rather than abstracted away (not hidden behind DoubleList and the poorly named DiscreteVoxelShape). VoxelShape now carries three important states: 1. The voxel bitset + its sizes for the X, Y, and Z axis 2. The voxel coordinates (represented as an array and an offset per axis) 3. Single AABB representation, if possible Note that if the single AABB representation is present, it is used instead of the voxel bitset representation as the single AABB representation is a special case of the voxel bitset representation and can be optimised as such. This effectively turns every VoxelShape instance, regardless of actual class, into a typical voxel bitset representation. This allows all VoxelShape operations to be optimised for voxel bitset representations without dealing with the abstraction and indirection that was imposed on VoxelShape by Mojang. The patch now effectively optimises all VoxelShape operations. Below is a list of some of the operations optimised: - Shape merging/ORing - Shape optimisation - Occlusion checking - Non-single AABB VoxelShape collisions/intersection - Shape raytracing - Empty VoxelShape testing This patch now additionally includes optimisations for raytracing, which mostly boil down to removing indirection caused by the interface BlockGetter which allows chunk caching. The patch now moves all optimised World operations to the Level class, so that it can remove indirection caused by the BlockGetter interface.
The vast majority of blocks an explosion of power ~4 tries to destroy are duplicates. The core of the block destroying part of this patch is to cache the block state, resistance, and whether it should explode - as those will not change. The other part of this patch is to optimise the visibility percentage calculation. The new visibility calculation takes advantage of the block caching already done by the explosion logic. It continues to update the cache as the visibility calculation uses many rays which can overlap significantly. Effectively, the patch uses a lot of caching to eliminate redundant operations. Performance benchmarking explosions is challenging, as it varies depending on the power, the number of nearby entities, and the nearby terrain. This means that no benchmark can cover all the cases. I decided to test a giant block of TNT, as that's where the optimisations would be needed the most. I tested using a 50x10x50 block of TNT above ground and determined the following: Vanilla time per explosion: 2.27ms Lithium time per explosion: 1.07ms This patch time per explosion: 0.45ms The results indicate that this logic is 5 times faster than Vanilla and 2.3 times faster than Lithium.
Need to use the offseted bounding box to check for collisions
|
I have a concern that this pr could regress TNT cannon performance because of the removal of the cache in the optimize explosions patch. The TNT cannons used on Factions have large amounts of TNT and Sand upwards into the thousands in the same location. Cannon and Faction servers often disable random TNT spawn velocity as well to better utilise the cache when compressing TNT together. I also had this exception |
I honestly didn't think that anyone running 1.20 would also be running factions. Although, Folia has the tnt optimisation patch for that disabled anyways (since day 1) due its usage of global state. Were you running Folia before and did you notice any problems with the tnt performance? |
If the block is out of bounds, then the block state may be null.
Vanilla uses float here, so it may change behaviorly slightly by using more precision.
Resolved the exception 259f2da |
I just help run a 1.20 cannon server running our own fork of Paper with tnt optimisations. There are quite a few modern factions servers out there with the biggest currently with 141 players at the time I am writing this and some of the older community is moving on trying to update. The biggest issue we face is that any tnt optimisations other than what is in Paper is paywalled and often break behaviour which stunts a lot of growth for new servers. In my experience both Paper and Folia have performance issues with TNT cannons. |
If both blockstates have cached collision shapes and either one of them full occludes block or both of them are empty, we do not need to run the further cache logic and can return immediately.
I did end up testing your claims @Samsuik about it effecting TNT Cannons, and it seems to not be the case. I have been running on this branch to see if I would encounter any bugs, and it seems players occasionally die by fall damage when they teleport around. This happens rarely, but it does happen. Here are the plugins it has happened on EpicHomes ( ) StormerTPAReloaded ( https://github.com/Loving11ish/StormerTPAReloaded ) StormerWarpsReloaded ( https://github.com/Loving11ish/StormerWarpsReloaded ) BetterRTP ( https://github.com/RonanPlugins/BetterRTP ) Even rarer. Here is a video of it now ( https://youtu.be/sRbGOVQYFzM ) I think he was using a bad video recorder or something because it is like 6 fps. |
I started building a cannon specifically for testing and I finished last night. Here are the results of my crude testing: If you would like to test the performance of the cannon I made I uploaded the cannon to google drive. Link: https://drive.google.com/file/d/1AKTyQekysAk5oA8xRVmq45GXgTDPTyp1/view?usp=sharing |
That looks like something I would have to paste using FAWE. Would you be able to make a video, and perhaps a spark report of it? I would be interested to see the results. |
If the offset were to be undone, then it would incorrectly mark the cache as not having an offset when it actually did.
|
After some deep testing I can see a x3-5 more performance on a instant heavy load with huge faction cannons (1000 tnt at a time) and after the first shot it stays at 20 tps, tested on a Intel® Core™ i9-13900 24 Core 64 GB DDR5 RAM compared to the old folia I get around 10-15 tps casually. (some paper config had to be changed in order to have all the tnt work) Can't wait for chunk (un)load to get fixed ! |
|
Merged to paper 1.20.2
I've not tested this myself, however the upcoming paper 1.20.2 build will have the legacy optimize explosions and the performance from this branch. |
|
@Spottedleaf Unable to place redstone like on screenshot. Same problem with back side of piston |
Resolved by PaperMC/Paper@c207429, will not be ported to this branch |
See the commit notes:
c6950e2
3b16d8f
Please report any issues with the branch on this PR.