6
\$\begingroup\$

Right now I create my boxes where 1 meter is 85 pixels. Gravity is 10. And

                        fixtureDef.restitution = 0.1f;
            fixtureDef.friction = 0.5f;
            fixtureDef.density = 1.0f;

The problem I'm having is illustrated in the image I have provided: http://www.box2d.org/forum/download/file.php?mode=view&id=1044&sid=86e8772dc965cba215f9a16cca2839e4

As you can see, there is a small gap between many, but not all the crates. What could cause this?

Thanks

\$\endgroup\$
  • 1
    \$\begingroup\$ You have a graphical error so you post a question about your physics engine instead of the graphics engine? \$\endgroup\$ – AttackingHobo Jul 21 '11 at 16:44
  • 3
    \$\begingroup\$ You need anti-aliasing \$\endgroup\$ – Notabene Jul 21 '11 at 16:54
  • 1
    \$\begingroup\$ No I do not need it. \$\endgroup\$ – jmasterx Jul 21 '11 at 18:33
  • \$\begingroup\$ @Milo yeah you do. It would most likely fix the problem. \$\endgroup\$ – AttackingHobo Jul 21 '11 at 18:52
  • 2
    \$\begingroup\$ Yes, it's cheating, but so is the entire physics engine. Who cares, it works. "If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck" :p \$\endgroup\$ – Maik Semder Jul 21 '11 at 19:55
8
\$\begingroup\$

I guess that's some issue in box2d, there is such a bug to increase performance. since more accuracy needs much more computational power. to fix that issue I guess you only need reduce box physical sizes (for example you can create a 84px*84px rectangle for a 86px*86px image). you can also fade the pixels in the edges to get better results.

\$\endgroup\$
  • \$\begingroup\$ Many physics engines use a small cheat distance and especially for when objects come to rest. Your oversize rectangle would make a nice fix, I'll wager. \$\endgroup\$ – Patrick Hughes Jul 21 '11 at 20:50
  • 1
    \$\begingroup\$ Box2d does, in fact, use a small 'cheat distance', and that's probably what's causing the boxes to not-quite-touch. The extra space around objects is so that floating point precision errors don't make items penetrate. \$\endgroup\$ – Blecki Jul 23 '11 at 0:39
0
\$\begingroup\$

Just wanted to say that Ali is right, Box2D has a macro on this - I'll paste it here:

/// 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.
#define b2_polygonRadius        (2.0f * b2_linearSlop)

This value is assigned to a new b2PolygonShape's m_radius field in the constructor. Subtracting this value from your body during creation is a trivial solution to resolve the gap glitch:

    b2PolygonShape polygon;
    polygon.SetAsBox(width*0.5-polygon.m_radius, height*0.5-polygon.m_radius, b2Vec2(offsetX, offsetY), angle);
    fixture.shape = &polygon;
\$\endgroup\$
0
\$\begingroup\$

This is also documented in the manual http://box2d.org/manual.pdf :

4.2 Shapes

Polygons inherit a radius from b2Shape. The radius creates a skin around the polygon. The skin is used in stacking scenarios to keep polygons slightly separated. This allows continuous collision to work against the core polygon.

The polygon skin helps prevent tunneling by keeping the polygons separated. This results in small gaps between the shapes. Your visual representation can be larger than the polygon to hide any gaps.

I have found that I can get better looking results simply by scaling up the scene, which makes the gaps look smaller, as it appears that the skin has a fixed width.

Related: https://stackoverflow.com/questions/7705095/webgl-box2d-drawing-issue-gap-between-bodies

\$\endgroup\$

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.