2018.3 - Continuous speculative = wrong contact points [Case 1110660]

[KospY]

I was pretty excited to try the new collision detection “continuous speculative”, however after some tests it seem that the contact points are really inaccurate in this mode.
It’s maybe a bug (I wish) or it’s normal, anyway there is so much inaccuracy right now that you should avoid using it if you need to get precise contact points (especially if you use capsule colliders, contact points will be even more inaccurate)

Here is a video of my repro project (I can do a bug report if someone confirm me that it’s a bug)
wateryforsakenechidna
Note:

• Switch the video to HD for a better view
• At first I use discrete, then Continuous and at last Continuous speculative (at 16s)
• Red/yellow sphere are the contact points (red being the first one)
• Blue box use a box collider
• Green box is a capsule collider

[Edy]

That looks wrong to me. I’d file a bug with a repro case.

[hippocoder]

Please file and paste text not link, of case number in this thread, it surely will help.

[KospY]

I sent a bug report. Case 1110660.

[Sailendu]

What’s the current status of this bug report? How can I view the bug report page? Is there a way to find case 1110660?

[KospY]

I don’t know. I sent a bug report with the repro project but I never got any reply from Unity.
The issue is still open but it doesn’t appear on the public issue tracker. Maybe they wait more reports before accepting a new issue?

[hippocoder]

It probably went to your spam folder.

[MelvMay]

Looks like the bug hasn’t been processed by QA yet. I’ll ping QA / the 3D physics guys for you.

[MelvMay]

The nice 3D physics QA guy assigned the case to himself and will take a look soon.

[Sailendu]

In the documentation link below, I read that in “continuous speculative” method the bounding box in inflated to detect the collision. By doing this, it does not miss the collision but it may cause ghost collision and I think the collision contact points are wrong because of this. Is this supposed to be the correct way of doing collisions? Because if it is detected by inflating the bounding box, the collisions will not be accurate. And I tested in “continuous speculative” mode, if I try to collide to moving rigidbody spheres, they bounce off each other before even actually hitting.

Unity - Manual: Continuous collision detection (CCD)

[hippocoder]

The bounding box is merely an optimisation, it’s just using that to decide what to check, not actually detect AFAIK.

[cubaschi]

It seems that even continuous and continuous dynamic trigger ghost collisions.
In the video the tentacle is grabbing with joints to the metal and the joints are released on a certain pullforce. The tentacle consisting of joints then retracts.

The blue magnets are reacting to collisions and deactivating on a certain collision force applied. The blue tentacle is set to discrete and the green to continuous.
This is a huge distance to trigger ghost collisions and sadly a no go for us.

continuous

[paradizIsCool]

Hi, I’m going crazy with physics since few days and I’m seeing this post.
Here is my case :
Ball (green) are rigidBody with continues collision, freeze all rotations
Blue boxes are kinetic rigidody (box collider)
Reds are static colliders (box collider for contact at frame 3)

ball is moving due to forces applied.

auto simulation is disabled, simulation time is fixed at 0.02
magenta rays are drawn just after Physics.Simulate
Blue rays are drawn in OnCollisionEnter

My issue is that SweepTest finds the collision at frame 2, but simulation 3 don’t. With Simulation, green ball collides with blue box at frame 4 after being pushed by red wall behind blue box.

I’ve made tons of tests, increase solver iterations didn’t solve anything (1 or 255 give me the same result, using 6 for the screenshots).
Rigidbody everywhere/nowhere neither.
removing red box changes nothing about blue box collision time (still frame 4)

This happens only on rare angles. I just don’t understand why calling SweepTest works where simulation fails.

I don’t have a repo project but I can try to do it.

Using 2018.3.3f1 on mac, targeting ios

[KospY]

Quick update:
Still no news from Unity about this bug
Last update on my ticket (13 February) is: “We have been able to reproduce this bug and have sent it for resolution with our developers.”
Please Unity, can you do something?

[hippocoder]

They have. "We have been able to reproduce this bug and have sent it for resolution " means that they have done something and it’s up to the overall schedule and individual priorities.

[Partel-Lang]

ContinuousSpeculative mode also generates completely false contacts on near miss:

ContinuousSpeculative CollisionDetectionMode bug

Happens with all Unity 2018.3 and 2019 versions.

This is all the code used in that demo:

public GameObject debugSpherePrefab;

    private void OnCollisionEnter(Collision collision)
    {
        ProcessCollision(collision);
    }

    private void OnCollisionStay(Collision collision)
    {
        ProcessCollision(collision);
    }

    private void ProcessCollision (Collision c)
    {
        var debugSphere = Instantiate(debugSpherePrefab, c.GetContact(0).point, Quaternion.identity);
        debugSphere.AddComponent<Destroyer>();
    }

Happens with all collider types as far as I have tested.
Submitted another bug report.

Best,
Pärtel

[KospY]

Here is the link on the issue tracker:

Unity IssueTracker - Continuous speculative collision produces incorrect...

If you encounter this bug please vote, so they may fix it in the future.

[DavidSWu]

We have experienced the same ghost collisions ourselves.

I am not sure how Speculative collision detection is implemented under the hood, but in common situations, it would be useful to have a sphere collider that becomes a capsule collider when moving and letting us deal with the approximation knowing the specific limitations.
Similarly, a capsule could become a convex hull (or convex mesh collider) with an extrusion radius, a mesh collider becomes a new mesh collider with 2x points (many would be redundant, inside the hull but they won’t cause much harm).
Or for bonus points interpolate the rigid body and add further points for nonlinear movement (i.e. external forces such as gravity) and rotation.
A very common case for us is projectiles which generally use spheres as they are the fastest, and at high velocities, we don’t care about interpolating for gravity so we could just use capsules. The only problems are that modifying the capsules each physics step on the main thread isn’t very performant, and the fact that we would want to use the starting position of the sphere to calculate the collision information (using closest points) rather than what would otherwise be the overlapping portion of the capsule.
So for now (since continuous speculative does not behave well yet) have to use continuous (dynamic) which is not ideal when you have a great many projectiles flying.
I suppose that we could use batch sphere casting commands but that would miss many projectile vs projectile collisions.

[Partel-Lang]

So this is “by design” according to the issue tracker?
“Speculative CCD calculates predicted contacts rather than actual contacts”.

So how can I tell actual contacts from predicted contacts if I wanted to play particle/sound FX on actual collision? I tried checking for collision.impulse.sqrMagnitude > 0, but that does not eliminate all of the false contacts either.

[Qleenie]

I am seeing ghost collisions on all available collision modes, on discrete, dynamic, continuous dynamic, using convex mesh colliders. Seems that in all collision modes speculative collisions are reported as contact points? Is this also by design?

Edit: Sorry, false alarm, had a higher default contact offset, which if I understand produces these ghost collisions.