I’m experiencing an issue with unwanted character bouncing when moving on a terrain generated from a heightmap and I’m using Havok Plugin. The character is controlled using the .setLinearVelocity function, and despite numerous adjustments to the physics body parameters (provided below), the bounce effect persists. I’ve attached a video for reference, and I’m seeking advice on how to prevent this bouncing.
Hmmm the first thing that I would check is if the dir-vec isn’t pointing too much to the y direction? I tried setting up a similar scenario to yours on a playground, and I’m not seeing the bounce, so there might be a difference there to indicate why it’s happening on your case: Player Capsule movement havok | Babylon.js Playground (babylonjs.com)
Oh thanks for pointing this, I hadn’t noticed! I tried experimenting a bit more with this setup, and using applyImpulse instead of setLinearVelocity seems to make the bounces less proeminent, but didn’t eliminate them: Player Capsule movement havok | Babylon.js Playground (babylonjs.com)
I’ll tag @Cedric here who might know of a better way
My vision of what’s happening is, when the capsule is moved forwards, its geometry collides with the ground’s triangles at very slight angle, and this influences on the response impulse causing the bounce. If a flat ground with only one subdivision is used (so just two big triangles), I don’t see a bounce. And the reported collision normals only point to the y axis:
Yes, exactly. This is how to reproduce the issue. I used the debug physics viewer and noticed that it only happens on every edge. But, I guess it shouldn’t happen, right? At least there should be a work around.
I did some tests with friction/restitution tweaking, then with different shapes for the player (mesh, capsule) and different shapes for the ground.
The only combination without jumps is when the ground is a box. It doesn’t look like an issue on bjs side. But a bug or precision issue with Mesh shape. Have you seen something similar @eoin ?
This could very well be the same issue most physics engines seem so suffer from.
Forces become velocities, and velocities become position displacements. From this new position, whether you use CCD or the more traditional discrete solution, collision detection is performed, and a collision normal is calculated. In this example, you’re looking for a (0,1,0) unit vector, but this might not always be the case. The problem is, that whether you use SAT, GJK, AABBs, OBBs etc. etc. it is custom for collision detection algorithms to use the vector providing the shortest path of penetration to solve the collision. When you hit a triangle like the above case, that shortest path might just as well be on the Z or X axis.
A common approach is to intercept the collision normal, and when a collision with a mesh shape is detected, either recalculate the normal or simply replace it with that of the triangle normal.
I am not sure Havok provides such functionality, though
You’re correct-- that playground still has bouncing! Just less so than that thread’s original playground.
I didn’t try myself, but judging from Cedric’s response here, it seems that tweaking the friction/restitution wouldn’t have fixed the bouncing of that playground anyway. Hmm…
Raggar and carolhmj are 100% correct. This “bouncing” is simply the outcome of the geometry. When the closest point between the triangle and the capsule is the triangle face, the normal will always point in the direction of the triangle face. However, when the closest point is on the edge, the normal needs to be able to take any value (depending what the other shape is and where it’s located in relation to the edge) and moving quickly towards that edge can result in the bouncing you see.
Erin Catto has a good blog post on this problem (it’s specifically discussing Box2D, but it’s a problem all physics engines have to deal with) if you want more info: Ghost Collisions :: Box2D
We have enabled some additional processing which should fix this for you, if you update your Havok WASM to the latest version (1.1.1).