The Scene
I have an entity scene with 2 planes. One acts as the ground and has a plane physics shape. The second plane, with a mesh physics shape, acts as a ramp of sorts for when a sphere is launched at its direction using ApplyLinearImpulse. The sphere, ground, and ramp have their own restitution values assigned.
Expected Behaviour
The sphere should roll on the ground until it reaches the ramp at which it should roll uphill on the ramp and start rolling downhill again if the force was not enough to push it over the edge.
Actual Behaviour
The sphere rolls on the ground until it reaches the transition point from the ground to the ramp and suddenly acts as if it has collided with something and then jumps into the air. This does not occur when ramp has plane collider, or when all restitution values are set to 0 for both sphere and mesh ramp.
The images above show how the ball in front bounces upwards when reaching the mesh collider ramp. The ball in the back just simply rolls uphill onto the plane collider ramp. This occurs when either the ramp or ball have any value of restitution greater than 0, this still occurs for small values such as 0.001. The collision occurs at the start of the ramp, but still has some forward momentum that’s why it’s a bit beyond the start of the ramp in the images above.
How would I go about mitigating this behaviour?
I do want my ball to have bounciness as this will be part of the behaviour of the ball. I have been considering manually simulating bounciness, but I’m curious if someone has a workaround/fix for this. Making all the colliders planes is out of the question because then I cannot implement curved ramps.
@aburger22 : Given that you don’t have this issue with the plane, you should be able to also get the same behavior with the mesh, given that the plane is just a quad collider as you can see here in this baking method:
So, maybe check your mesh and see what the difference here is to understand the source of the issue better.
Also, I suggest you enable the contact display by adding the Physics Debug Display authoring component and activating the contact display. This should allow you to see what happens step by step and where the collisions with the two ramps differ.
I would like to say a 1000 THANKS YOU’s to both you and @Sima_Havok . Using the Physics Debug Display component and some transparent materials, I quickly realized where the mistake occurred.
The REAL Problem & Solution
My ramp with the mesh collider was inset by a few units into the ground surface. This caused the ball to take both the ground surface and the ramp colliders into account where these two colliders were very close to each other causing a “double” collision or as @Sima_Havok calls it a Ghost collision which resulted in a SIGNIFICANTLY larger collision force being registered. I fixed this by raising the ramp out of the ground to where the colliders barely overlaps and with slight adjustments to the restitution values of the mesh collider has made this problem non-existent.
Can you try configuring “Friction Type” = “Patch Friction Type” and “Improved Patch Friction” enabled in the Physics Settings? Then try again with the original scene.
Taking “double collisions” rang a bell about an ancient problem with collisions and frictions in Unity. From Unity 5 to Unity 2020 collisions and friction were severely faked for performance, and the results strongly depended on the number of contacts. From Unity 2021 collisions and friction may be simulated realistically with the mentioned options so the results are quite close to the physically correct behavior regardless the number of contacts.
Patch Friction Type was selected by default. Enabling “Improved Patch Friction” does not seem to make any discernible difference as the contacts seem the same as before. A slight & unexpected bounce is still present when overlapping. The images below paint a stark difference between the contacts (green arrows) registered between the ball and a mesh collider (top image) and ball with plane collider (bottom image).
After debugging somewhat, I have since switched to almost purely utilizing primitive shapes wrapped with complex render meshes. The performance difference accompanied with reliability at high velocities has convinced me to make this choice.
Thank you for the suggestion, I will certainly keep this tidbit in mind for the future.
Additional note: while I was still exploring mesh collider shapes, I found that adding a small primitive onboarding collider further helped in making a more realistic cross over between colliders. Lift the plane out some more from the floor surface and place a plane physics shape as a connecter between the floor and the mesh collider, with the plane collider “in front” of the mesh collider so that the ball rolls over the plane and “falls” onto the mesh. This is helpful when the approaching collider travels at a higher velocity as the solution I previously discussed would still cause a bounce to register at said higher velocities.
Basically, use primitives to force the velocity as parallel as possible to the mesh surface. From my observations, a mesh registers more contact points which results in a higher likelihood of collision leading to a bounce and also higher resulting friction. Ball does not roll as far up the ramp when compared to a primitive shape.
