I don’t know much about things like this, but I would try to set the friction of the rigidbody component of the wall to 0. If that didn’t help I would play around with the values of all rigidbodies to see if the result improved.
This effect is called tunnelling. The physics simulation is done in steps. If the object travels fast, then the step size increases, making it possible for the wall to be not noticed. One way to solve it is to increase the continuous collision detection (CCD) of the fast rigidbody. This will increase amount of simulation steps, making them smaller and less likely to skip a wall.
You can find an example of a script that can be attached to a fast moving entity and allow to adjust its simulation properties here:
As mentioned, the physics world simulation is not continuous, as it takes resources.
How does Ammo know if something collided with something? It does this by simply going through all the objects in its world and calculates if something intersects something. What about moving objects? It does it in steps.
For example with your moving cube box. At the first step it goes the same way through all objects and checks if box collided with something. Then some time passes and it makes a second simulation step. It looks at your box and says, ok, after this much time with it moving at that speed, it should be over here, so lets check if it collides with something. And does the same thing - goes through all objects and sees if it intersects anything.
By default, Ammo tries to do 60 simulation steps per second. With the script above you can adjust it. If your object moves fast, then at each step the cube will travel quite a distance. When Ammo detects that the box has collided with something, it will place it at the last safe position during previous step. Since the cube travels quite a distance between each step, there might appear a small gap between the wall and the object, because that is the last safe place Ammo knows about.
Increasing the simulation steps will reduce that gap, as Ammo will have a last safe place closer to the wall, but it will never eliminate it. It would also increase demand on CPU and might affect the performance.
As the guys suggested, you can use a raycast to find where the wall is precisely. For example, when player moves right, cast a ray to the right and see where the wall is. This will give you a safe position as close to the wall as possible. Then, give your cube an impulse as you do now, but when your cube stops, you teleport it to that safe position. This will be a tiny adjustment for a single frame to close the possible gap.
Edit: all of this and more in the future can be avoided if you don’t use physics
I have a suggestion. If you want to continue using dynamic physics, use this.entity.rigidbody.linearVelocity() instead of applyForce. You can then apply a constant force without the rigidbody getting too fast, and you can still use dynamic phyiscs.
.linearVelocity is a property and not a function, like .angularVelocity. They contain the current velocities of the body in vector format. I would leave the physics engine to adjust that value, but one may simply limit the maximum or minimum velocities a body may have.
Also I have tried using linearVelocity to check for the player’s velocity while applying forces, but it seems that it doesn’t change when applying forces, so when I used it to limit speed, it didn’t work. Not sure if this was intended or unintentional.
Right, so a linear velocity describes the speed at which the body moves at the current frame. In particular, it describes the speed on each world axis X, Y and Z, which can be conveniently described by a 3D vector.
I am not sure about your past case @DevPlex01, but if you set a velocity for all axis to 0, the body will immediately stop. One thing to take note here, is you need to make sure you stop the body after applying a force. If you stop a body, then at the same frame, your code applies a force - it will continue moving. Same thing for limiting the maximum speed.