Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Any good solution to remove gaps between rigid bodies?

Discussion in '2D' started by TruffelsAndOranges, Dec 16, 2014.

  1. TruffelsAndOranges

    TruffelsAndOranges

    Joined:
    Nov 9, 2014
    Posts:
    92
    In Unity there will always be gaps between 2D rigid bodies. This is a problem that is inherited from Box2D and a way of optimizing the physics engine.

    In many applications this can graphically be prevented by using oversized sprites, or making the colliders smaller than the sprites that they are connected to. The problem is common.

    When you use the 2D colliders to automatically create meshes that you then draw upon, you will instantly realize that this is not a problem that can be fixed by oversized sprites, and another solution is required.

    The solution I came up with was to scale up everything in the scene by 10. This removed all kinds of gaps, destroyed any optimization and required me to make a lot of re-scripting. As expected, this solution created new problems. One of them was that the movement of the editor perspective scene camera does not scale with the world scale. This made working with level design a big hassle.

    I am wondering, is there any _good_ solution to this? Or does every solution create a multitude of new problems? I am creating a 2D physics based game for PC, so the Box2D/Physics2D optimizations that add the gaps are not required.

    Here is an image of the gap problem:
     
  2. theANMATOR2b

    theANMATOR2b

    Joined:
    Jul 12, 2014
    Posts:
    7,790
    I don't think this is a solution but may be worth a try,
    Have you attempted to use 3D physics in your 2D world?
     
    TruffelsAndOranges likes this.
  3. TruffelsAndOranges

    TruffelsAndOranges

    Joined:
    Nov 9, 2014
    Posts:
    92
    Good idea!

    Nope! That would destroy all optimizations of the 2D engine, wouldn't it? I also do not want to remake a huge project by making everything 3D instead of 2D, just because Box2D/Physics2D have too little customization available.
     
  4. theANMATOR2b

    theANMATOR2b

    Joined:
    Jul 12, 2014
    Posts:
    7,790
    Friduric, maybe set up a test scene with an average amount of 2D objects in the scene, setup some basic movement controls - maybe similar to your cart & boulder scene above. (please forgive if that's not what is displayed in the image)

    Apply 2D physics to the objects - test and record the results, then replace the 2D physics with 3D physics and compare the results.
    It's likely there will be a hit to the optimizations but... if you can live with it and optimize in other areas maybe it can be managed to get better accuracy.

    Actually I found this link which confirms your optimization concern.
    http://x-team.com/2013/11/unity3d-v4-3-2d-vs-3d-physics/
    Note - looking at the examples it's obvious the 3D physics are considerably more accurate.

    Unity's blurb on physics. Thought it was interesting.
    Unity’s easy-to-use integrated 2D physics system uses the same system of rigidbodies, joints and colliders as our feature-rich 3D solution. Actually, however, it’s driven by Box 2D, for an industry-hardened stable and versatile 2D solution. It’s easy to mix 2D and 3D physics in Unity. By doing so you can work in completely new ways and create innovative game formats with ease.

    I found this helpful best practice workflow on this site: http://x-team.com/2014/05/unity-3d-best-practices-physics/
    One interesting thing that they mention to increase accuracy -
    Tweak the Fixed Timestep value on the Time Manager, this directly impacts the FixedUpdate() and Physics update rate. By changing this value you can try to reach a good compromise between accuracy and CPU time spent on Physics.

    One more additional link I thought might be helpful. (I'm not associated with the developer of rage-spline in any way)
    http://u3d.as/content/freakow-/rage-spline/1DK


    Hope you find a solution. I'm not a physics game developer but thought I'd follow up in an attempt to help.
     
    TruffelsAndOranges likes this.
  5. TruffelsAndOranges

    TruffelsAndOranges

    Joined:
    Nov 9, 2014
    Posts:
    92
    Hey theANMATOR2b!

    Thank you for reply. The game I am creating has been directly ported from my own game engine using Box2D. In that engine I used a constant to tweak every Box2D-physics coordinates and sizes through how I wrapped Box2D. This way I could just scale everything in Box2D up without having to scale anything in my game (i.e. forces etc). In Unity this does not work because they have wrapped around Box2D in another way.

    I cannot use the 3D physics engine because I use rather advanced 2D algorithms that are specifically designed for Box2D. I am sure I could create similar results in Unitys 3D engine, but it would take so much time translating all algorithms from 2D to 3D space.

    Changing the "Fixed Timestep" would not work, because it will only tweak the number of iterations the physics engine work to stabilize things. If the physics engine determine a object is stabilized when it actually has a gap, no matter how many iterations I run it will remove the gap.

    The gap problem is an implication of some non-public constant that Box2D use, which is kinda stupid really. It would've been much better if it was exposed to the programmer! It would require more CPU, but at the moment CPU limit is not a problem!

    Thanks again for your answer. I think Unity will have to fix this if we are going to have a correct implementation of Box2D without gaps! :)
     
  6. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,321
    Box2D has a compile-time constant named 'b2_polygonRadius'. It has a description as follows:

    /// The radius of the polygon/edge shape skin. This should not be modified. Making
    /// this smaller means polygons will have an insufficient buffer for continuous collision.
    /// Making it larger may create artifacts for vertex collision.

    This defaults to 0.01 and is responsible for the radius (gap) you see. I have found that with careful usage, it can be changed however it can cause problems as described. To this end, I changed Unity so that this can be modified in the 2D physics settings under the property 'Min Penetration For Penalty' (horrible name but matches 3D). You can find this in the 4.5.5p5 release.

    If this is changed to (say) 0.002 you will find that the gaps probably disappear however, as indicated, many problems can occur if it is changed too much. Try to keep it as close to the default as possible. You have been warned!
     
    Deleted User and theANMATOR2b like this.
  7. Ruskul

    Ruskul

    Joined:
    Aug 7, 2014
    Posts:
    72
    ----

    I used to work with box2d outside of unity. A solution used at the time was to make all collider generation account for that "gap".

    In unity, you can do this by reducing colider size on a box collider (to 0.99), but then this doesn't work if the object gets scaled. There seems like there needs to be a built in property for defining a size change for the colider that isn't affected by scale. Basically (-0.01). I don't think it is good to mess with the penetration penalty because box2d needs a good buffer... the real issue is simply sizes colliders slightly smaller than graphcs.