Collisions: Difference between revisions

From Minecraft Parkour Wiki
Content added Content deleted
(Created page with "[WIP] Minecraft's collision physics is very simplistic in nature, yet it contains many glitches. As a reminder, Minecraft's physics is updated 20 ticks per second. The p...")
 
(started rewriting. Need code, visuals, and 1.14+ explanation)
Line 1: Line 1:
Minecraft's collision physics is very simplistic, yet it contains many glitches.
[WIP]


Instead of ray-tracing the collisions, the game simply attempts to move the player sequentially along each axis.
Minecraft's collision physics is very simplistic in nature, yet it contains many glitches.


As a reminder, Minecraft's physics is updated 20 [[ticks]] per second. The player's movement and collisions are calculated once every tick.
As a reminder, Minecraft's physics is updated 20 [[ticks]] per second. The player's movement and collisions are updated once per tick.




== Order of collisions and X/Z Facing ==
== Order of collisions ==
Movement is not checked linearly: instead, the game does # steps:
Every tick, after the player's velocity has been updated, the game does these steps to check collisions:


* Move the player along the Y axis until there is a vertical collision. In that last case, if the player's Y speed is negative,
* Move the player along the Y axis. If a vertical collision is detected when falling, the player is now considered to be on ground.
* Move the player along the X axis until there is a horizontal collision.
* Move the player along the X axis.
* Move the player along the Z axis until there is a horizontal collision.
* Move the player along the Z axis.
* If a horizontal collision was detected, we know a wall is blocking the player's path, but perhaps it's low enough that the player can simply.
* If the player is on ground and collided with a wall, perhaps they could step on top of it (e.g. if the wall is just a slab).
** See [[Stepping]] for explanations and visuals.
** The game does another calculation to see if the player could go further when taking [[stepping]] into account.
** This mechanic is responsible for [[Blip|Blips]] and [[Jump Cancel|Jump-Cancel]], and their glitched variants.
** Otherwise, the wall is considered too tall to step onto.
* End


== X/Z Facing ==
Due to the X axis being processed before the Z axis, they are fundamentally asymetric: it's important to distinguish "X-facing" jumps from "Z-facing" ones.


* '''X-facing''' refers to jumps that point towards East/West.
== Some examples ==

* '''Z-facing''' refers to jumps that point towards North/South.

Some jumps are only possible when facing one axis or the other.


Players tend to find Z-facing neos more intuitive, but X-facing neos can actually be a bit easier.

Z-facing neos are very similar to linear jumps. To convert a neo to its equivalent, simply add 1.2 to its distance and increase its [[Tiers|tier]] by one.

For example, a triple neo is equivalent to a "4.2+0.25" (these equivalents cannot be built, but are useful for analysis, as it's quite easy to determine whether a linear jump is possible or not).


The axis of a jump can be checked with [[Debug Screen|F3]].

== 1.14+ ==
[WIP]

Revision as of 19:37, 22 May 2021

Minecraft's collision physics is very simplistic, yet it contains many glitches.

Instead of ray-tracing the collisions, the game simply attempts to move the player sequentially along each axis.

As a reminder, Minecraft's physics is updated 20 ticks per second. The player's movement and collisions are updated once per tick.


Order of collisions

Every tick, after the player's velocity has been updated, the game does these steps to check collisions:

  • Move the player along the Y axis. If a vertical collision is detected when falling, the player is now considered to be on ground.
  • Move the player along the X axis.
  • Move the player along the Z axis.
  • If the player is on ground and collided with a wall, perhaps they could step on top of it (e.g. if the wall is just a slab).
    • See Stepping for explanations and visuals.
    • This mechanic is responsible for Blips and Jump-Cancel, and their glitched variants.

X/Z Facing

Due to the X axis being processed before the Z axis, they are fundamentally asymetric: it's important to distinguish "X-facing" jumps from "Z-facing" ones.

  • X-facing refers to jumps that point towards East/West.
  • Z-facing refers to jumps that point towards North/South.

Some jumps are only possible when facing one axis or the other.


Players tend to find Z-facing neos more intuitive, but X-facing neos can actually be a bit easier.

Z-facing neos are very similar to linear jumps. To convert a neo to its equivalent, simply add 1.2 to its distance and increase its tier by one.

For example, a triple neo is equivalent to a "4.2+0.25" (these equivalents cannot be built, but are useful for analysis, as it's quite easy to determine whether a linear jump is possible or not).


The axis of a jump can be checked with F3.

1.14+

[WIP]