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.
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.
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.
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.
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!
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!
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.
