Search Unity

  1. All Pro and Enterprise subscribers: find helpful & inspiring creative, tech, and business know-how in the new Unity Success Hub. Sign in to stay up to date.
    Dismiss Notice
  2. Dismiss Notice

Collision issue with between spherecollider and boxcollider edges

Discussion in 'Physics' started by Riyujin, Jun 19, 2019.

  1. Riyujin


    Apr 16, 2019

    I'm working on a breakout-type game with balls and cubes (it's in 3D).
    So it involves:

    - SphereCollider
    - BoxCollider (bricks are all perfect cubes)
    - A custom collision physics script (I'll explain just after)

    I found that using PhysicsMaterials results it very poor bounces (the angle would change without any reason).
    So I decided to make my own script which is very simple:

    When the ball collides with something, it gets the normal of the collision. Using that normal vector, it simply inverts the component of the ball-direction-vector parallel to the normal vector.
    (ball-direction-vector, by that I mean the vector that dictates the direction of the ball at any given time, sorry for bad english).

    Also, the ball never looses/gain speed on any collisions, just through powerups.

    My problem now is:

    When the sphere hits the perfect edge of a cube, the ball's direction gets a very unlikely new direction.
    See picture here :

    Green X = point of collision
    On the left side, the ball hits on the face, so there is no problem.
    However, on the edge, I would expect the ball to move in the purple area. Instead, it goes as shown by the red arrow.

    VIDEO showing the problem :

    Timescale is set to 0.2f so it's easier to see.
    The view is from the top. Also, while recording this I noticed that it goes also weird on the second edge, since this cube I hit needs multiple hits before being destroyed.So it's even weirder than on 1-hit-destroyed cubes.

    Now, I don't really know what to do, for edges-bounces, it's perfect since normals are going outward from the surface. But on corners, maybe they are pointing outward from the center of the cube, in that case that makes sense.

    Any idea or things to test out ? Am I missing something ?

    Thanks for reading, I hope it's clear enough, I can add the script part or more infos if you need,

  2. Zetric


    Apr 2, 2013
    Hi, just happened to come across your post looking for something else. But I recently experienced this problem myself.
    To save you some google and forum searches I can tell you that it behaves that way because when a spherecast or collider connects with the edge of another collider it "interpolates" the value by giving you the normal value = to the point of collision contact towards the spheres center.
    Regular raycasts dont do this.

    Therefore as a quick fix you can cast a second regular raycast onto the point of contact to retrieve the correct "flat" normal of your cube.

    However... (Thers always a but)
    It might return either the right-facing normal or the down-facing normal (based on your example) since we are literally casting onto the very infinite edge of the collider.
    To get the correct one of the two you'll have to do some more checks to see which one of them is the most likely to be the one you want.

    Maybe this will guide you in the right direction!
    josiest likes this.
  3. Riyujin


    Apr 16, 2019
    Hi, well sounds like a solution.
    However I want to keep the real-like corner bounce, and not actually keep it to perfect edges-bounces (i.e. horizontal or vertical reflection). I've given up on this issue since it happens very rarely, but thing is I get some weird sh*t happening when instead of OnCollisionEnter it's a OnCollisionStay that happens, case that I've treated only for the boundaries of the map.

    Perhaps I'll find the solution, I'll post it if it's the case.
    Anyway thanks for your time & ideas :)
  4. josiest


    Jun 3, 2019
    I was having a similar problem with using my own physics. After a bit of debugging I was able to realize that the hit normals on edges weren't what I expected them to be. I didn't realize this was unique to non-ray casts so this helps a lot!