This video is mostly to help document troubleshooting efforts to correct some unfortunate internal physics engine collision issues for large collision meshes, specifically in Godot4 (but present using Godot Physics in 3.5 as well)
It is important to note the following:
-The Player controller is a CharecterBody3D(KinematicObject) utilizing a capsule mesh and capsule collider shape
-The Terrain collider is a StaticBody3D utilizing a dynamically generated/sampled HeightMapShape3D shape/mesh
-No physics objects are scaled in this demonstration, all objects are utilizing native scaling of (1,1,1) (Demonstrated at the end of the video clip)
-All weird and unusual player movement is a result of interactions with the terrain collision and not of latency, frame drop, or anything else WITH THE EXCEPTION of when a new chunk of collision is generated briefly in the video, that one hiccup is due to the mesh generation at run-time
-This issues persist across 3.5-4.0beta7 in Godot Physics, and across several mesh shape types (concave, convex, heightmapshape3d)
-The counter running in the output window in the background editor is displaying the NUMBER of collisions per physics tic, up to the hard-coded maximum of 6 collisions. There should realistically never be more than 2-3 collisions between the same two physics objects at any given physics tic, but even the edge-cases where more than two collisions occur (two walls and the ground or ceiling) occurring in the demonstrated examples, at most only two collisions should be occurring here (only two collisions per axis per physics tic) This expected result is observed when utilizing Bullet physics in 3.5, with no more than 2 collisions occurring while on the Terrain collider, but Godot Physics consistently returns 3-6 collisions even on relatively flat planes.
-The red arrows are a custom debug visualizer being generated to demonstrate the location of the collision and the normal vector of the collision. They are only triggered in this example when the normal vector deviates significantly from the expected UP Vector (0,1,0) via dot product of more than 0.5