Unity Tip: Giving Camera-Driven Objects Physical Collision

[MartyG]

Hi everyone,

You may have found in your Unity projects that objects whose movement is driven by camera scripts such as 'TrackingAction' pass through other objects unless at least one of the objects has a Constraint position or rotation set as unlocked.

The big dilemma is that if all constraints are enabled then the objects pass through each other.  But if you have one of the constraints left unlocked then the object that is being collided against shifts its position or rotation and breaks the appearance of whatever that object was attached to (e.g an avatar arm.)  This is an issue I have tried for months to resolve.

Today though I finally worked out a workaround that is a bit crude but seems to work.  

STEP ONE

Go to the box collider settings of the object that you want the camera-driven object to collide with (e.g an avatar torso) and slightly increase the size of its collider by a small decimal amount (e.g from '0.4' to '0.6') so that it extends by a small amount from the surface of the object like a force-field.

In my project, the objects that are to be collided with have a Rigidbody component with a high Mass value of '10000' so they can't be pushed around easily but a low Drag value of '1'. Gravity is enabled (because it's my experience that Unity objects react to physics better if they have some kind of motion force influencing them) and 'Kinematic' is disabled (because it can sometimes enable other objects to pass through if it is switched on.) 

Even if Gravity is enabled, the object should not fall downwards so long as you have the Position constraints enabled so that it cannot vertically fall.

http://test.sambiglyon.org/sites/default/files/collider.jpg

STEP TWO

Create a small object such as a sphere and place it inside whatever object (e.g an avatar upper / lower arm) you want to be stopped when it bumps into something.  Scale the small object so that it protrudes a little way outside of the object you have placed it within.

STEP THREE 

Child-link the small immersed object to your camera-powered object that provides the movement (e.g an avatar arm's rotation joint.)  Crucially, also child the piece that the small object is immersed in to the rotation joint - do NOT make the small object a child of the object it is buried inside.

http://test.sambiglyon.org/sites/default/files/bearings.jpg

By using this linking system, the small object will be able to rotate independently of the object it lives within.  So if you have it inserted in the upper arm flesh of an avatar, the arm will still be moved normally and the small object inside it will move with the arm, but NOT change the movement of the arm.  Think of it like a ball bearing spinning freely inside a bicycle gear.

SUMMARY

In the image below, the avatar arm without the collision spheres can pass through the body, but the arm with the spheres cannot pass through no matter how hard it tries or from whatever angle.

http://test.sambiglyon.org/sites/default/files/nopass.jpg

Once you are satisfied that your collision objects are working correctly, you can make them invisible by creating a blank transparent PNG image and importing it into Unity and then applying it to the surface of the objects and giving the applied texture a 'Transparent' lighting filter to hide them from view completely.

[Vidyasagar_MSC]

Thanks for this awesome post and information Marty

[MartyG]

Thanks Vidysager!  :)

I would add that in circumstances where you want fine-control over physicality, such as having the hand of one avatar arm stroke the virtual flesh of the other arm, then you can copy and paste a row of these spheres right along the arm so that its whole length is covered by the ball bearings.  I tried this with the palms of the avatar hands and it stopped the sphere-less hand from passing though the sphere-enabled one.

http://test.sambiglyon.org/sites/default/files/contact.jpg

Another little tip I just discovered is not to make the collider field of the object that you are colliding with so large that it overlaps the spheres' colliders'  A prime example in my avatar was when it was in its default position of standing with the arms hanging down at the sides.  

I made the torso's collider "force fields" large enough that they were inside the arm spheres' colliders when the game was run.  This made the arm less likely to deflect off the torso.  Once I reduced the size of the torso colliders so that there was a little empty space between them and the spheres when the game was run, the deflection worked much more solidly.

This seems to be a general condition of collider interactions - they have to be separated at first and then touch each other for Unity to know that it is supposed to repel the object doing the touching.. Beginning the program with the fields merged makes it more likely that the collision effect will be disrupted.

Edit 2: another tip I found is to have all of the Rotation constraints unlocked on the spheres instead of just one.  This makes the deflection even more reliable.  This is because an object will try to pass through any constraint direction that is locked, so if you have the 'X' horizontal rotation constraint unlocked then objects approaching from the X direction will bounce off, but they may be able to pass through in the Y and Z directions if the object that is trying to penetrate approaches the sphere-enabled object from those directions.

[MartyG]

I continued to refine my collision system and recorded some YouTube footage showing my avatar moving with and without the collision padding I put on zones on the upper / lower arms and torso.

https://www.youtube.com/watch?v=BvoZx2B1hpA&feature=youtu.be

Here is the latest data from my camera-object collision experiments.

*  The collision physics of the sphere system seem to work more like the "deflector shields" on a Star Trek starship than the collision you may be used to in Unity.  In Star Trek, an object colliding with a starship's shields does not stop dead but instead is pushed off in another direction away from the shield.  Objects equipped with the spheres display the same behavior, sliding over the surface of the sphere instead of stopping.

*  Giving the collision spheres Box type colliders seems to work better than the default sphere collider for providing stable collision.  This is because objects tend to slip off the curves of a sphere collider, whereas they are more likely to just stop when hitting the flat sides of a box collider.

http://test.sambiglyon.org/sites/default/files/blocker.jpg

* When the sphere-equipped object (e.g a point on an avatar arm) deflects, the object will try to move through the object being collided with at any point where there is a gap in the sphere coverage.  So for example, if you have a collision sphere on the upper arm and one on the lower arm, the arm will be able to pass through an object if the un-covered area inbetween the two spheres collides with it.  

This is why there is a moment on the above video where the hands pass through each other - because they currently have no collision padding and because the arm is being moved by the camera script, they are intangible to each other (there would be a solid collision between the two if they were being moved with a keyboard or joypad control.).

[MartyG]

Update: we now have a first iteration of palm-to-palm physicality installed and working, via a ball-bearing at the back of each hand that is similar to the raised area on human hands at the start of the wrist that collide together when the real-life hands are brought together palm-to-palm in a "prayer poise".

https://www.youtube.com/watch?v=tPSOhN7xsok&feature=youtu.be

If you look carefully, you can see the ball-bearings rotating in the hand as they absorb the impact and convert it into physicality.  

Please ignore the little floating bubbles in the second half of the video - we clapped our squirrel-guy's paw-pads off.  We need to tie them down tighter.  :)