Disabling physics pushing and demo scene

Disabling the 'Skeleton Animation' stops the problem. Presumably it's modifying the transform of the collider which causes all existing contacts to be removed as the collider will be recreated. I'm not even sure how the collider is being created; persumably by all these scripts.

I'm not an expert on these scripts but if it's doing this during fixed-update or update then you'll not see any contacts you can use. Having physics perform the col-de using a Dynamc body won't suffer from this because it's all done during the update, not after when your 'Skeleton Animation' script runs and causes the collider to be recreated.

Anyway, this isn't really a simple set-up as it's using a pretty complex set of scripts to which I have no idea how it works.

 

Unity physics is not at fault here, it's the fault of the script constantly updating the Transform between the Collider2D and the Rigidbody2D it's attached to *every frame* during LateUpdate. If you do this, the collider is recreated which causes its contacts to be deleted and regenerated next fixed update. Colliders live in the local space of the Rigidbody2D so if you move the colliders and not the Rigidbody2D itself then they need to be recreated.

Your movement scripts are based upon counting contacts, which there'll be NONE as you check them in fixed-update (and start the thing moving downwards) which is before the physics system runs. It then runs, following which the callbacks happen and you set the velocity to zero. Then the 'animation' scripts run in LateUpdate (potentially several times recreating the colliders) then eventually a fixed-update happens and you check for contacts (and start the thing moving downwards again) but there are none because your scripts causes the colliders to be recreated wiping any contacts then, again, the physics updates and regenerates the contacts and it goes on and on.

If they are animating Transforms on GameObjects which have Colliders that are attached to a Rigidbody2D not on the same GameObject then you should add another Kinematic Rigidbody2D for that 'node'. This is what kinematics is about.

Effectively what you have here is a kinematic rag-doll. When you do this, you should have a Kinematic Rigidbody2D at every animated position so that the Transform change updates the Rigidbody2D and not the Colliders attached to it. You typically nest Kinematic bodies like this. Moving a parent Kinematic body moves all the children with it.

I did this on your project by adding a Kinematic Rigidbody2D onto the 'GameObject' under the 'Spine' game object. When I did this I saw contacts when overlapping stuff (I checked in the Info Rollout / Contacts).

You cannot have a single Kinematic root body with colliders attached on chidlren GameObjects and animate their Transforms.

There's nothing stopping your script from grabbing all Rigidbody2D children and simply checking them for contacts.

 

Add a Kinematic Rigidbody2D to the 'GameObject' GO under the Spline Object then replace the 'body1.cs' script with the following I hacked together for you:

Code (CSharp):

1. using System.Collections;
2. using System.Collections.Generic;
3. using UnityEngine;
4.  
5. public class Body1 : MonoBehaviour {
6.  
7.     private Rigidbody2D[] mybodies;
8.     private Rigidbody2D rootBody;
9.  
10.     public virtual void OnCollisionEnter2D(Collision2D coll)
11.     {
12.         rootBody.velocity = Vector2.zero;
13.     }
14.     public virtual void OnCollisionStay2D(Collision2D coll)
15.     {
16.         rootBody.velocity = Vector2.zero;
17.     }
18.     private Vector3 _lastVelocity;
19.     private ContactPoint2D[] contacts = new ContactPoint2D[20];
20.  
21.     private void Start()
22.     {
23.         mybodies = GetComponentsInChildren<Rigidbody2D>();
24.         rootBody = transform.root.GetComponent<Rigidbody2D> ();
25.     }
26.  
27.     void FixedUpdate()
28.     {
29.           // Apply the final velocity
30.         _lastVelocity = GetCurrentVelocity();
31.  
32.         rootBody.velocity = _lastVelocity;
33.  
34.         foreach (var b in mybodies)
35.         {
36.             int contactCount = b.GetContacts(contacts);
37.             if ( contactCount > 0 )
38.             {
39.                 Debug.LogFormat("Contact count: {0}", contactCount);
40.                 rootBody.velocity = Vector2.zero;
41.                 break;
42.             }
43.         }
44.     }
45.  
46.     public Vector3 GetCurrentVelocity()
47.     {
48.         var velocity = Vector3.down;
49.         return velocity + Vector3.right * Input.GetAxis("Horizontal") * 5f;
50.     }
51. }
52.  

