Walking on MeshColliders generate incorrect collisions

Hi,
I've been trying to make a platforming character controller using the new Physics, and got some extremely weird bump up/bump back when walking on anything else than BoxCollider or SphereCollider.

I made a minimal scene reproducing this behavior.
With the default Box, the sphere travel smoothly as expected.
With the default Plane, the sphere will get randomly bumped upward.

Is this somehow the intended behavior, and if so, what are you supposed to do to make your characters walking smoothly and predictably ? Or is it an actual bug ? This happen both on Unity 2019.3.13 and .3.14.

 

Do you have a StaticOptimizeEntity on the colliders (or their parents)? I've encountered an issue where a static-optimized mesh collider seems to be completely ignored by ColliderCast, but not by CalculateDistance. Maybe a related issue?

 

No StaticOptimizeEntity anywhere in my project.
Just in case I tried adding a non-kinematic rigidbody / dynamic physics body to that repro-scene's ground (in case the conversion automatically add that static optimization) but the wrong collisions are still there.

 

Hello, I think this might be an instance of phantom collisions. I'm aware of a number of threads on this:

https://forum.unity.com/threads/rolling-ball-bounces-on-mesh-edges.766397/
https://forum.unity.com/threads/ball-rolling-on-mesh-hits-edges.772760/
https://forum.unity.com/threads/ghost-collisions-on-adjacent-box-colliders.850951/
https://forum.unity.com/threads/what-does-collisionevents-normal-returns.811143/

Unfortunately, I'm unaware of a full solution to this issue. In the last thread I've post a partial solution that works only for internal edges but fails to correctly handle transitions between different colliders.

 

Thanks for the links. I'm kinda surprised that there is no actual fix for something that game-breaking even 6 months after.
Basically if you need smooth Dots-compatible physics you have no choice but to use Havok ? That's a bummer.

 

I get this issue in my project too. My workaround is to have two colliders on my ‘character’ one which has no bounciness and only collides with the floor (using layers) and the other collider does all other collision.

i also needed to set the contact offset value in physics settings to 0.0001

 

I changed that Contact Offset value and gave everyone's collider a physics material with no restitution, but it didn't change anything. Did you do something else ?

 

Oh, you're in DotsPhysics? sorry, I'm in Physx.

 

Well nevermind, I switched to the Havok backend and ... it got the exact same bug, except much worse.
At that point I'm considering just cutting my losses and giving up on ECS entirely. Not much point to it if only the old PhysX backend is actually working, and constant data exchange between ECS code and PhysX would kill any hope at decent performances.

 

that’s sad to hear because i was hoping to upgrade my physics to DOTS physics for the promised determinism . But it that’s a a cost of hopping on collider edges I can’t

 

Well, I don't believe they are gonna fix it because it does not require fix, so to say. It's one of the trade-offs that Speculative CCD algorithm requires I think. More on this here https://docs.unity3d.com/Manual/ContinuousCollisionDetection.html

Are you sure that you did not messed something up like different physics engines on different bodies or so? Asking because I'm thinking of a Havok as a backup solution if I did not manage to make it work.
I'm fighting the same battle and you can find my progress in this thread, to add-up to the @mpforce1 list of threads.

 

I wonder if CCD could be turned into an option relatively easily? Like just a bool that determines if we expand the AABBs in the broadphase or not

It seems like it could help a lot of people who are facing this issue and wouldn't mind the risk of colliders going through things at high speed

 

But, then you'll need to query against all colliders, and not just the ones that are inside the AABB, which wont be as time efficient as this one.

 

I mean just moving the collider with velocity, and then generating the contacts at the new position with the regular non-expanded AABB, like what you get in classic monobehaviour physics when not using CCD

Or does speculative CCD bring a performance improvement over no CCD at all?

 

I'm really new to whole this physics thing but my understanding is that, without AABB, any dynamic rigid body could collide with any other dynamic rigid body, so you can't just move it with velocity and check collisions for that position. My reasoning is that you'll need to move all the rigid bodies and then do the check. But even that does not solve the problem because one body can bounce from another so you'll need to do another pass and so on. Maybe CCD actually does this processes but it at least limits it to the AABB and not the whole world.

I believe that anything not caching world state is counted as CCD

 

Did you just run this with Havok, or did you do the setup required to "enable welding" on specified bodies? Havok doesn't solve this case by default as it is more expensive, so users need to opt in on bodies of interest...

 

Oh. my.
Thank you, that fixed it ! Both in the repro project and in the actual game.
Guess I will stick with Havok then, and can continue my ECS-related projects thank to you.

 

Glad to hear that! Please reach out if you have any other questions!

 

@petarmHavok Do you know if contact welding is on the roadmap for Unity Physics? In my current project we need a deterministic simulation, which Havok Physics doesn't provide. Based on all the threads about this issue it sounds like people, myself included, would be interested in at least the option to enable it.

 

What do you mean in "Havok Physics doesn't provide deterministic simulation"? Determinism on a particular platform is definitely there, it's only the cross-platform that's missing. Which one do you need?

Regarding contact welding, it's currently not on the roadmap. I'll let you know if that changes.

 

Thanks for getting back to me. We need cross platform determinism, however, in our project at least, when I enable Havok Physics I get non-deterministic results. Whereas, Unity Physics is deterministic on the same machine. In our setup we run a separate client and server world and sync the state of the world once at the start of the game. However, I find that these quickly fall out of sync with Havok Physics enabled. Is there something more we need to do in order for Havok to be same platform deterministic?

I notice that in the FAQs in the docs it says:

To me this implies that we need to be able to sync these internal caches or Havok won't work for our use case. If that's true do you know how we can do this? This might all come to nothing anyway since we eventually need cross platform determinism.

It's unfortunate that Unity aren't considering contact welding, do you know if there is anything else on the roadmap that will solve this problem?

 

Yes, you are right, the caches make Havok Physics non-deterministic for your scenarios.

And I'm sorry to say there is nothing other than welding that can solve the problems you are seeing. Now depending on your particular scenario, you might be able to avoid some of the issues by using simpler geometry. Also, we are discussing some solutions here: https://forum.unity.com/threads/sph...-with-mesh-collider-edge.889963/#post-5952542

I'll definitely note the rising need for this, and see if there are some simple ideas to get you started.

 

I second the need for both welding and cross platform determinism. In my case i need it for replays in a turn based physics game