Entities perform insanely redundant collision checks on motion
The bug
The block collisions method for entities is incredibly inefficient and performs insanely redundant computations for no reason. Each tick when an entity calls the movement method to update it's position, it will first move in the Y axis, then move in the X or Z depending on which motion is greater then finish moving along the remaining axis for that tick. This method is well established to simulate entity motion in a way that is computationally efficient as it allows collision checks to be done independently for each face of an entities hitbox.
Unfortunately however, the collisions method is poorly designed to utilise the movement method for efficient collision calculations. As it will start by collecting block collision boxes from the volume projected by the motion axes, then iterate through this volume for each block, checking whether the hitbox of the entity intersects the block faces in each axis. Which is absurd because for fast moving entities the volume projected by the motion axes can contain millions of blocks that have nothing to do with the motion axes. This results in the block collisions method scaling extremely poorly as the velocity of collisions increases.
To get an idea of how bad the scaling is, consider that a TnT entity with Motion:[1000.0, 100.0, 1000.0] would check 100 million positions for collisions despite only realistically being able to collide with 8400 blocks in total. So that is pretty much 100 million calculations the game does for literally no reason but to waste energy.
The currently implemented method incorporates no mechanisms to discard redundant collision checks and free up computation for other more crucial tasks. Some effective measures to improve collisions would be to check the load state of chunks intersecting the motion axes in the order they are processed. So for example an entity with Motion:[800.0,100.0,900.0] would check the load state of chunks Z+900 then X+800 from the entities current position and discard collision checks for unloaded chunks. Then the method could check whether the subchunks intersecting the lines Y+100, Z+900, X+800 contain blocks other than air and skip collision checks for subchunks containing air. Then finally the method would iterate over individual block collisions along the motion axes where the entity actually moves.
Created Issue:
Entities Perform Insanely Redundant Collision Checks on Motion
An entity processing it's motion on the X, Y and Z axis will check for collisions with blocks within a volume enclosed by the axis of motion. This is in spite of the fact that the entity can ONLY collide with blocks within each axis of motion which are processed independently every tick.
This cullminated into a devastating effect when I fired a cannon 2000 blocks, which is only a fraction of it's maximum range, and then my game froze and the world was unrecoverable. It was fortunate I had saved a schematic of the cannon otherwise I would have lost the design completely. These issues can be fixed by installing carpet mod and running optimisations such as OptimizedTnT and OptimizedFastEntityMovement.
OptimizedTnT is an ideal solution for optimizing TnT because if multiple TnT entities explode at the same location, instead of processing the blast knockback formula independently for each TnT, it simply combines their effects into a single calculation vastly improving performance while maintaining behaviour.
OptimizedFastEntityMovement is also an ideal solution because it makes it so entities ONLY process collions from blocks directly in the path of each XYZ axis that the motion is processed along, preserving the current entity motion behaviour while also vastly reducing the number of computations.
But unfortunately some of my viewers just wanted to plug and chug the cannon and didn't bother watching the whole video. Now I am dealing with players getting angry at me for designing a contraption in minecraft which crashes their game and renders their worlds unrecoverable all because of a lack of optimisation in the game code.
As an example here is a world download with the cannon positioned at 4K,4K in the overworld and setup to fire a payload at 0,0:
https://www.mediafire.com/file/vpf6ctq0cvfl0p7/Orbital_Strike_Crash_Test.zip/file
Instructions are as follows:
- Join the world and wait 1 minute
- Press the Button labelled "Start Cannon"
- The player will be teleported to 0,0,0 and the cannon will begin charging
Note the TPS drop significantly due to large quantities of TnT performing inefficient calculations
Note that eventually the game becomes unresponsive due to excessive collision checks as the cannon fires
Note that the cannon works perfectly fine with optimizations running
You can also find the video about the cannon here:
EntitiesPerformInsanelyRedundantCollisionChecks onMotionEntities perform insanely redundant collision checks on motion
relates to
An entity processing it
's motion on the X, Y and Z axis will check for collisions with blocks within a volume enclosed by the axis of motion. This is in spite of the fact that the entity can ONLY collide with blocks within each axis of motion which are processed independently every tick.This cul
lminated into a devastating effect when I fired a cannon 2000 blocks, which is only a fraction of it's maximum range, and then my game froze and the world was unrecoverable. It was fortunate I had saved a schematic of the cannon otherwise I would have lost the design completely. These issues can be fixed by installing carpet mod and running optimisations such as OptimizedTnT and OptimizedFastEntityMovement.
OptimizedTnT is an ideal solution for optimizing TnT because if multiple TnT entities explode at the same location, instead of processing the blast knockback formula independently for each TnT, it simply combines their effects into a single calculation vastly improving performance while maintaining behaviour.
OptimizedFastEntityMovement is also an ideal solution because it makes it so entities ONLY process collions from blocks directly in the path of each XYZ axis that the motion is processed along, preserving the current entity motion behaviour while also vastly reducing the number of computations.
But unfortunately some of my viewers just wanted to plug and chug the cannon and didn't bother watching the whole video. Now I am dealing with players getting angry at me for designing a contraption in minecraft which crashes their game and renders their worlds unrecoverable all because of a lack of optimisation in the game code.
As an example here is a world download with the cannon positioned at 4K,4K in the overworld and setup to fire a payload at 0,0:
https://www.mediafire.com/file/vpf6ctq0cvfl0p7/Orbital_Strike_Crash_Test.zip/file
Instructions are as follows:
- Join the world and wait 1 minute
- Press the Button labelled "Start Cannon"
- The player will be teleported to 0,0,0 and the cannon will begin charging
Note the TPS drop significantly due to large quantities of TnT performing inefficient calculations
Note that eventually the game becomes unresponsive due to excessive collision checks as the cannon fires
Note that the cannon works perfectly fine with optimizations running
You can also find the video about the cannon here:
An entity processing its motion on the X, Y and Z axis will check for collisions with blocks within a volume enclosed by the axis of motion. This is in spite of the fact that the entity can ONLY collide with blocks within each axis of motion which are processed independently every tick.
This culminated into a devastating effect when I fired a cannon 2000 blocks, which is only a fraction of it's maximum range, and then my game froze and the world was unrecoverable. It was fortunate I had saved a schematic of the cannon otherwise I would have lost the design completely. These issues can be fixed by installing carpet mod and running optimisations such as OptimizedTnT and OptimizedFastEntityMovement.
OptimizedTnT is an ideal solution for optimizing TnT because if multiple TnT entities explode at the same location, instead of processing the blast knockback formula independently for each TnT, it simply combines their effects into a single calculation vastly improving performance while maintaining behaviour.
OptimizedFastEntityMovement is also an ideal solution because it makes it so entities ONLY process collisions from blocks directly in the path of each XYZ axis that the motion is processed along, preserving the current entity motion behaviour while also vastly reducing the number of computations.
But unfortunately some of my viewers just wanted to plug and chug the cannon and didn't bother watching the whole video. Now I am dealing with players getting angry at me for designing a contraption in minecraft which crashes their game and renders their worlds unrecoverable all because of a lack of optimisation in the game code.
As an example here is a world download with the cannon positioned at 4K,4K in the overworld and setup to fire a payload at 0,0:
https://www.mediafire.com/file/vpf6ctq0cvfl0p7/Orbital_Strike_Crash_Test.zip/file
Instructions are as follows:
- Join the world and wait 1 minute
- Press the Button labelled "Start Cannon"
- The player will be teleported to 0,0,0 and the cannon will begin charging
Note the TPS drop significantly due to large quantities of TnT performing inefficient calculations
Note that eventually the game becomes unresponsive due to excessive collision checks as the cannon fires
Note that the cannon works perfectly fine with optimizations running
You can also find the video about the cannon here:
An entity processing its motion on the X, Y and Z axis will check for collisions with blocks within a volume enclosed by the axis of motion. This is in spite of the fact that the entity can ONLY collide with blocks within each axis of motion which are processed independently every tick.
This culminated into a devastating effect when I fired a cannon 2000 blocks, which is only a fraction of it's maximum range, and then my game froze and the world was unrecoverable. It was fortunate I had saved a schematic of the cannon otherwise I would have lost the design completely. These issues can be fixed by installing carpet mod and running optimisations such as OptimizedTnT and OptimizedFastEntityMovement.
OptimizedTnT is an ideal solution for optimizing TnT because if multiple TnT entities explode at the same location, instead of processing the blast knockback formula independently for each TnT, it simply combines their effects into a single calculation vastly improving performance while maintaining behaviour
.OptimizedFastEntityMovement is also an ideal solution because it makes it so entities ONLY process collisions from blocks directly in the path of each XYZ axis that the motion is processed along, preserving the current entity motion behaviour while also vastly reducing the number of computations.
But unfortunately some of my viewers just wanted to plug and chug the cannon and didn't bother watching the whole video. Now I am dealing with players getting angry at me for designing a contraption in minecraft which crashes their game and renders their worlds unrecoverable all because of a lack of optimisation in the game code.
As an example here is a world download with the cannon positioned at 4K,4K in the overworld and setup to fire a payload at 0,0:
https://www.mediafire.com/file/vpf6ctq0cvfl0p7/Orbital_Strike_Crash_Test.zip/file
Instructions are as follows:
- Join the world and wait 1 minute
- Press the Button labelled "Start Cannon"
- The player will be teleported to 0,0,0 and the cannon will begin charging
Note the TPS drop significantly due to large quantities of TnT performing inefficient calculations
Note that eventually the game becomes unresponsive due to excessive collision checks as the cannon fires
Note that the cannon works perfectly fine with optimizations running
You can also find the video about the cannon here:
An entity processing its motion on the X, Y and Z axis will check for collisions with blocks within a volume enclosed by the axis of motion. This is in spite of the fact that the entity can ONLY collide with blocks within each axis of motion which are processed independently every tick.
This culminated into a devastating effect when I fired a cannon 2000 blocks, which is only a fraction of it's maximum range, and then my game froze and the world was unrecoverable. It was fortunate I had saved a schematic of the cannon otherwise I would have lost the design completely. These issues can be fixed by installing carpet mod and running optimisations such as OptimizedTnT and OptimizedFastEntityMovement.
OptimizedTnT is an ideal solution for optimizing TnT because if multiple TnT entities explode at the same location, instead of processing the blast knockback formula independently for each TnT, it simply combines their effects into a single calculation vastly improving performance while maintaining behaviour (MC-260762).
OptimizedFastEntityMovement is also an ideal solution because it makes it so entities ONLY process collisions from blocks directly in the path of each XYZ axis that the motion is processed along, preserving the current entity motion behaviour while also vastly reducing the number of computations (this issue).
But unfortunately some of my viewers just wanted to plug and chug the cannon and didn't bother watching the whole video. Now I am dealing with players getting angry at me for designing a contraption in minecraft which crashes their game and renders their worlds unrecoverable all because of a lack of optimisation in the game code.
As an example here is a world download with the cannon positioned at 4K,4K in the overworld and setup to fire a payload at 0,0:
https://www.mediafire.com/file/vpf6ctq0cvfl0p7/Orbital_Strike_Crash_Test.zip/file
Instructions are as follows:
- Join the world and wait 1 minute
- Press the Button labelled "Start Cannon"
- The player will be teleported to 0,0,0 and the cannon will begin charging
Note the TPS drop significantly due to large quantities of TnT performing inefficient calculations
Note that eventually the game becomes unresponsive due to excessive collision checks as the cannon fires
Note that the cannon works perfectly fine with optimizations running
You can also find the video about the cannon here:
relates to
An entity processing its motion on the X, Y and Z axis will check for collisions with blocks within a volume enclosed by the axis of motion. This is in spite of the fact that the entity can ONLY collide with blocks within each axis of motion which are processed independently every tick.
This culminated into a devastating effect when I fired a cannon 2000 blocks, which is only a fraction of it's maximum range, and then my game froze and the world was unrecoverable. It was fortunate I had saved a schematic of the cannon otherwise I would have lost the design completely.
These issues can be fixed by installing carpet mod and running optimisations such as OptimizedTnT and OptimizedFastEntityMovement.
OptimizedTnT is an ideal solution for optimizing TnT because if multiple TnT entities explode at the same location, instead of processing the blast knockback formula independently for each TnT, it simply combines their effects into a single calculation vastly improving performance while maintaining behaviour (MC-260762).
OptimizedFastEntityMovement is also an ideal solution because it makes it so entities ONLY process collisions from blocks directly in the path of each XYZ axis that the motion is processed along, preserving the current entity motion behaviour while also vastly reducing the number of computations (this issue).
But unfortunately some of my viewers just wanted to plug and chug the cannon and didn't bother watching the whole video. Now I am dealing with players getting angry at me for designing a contraption in minecraft which crashes their game and renders their worlds unrecoverable all because of a lack of optimisation in the game code.
As an example here is a world download with the cannon positioned at 4K,4K in the overworld and setup to fire a payload at 0,0:
https://www.mediafire.com/file/vpf6ctq0cvfl0p7/Orbital_Strike_Crash_Test.zip/file
Instructions are as follows:
- Join the world and wait 1 minute
- Press the Button labelled "Start Cannon"
- The player will be teleported to 0,0,0 and the cannon will begin charging
Note the TPS drop significantly due to large quantities of TnT performing inefficient calculations
Note that eventually the game becomes unresponsive due to excessive collision checks as the cannon fires
Note that the cannon works perfectly fine with optimizations running
You can also find the video about the cannon here:
An entity processing its motion on the X, Y and Z axis will check for collisions with blocks within a volume enclosed by the axis of motion. This is in spite of the fact that the entity can ONLY collide with blocks within each axis of motion which are processed independently every tick.
This culminated into a devastating effect when I fired a cannon 2000 blocks, which is only a fraction of it's maximum range, and then my game froze and the world was unrecoverable. It was fortunate I had saved a schematic of the cannon otherwise I would have lost the design completely.
OptimizedFastEntityMovement is also an ideal solution because it makes it so entities ONLY process collisions from blocks directly in the path of each XYZ axis that the motion is processed along, preserving the current entity motion behaviour while also vastly reducing the number of computations (this issue).
But unfortunately some of my viewers just wanted to plug and chug the cannon and didn't bother watching the whole video. Now I am dealing with players getting angry at me for designing a contraption in minecraft which crashes their game and renders their worlds unrecoverable all because of a lack of optimisation in the game code.
As an example here is a world download with the cannon positioned at 4K,4K in the overworld and setup to fire a payload at 0,0:
https://www.mediafire.com/file/vpf6ctq0cvfl0p7/Orbital_Strike_Crash_Test.zip/file
Instructions are as follows:
- Join the world and wait 1 minute
- Press the Button labelled "Start Cannon"
- The player will be teleported to 0,0,0 and the cannon will begin charging
Note the TPS drop significantly due to large quantities of TnT performing inefficient calculations
Note that eventually the game becomes unresponsive due to excessive collision checks as the cannon fires
Note that the cannon works perfectly fine with optimizations running
You can also find the video about the cannon here:
An entity processing its motion on the X, Y and Z axis will check for collisions with blocks within a volume enclosed by the axis of motion. This is in spite of the fact that the entity can ONLY collide with blocks within each axis of motion which are processed independently every tick.
This culminated into a devastating effect when I fired a cannon 2000 blocks, which is only a fraction of it's maximum range, and then my game froze and the world was unrecoverable. It was fortunate I had saved a schematic of the cannon otherwise I would have lost the design completely.
OptimizedFastEntityMovement is also an ideal solution because it makes it so entities ONLY process collisions from blocks directly in the path of each XYZ axis that the motion is processed along, preserving the current entity motion behaviour while also vastly reducing the number of computations (this issue).
But unfortunately some of my viewers just wanted to plug and chug the cannon and didn't bother watching the whole video. Now I am dealing with players getting angry at me for designing a contraption in minecraft which crashes their game and renders their worlds unrecoverable all because of a lack of optimisation in the game code.
As an example here is a world download with the cannon positioned at 4K,4K in the overworld and setup to fire a payload at 0,0:
https://www.mediafire.com/file/vpf6ctq0cvfl0p7/Orbital_Strike_Crash_Test.zip/file
Instructions are as follows:
- Join the world and wait 1 minute
- Press the Button labelled "Start Cannon"
- The player will be teleported to 0,0,0 and the cannon will begin charging
Note the TPS drop significantly due to large quantities of TnT performing inefficient calculations
Note that eventually the game becomes unresponsive due to excessive collision checks as the cannon fires
Note that the cannon works perfectly fine with optimizations running
You can also find the video about the cannon here:
The bug
An entity processing its motion on the X, Y and Z axis will check for collisions with blocks within a volume enclosed by the axis of motion. This is in spite of the fact that the entity can ONLY collide with blocks within each axis of motion which are processed independently every tick.
This culminated into a devastating effect when I fired a cannon 2000 blocks, which is only a fraction of it's maximum range, and then my game froze and the world was unrecoverable. It was fortunate I had saved a schematic of the cannon otherwise I would have lost the design completely.
OptimizedFastEntityMovement from the Carpet Mod is also an ideal solution because it makes it so entities ONLY process collisions from blocks directly in the path of each XYZ axis that the motion is processed along, preserving the current entity motion behaviour, while also vastly reducing the number of computations (this issue).To reproduce
As an example here is a world download with the cannon positioned at 4K,4K in the overworld and setup to fire a payload at 0,0:
https://www.mediafire.com/file/vpf6ctq0cvfl0p7/Orbital_Strike_Crash_Test.zip/file
Instructions are as follows:
- Join the world and wait 1 minute
- Press the Button labelled "Start Cannon"
- The player will be teleported to 0,0,0 and the cannon will begin charging
Note the TPS drop significantly due to large quantities of TnT performing inefficient calculations
Note that eventually the game becomes unresponsive due to excessive collision checks as the cannon fires
Note that the cannon works perfectly fine with optimizations running
You can also find the video about the cannon here:
The bug
An entity processing its motion on the X, Y and Z axis will check for collisions with blocks within a volume enclosed by the axis of motion. This is in spite of the fact that the entity can ONLY collide with blocks within each axis of motion which are processed independently every tick.
This culminated into a devastating effect when I fired a cannon 2000 blocks, which is only a fraction of it's maximum range, and then my game froze and the world was unrecoverable. It was fortunate I had saved a schematic of the cannon otherwise I would have lost the design completely.
OptimizedFastEntityMovement fromtheCarpet Mod isalsoan ideal solution because it makes it so entities ONLY process collisions from blocks directly in the path of each XYZ axis that the motion is processed along, preserving the current entity motion behaviour, while also vastly reducing the number of computations (this issue).To reproduce
As an example here is a world download with the cannon positioned at 4K,4K in the overworld and setup to fire a payload at 0,0:
https://www.mediafire.com/file/vpf6ctq0cvfl0p7/Orbital_Strike_Crash_Test.zip/file
Instructions are as follows:
- Join the world and wait 1 minute
- Press the Button labelled "Start Cannon"
- The player will be teleported to 0,0,0 and the cannon will begin charging
Note the TPS drop significantly due to large quantities of TnT performing inefficient calculations
Note that eventually the game becomes unresponsive due to excessive collision checks as the cannon fires
Note that the cannon works perfectly fine with optimizations running
You can also find the video about the cannon here:
relates to
The bug
An entity processing its motion on the X, Y and Z axis will check for collisions with blocks within a volume enclosed by the axis of motion. This is in spite of the fact that the entity can ONLY collide with blocks within each axis of motion which are processed independently every tick.This culminated into a devastating effect when I fired a cannon 2000 blocks, which is only a fraction of it's maximum range, and then my game froze and the world was unrecoverable. It was fortunate I had saved a schematic of the cannon otherwise I would have lost the design completely.
OptimizedFastEntityMovement from Carpet Mod is an ideal solution because it makes it so entities ONLY process collisions from blocks directly in the path of each XYZ axis that the motion is processed along, preserving the current entity motion behaviour, while also vastly reducing the number of computations (this issue).To reproduce
As an example here is a world download with the cannon positioned at 4K,4K in the overworld and setup to fire a payload at 0,0:
https://www.mediafire.com/file/vpf6ctq0cvfl0p7/Orbital_Strike_Crash_Test.zip/file
Instructions are as follows:
- Join the world and wait 1 minute
- Press the Button labelled "Start Cannon"
- The player will be teleported to 0,0,0 and the cannon will begin charging
Note the TPS drop significantly due to large quantities of TnT performing inefficient calculations
Note that eventually the game becomes unresponsive due to excessive collision checks as the cannon fires
Note that the cannon works perfectly fine with optimizations running
You can also find the video about the cannon here:
The bug
The block collisions method for entities is incredibly inefficient and performs insanely redundant computations for no reason. Each tick when an entity calls the movement method to update it's position, it will first move in the Y axis, then move in the X or Z depending on which motion is greater then finish moving along the remaining axis for that tick. This method is well established to simulate entity motion in a way that is computationally efficient as it allows collision checks to be done independently for each face of an entities hitbox.
Unfortunately however, the collisions method is poorly designed to utilise the movement method for efficient collision calculations. As it will start by collecting block collision boxes from the volume projected by the motion axes, then iterate through this volume for each block, checking whether the hitbox of the entity intersects the block faces in each axis. Which is absurd because for fast moving entities the volume projected by the motion axes can contain millions of blocks that have nothing to do with the motion axes. This results in the block collisions method scaling extremely poorly as the velocity of collisions increases.
To get an idea of how bad the scaling is, consider that a TnT entity with Motion:[1000.0, 100.0, 1000.0] would check 100 million positions for collisions despite only realistically being able to collide with 8400 blocks in total. So that is pretty much 100 million calculations the game does for literally no reason but to waste energy.
The currently implemented method incorporates no mechanisms to discard redundant collision checks and free up computation for other more crucial tasks. Some effective measures to improve collisions would be to check the load state of chunks intersecting the motion axes in the order they are processed. So for example an entity with Motion:[800.0,100.0,900.0] would check the load state of chunks Z+900 then X+800 from the entities current position and discard collision checks for unloaded chunks. Then the method could check whether the subchunks intersecting the lines Y+100, Z+900, X+800 contain blocks other than air and skip collision checks for subchunks containing air. Then finally the method would iterate over individual block collisions along the motion axes where the entity actually moves.
If you have multiple TnT exploding in the same position, they will each perform their calculations of knockback and blocks broken independently. Despite the fact that the effect of their explosions can be combined linearly. This issue relates to MC-260743 and MC-238249. Features such as OptimizedTnT from carpet mod have working implmentantions which do not affect vanilla behviours:
OptimizedTnT is an ideal solution for optimizing TnT because if multiple TnT entities explode at the same location, instead of processing the blast knockback formula independently for each TnT, it simply combines their effects into a single calculation vastly improving performance while maintaining behaviour. This also includes a fix for MC-238249 which eliminates the redundant checks on the blast origin if the TnT is in a state where it does not deal damage to blocks.
As an example here is a world download with a TnT cannon positioned at 4K,4K in the overworld and setup to fire a payload at 0,0:
https://www.mediafire.com/file/vpf6ctq0cvfl0p7/Orbital_Strike_Crash_Test.zip/file
Instructions are as follows:
- Join the world and wait 1 minute
- Press the Button labelled "Start Cannon"
- The player will be teleported to 0,0,0 and the cannon will begin charging
Note the TPS drop significantly due to large quantities of TnT performing inefficient calculations
Note that eventually the game becomes unresponsive due to excessive collision checks as the cannon fires
Note that the cannon works perfectly fine with optimizations running
You can also find the video about the cannon here:
I wasn't able to reproduce a crash, but I was able to reproduce extreme server-side lag, to the point where the game stalled for several minutes.
The crash takes a while because of the extreme lag slowing down the charging process, it should normally take 90s but ran at around 4 TPS for me so it took about 8 minutes. This is a relatively small cannon btw, normally these types of cannon use a lot more TnT.
You should probably make an additional report for the explosion thing and make this about the collision check only. It's different from the report ampolive linked, so it should be its own issue.
A report specifically about the explosion calculations would be made redundant by MC-238249 which goes into a lot more detail on that.
That report is about the origin position being checked for eyery ray, while your report mentions another optimization potential (combining multiple explosions on the same tick and same position into 1 explosion).
Agreed with Dhranios, that probably should be separated into another ticket.
Can you please split out the issues as indicates in previous comments? Thanks!
I've removed all the extra information from the summary, leaving only the motion performance issue. The ticket containing the other TNT performance issue that was previously cited here is at MC-260762.