This works perfectly. It collides with the other box and the ground. By adding the Kinematic body you also stop the collider from being recreated so contacts are available to be checked.

I would also recommend setting both Kinematic bodies to use Continuous collision detection to stop overlaps.

Note that the above script is something I quickly modified; it makes various assumptions such as assuming the root has a Rigidbody2D. You can customise this part yourself.

Hope this helps.

 

To be clear, this has nothing to do with triggers or non-triggers nor do you have to add a Rigidbody2D to every collider as some fixed rule. I've tried to explain it a few times above and granted it might be better with a picture (that I don't have)!

I'll try to be clearer; Collider2D live in the space of the Rigidbody2D. For example, all the vertices of a BoxCollider2D are stored as a relative position from the Rigidbody2D. When you XY-position or Z-rotate the Rigidbody2D, the colliders attached to it do not require any attention so it's fast as it's only the Rigidbody2D that moves. However, if you adjust the collider offset or if the Collider2D lives on a child GameObject relative to the Rigidbody2D and you modify the Unity Transform inbetween the Rigidbody2D and Collider2D (the one on the Rigidbody2D is obviously fine to modify) then you've changed the relative position of the Collider2D with respect to the Rigidbody2D. Box2D is fairly immutable for stuff like this and such a change requires that the collider be destroyed and recreated so this is what we have to do.

When you animate the Transform XY-position or Z-rotation on a GameObject that has a Rigidbody2D and a Collider2D, we know to ignore all the Collider2D on that GameObject and only adjust the Rigidbody2D because of the above. Likewise, if we had a GameObject that has a Rigidbody2D but the Collider2D is on a child GameObject and we animated the Transform XY-position or Z-rotation of the Transform on the parent Rigidbody2D we would still ignore the Collider2D on the child GameObject because they have not changed position/rotation relative to the attached Rigidbody2D. In this parent/child split, if we were to instead animate the Transform on the child GameObject (that contained the Collider2D only) then we're changing the relative position of the Collider2D with respect to its parent so it needs to be recreated in its new position.

Recreating a collider involves destroying it then creating it. When you destroy a collider, Box2D immediately removes all its contacts. Those contacts will be recreated in its new position during the next physics update. We then have to match up the old deleted contacts with the new incoming ones so we don't end-up reporting new OnCollisionEnter2D or OnTriggerEnter2D which is a real PITA to do and has been the source of bugs in the past.

When you have a rag-doll set-up where you typically have colliders in a hierarchy of GameObject, some of which you animate XY-position or Z-rotation then you need to have a Kinematic Rigidbody2D at those GameObject which you animate. You do not need to have a Rigidbody2D at every GameObject, just ones where you animate.

Also, Kinematic Rigidbody2D automatically move relative to any parent Kinematic Rigidbody2D so modifying a root Rigidbody2D causes all children Rigidbody2D to move relative to it as you would expect in a normal Transform hierarchy; in this case it's also a Kinematic Rigidbody2D hierarchy as well but the difference being that there isn't a need to have a Rigidbody2D at every Transform position in that hierarchy, just the animate 'joint' positions.

Finally, I'd like to add that amongst the plans this year is to investigate making major modifications to Box2D rather than living with its shortcomings. One of which is to remove/reduce the need to recreate a Collider2D if you transform it relative to its Rigidbody2D. The other is to either defer recreation of Collider2D and therefore the contacts and/or allow the contacts to be updated immediately, either by a global option or per-Collider2D/Rigidbody2D.

That's it!

Hope this explanation helps.

 

I wanted to add to this part as well; I see all the time, especially in docs where the docs guys/gals have 'simplified' the description for the sake of being concise at the loss of accuracy and I believe that in some cases, such as this, it adds long-term confusion or at least lack of real understanding which is, of course, not the users fault at all.

All 2D components when added to the scene affect the physics system, full stop. A Static body may not be moved by the physics system but it affects it as it's considered when things overlap or touch it. A Kinematic body is the same except for the fact that like a Static body, forces do not move it. Forces include global gravity, user-applied forces or contact forces. They will move if you directly set their velocity but they'll keep moving unless you explicitly change the velocity. Dynamic bodies are obviously affected by forces.

