1
\$\begingroup\$

I have two objects: a player and a wall. The player is passing through the long side of the wall but it collided with the short side of the wall.
I want the player to collide with whole wall.

enter image description here

Here is the code:

enter image description here

\$\endgroup\$
2
  • \$\begingroup\$ We need more details to be able to reproduce and help you solve this problem. How are you moving your player? (Show us the script) What kind of collider components are you using on the player and on the wall? How is the player's rigidbody configured? \$\endgroup\$
    – DMGregory
    May 18 at 11:22
  • 2
    \$\begingroup\$ 1) Code should always be shared as properly-formatted text, not as an image. See the help center if you need support with the formatting. 2) Rigidbodies should be moved with the rigidbody component, not the transform. We've covered this in past Q&A. \$\endgroup\$
    – DMGregory
    May 18 at 14:36
0
\$\begingroup\$

I would try changing the type of collision detection of the rigidBodies. They might be moving to fast and be "tunneling" through objects. unity docs

You can read more about different types of collision detection here

\$\endgroup\$
1
  • \$\begingroup\$ MY object moving at a slow pace still it is not working \$\endgroup\$
    – shriram
    May 18 at 12:12
0
\$\begingroup\$

As I explained here there are 2 ways of moving objects:

  1. To change transform position by little bit every frame;
  2. To use inbuilt physics, and give rigidbody velocity,(or force).

You chose method 1, which is good method (I use it to move units in my RTS game). However you ran into the problem.

Your problem is this:

Choosing to change transform position directly, you are basically telling unity - no matter what happens move this object a little every frame. Computer does exactly that - no matter what walls , colliders are in the way computer tries to move your transform. At the same time you set up collider system thus asking physics engine to take care of collisions. So now two systems are fighting each other - physics system with colliders tries to stop objects overlapping, and your Update() function heroically tries to change transform position no matter what. Result - buggy unpredictable behavior.

The 2 solutions:

First one.

Since you move object directly without physics, also stop it directly without using physics. To do that in your player object check the box isTrigger (might need to do it on the wall object also). What it does, is tells physics system that this player object is not to be affected by collisions, but it will inform you if such collision occurred. Then set the tag of wall object to something like "wall". Then, in your player script use OnTriggerEnter() to find out if you hit the wall.

This would be simplified example of code:

bool amMoving;
public void OnTriggerEnter(Collider other)
{
    if (other.transform.tag == "wall" && amMoving == true)
    {
        amMoving == false;
    }
}

void FixedUpdate()
{
    if (amMoving == true)
    {
        // here write your code to move transform little by little
    }
}

Second solution - do not move player object every frame, instead give rigidbody of player object velocity or force. And physics system will stop it when collision occurs.

\$\endgroup\$
5
  • \$\begingroup\$ Note that since update runs after the physics step (which is where trigger messages fire), the approach you show here will notify you of the collision one frame late (or more, if running at a high FPS). So the player will see the objects interpenetrate for a frame before any correction is applied. Instead, you can use a physics overlap query or shapecast to check your planned move before you move there, then revise the planned move as needed to avoid penetration. \$\endgroup\$
    – DMGregory
    May 18 at 14:47
  • \$\begingroup\$ @DMGregory Yes, good point! However to make things simple - just make collider of wall a bit bigger and it will work fine for most situations.. \$\endgroup\$
    – ShoulO
    May 18 at 14:53
  • \$\begingroup\$ @DMGregory FixedUpdate() however runs before physics. So updated my answer with FixedUpdate() \$\endgroup\$
    – ShoulO
    May 18 at 15:38
  • \$\begingroup\$ At this point you might as well upgrade to a Rigidbody solution so that you can get interpolation. Otherwise you may see judder due to mismatches between the fixed time step and the rendered framerate. \$\endgroup\$
    – DMGregory
    May 18 at 15:39
  • \$\begingroup\$ In slow speeds it does not really matter Update() or FixedUpdate(). At least I never noticed difference in slow speeds. OP can play with both to see if there is any difference \$\endgroup\$
    – ShoulO
    May 18 at 17:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.