The only exception to this is when a Rigidbody2D has its Simulated property set to false. The body, its colliders, its joints (etc) are ignored by the physics system in this and only this case.

Don't want you to feel like I'm jumping on you here, not at all, just my way of trying to clarify and I had some time on my hands to do so. Hope it all helps you.

 

I couldn't agree more with this.

Not trying to blame the docs guys/gals at all. It's very difficult to write good documentation that provides enough information for everyone in one place though. Also where to put it can be a challenge. Most of this kind of info should go into the manual and that's something I've got on my plate in 2017. Going to put a lot of work into the 2D physics manual. Heck, I almost wrote a book as a GDoc which I need to revamp into a 2D physics manual.

 

I'm dedicated to getting a bunch of manual & docs work done early in 2017 hence it being in my top 5 things TODO and it's a big ol' list.

 

This is not true. I am 'the programmers', I'm the dev for 2D physics here at Unity. Simulated has nothing whatsoever to do with a body being kinematic.

The body-type defines the behaviour of the body and its colliders. Simulated simple turns on/off the physics system from simulated the body as the documentation states.

 

Yes, that's a pretty good use for it.

 

If by 'without a Rigidbody2D is static' you mean the Collider2D isn't attached to a Rigidbody2D then yes. If you mean a Rigidbody2D on the same GameObject then no, the statement isn't correct. As should be well known, a Collider2D attaches to a Rigidbody2D on the same GameObject or uses the nearest Rigidbody2D going up the Transform hierarchy.

Try not to move static colliders. Stuff is only crazy expensive when you do it a lot!

Rigidbody2D = b2Body; Collider2D = multiple b2Fixture + b2Shape (ignoring circle. box & edge colliders); Joint2D = b2Joint.
When you add a Rigidbody(2D), you are asking that component to drive the Transform. Whether that's what you think or not, that's what you're asking Unity to do. If you set a body position/rotation directly then you immediately warp to that position; there's no interpolation available. If you set the body position/rotation then it'll update the Transform during the next physics update. If you set the Transform it'll update the transform and the body position/rotation immediately. Both will reset any interpolation being used. When you change a Transform is irrelevant to what it does.

Changing any scale is bad because as I've said a lot above, Box2D does not provide any scaling of colliders (b2Shapes) therefore they need to be recreated. Box2D treats most collider stuff as immutable.

Again, colliders attach to a rigidbody on the same GO or on a parent one. Changing a child collider transform causes only that collider to be recreated. Box2D allows fixture/shape to be removed and a new one added which is what we do. You do not have to remove all of them (other colliders attached to it).

Yes, two separate b2Body. The child b2Body doesn't automatically move with the parent at all. It only happens when using a child body that is set to be Kinematic. This is a Unity thing, not a Box2D thing and happens specifically for hierarchical kinematic set-ups as this original post project was doing. Note that Box2D has no idea about Unity Transform or the hierarchy.

Collisions/Triggers are only reported to the GO that contains the colliders/rigidbody that are involved.

Just the colliders. It's work that you should avoid. Recreating some colliders are worse than others. A CircleCollider2D and BoxCollider2D always involve a single b2Fixture/b2Shape so they are relative fast. EdgeCollider2D scales with the number of edges although it's still pretty cheap. PolygonCollider2D costs can get high quickly as they allow not only a concave outline but also multiple paths defining interior holes. These paths are decomposed into multiple convex b2PolygonShape. This costs and the cost has nothing to do with C#.

As I said above, when you destroy a fixture, all its contacts are removed.

A kinematic body can have its linear and angular velocity set, yes. I don't believe this is supported in 3D physics though. Kinematic bodies that are children of other Kinematic bodies move with their parents as said above.

I was trying to be brief above as it takes a lot of time to review and post, something I don't have a lot of right now, sorry!

 

Please don't hijack threads like this, it makes confusing topics even more confusing to follow.

If you'd like to create a separate thread or start a conversation with me then I'd be happy to help, thanks.