ASSERT in b2PolygonShape::Set / vertices order

[fisher]

Hello, I think there is a problem with vertices export/saving order. Or I'm really very tired

I have created some "magic" project with RUBE, which does not works after export to *.cpp or *.json. Just simple box with two fixtures (attached in zip file).

Project opens in RUBE, and works in player. After export to cpp and json, not works on my target project with Box2d 2.3.0.

Box2d reports exception:

Code: Select all

void b2PolygonShape::Set(const b2Vec2* vertices, int32 count)
158:	// Polygon is degenerate.
		b2Assert(false);

Other projects are working, so the problem is only with this one.

After some investigation I have noticed differences in polygon vertices order of scene exported from RUBE:

JSON file
--------------------------------

Code: Select all

"vertices" : 
{
	"x" : 
	[
		0.05443939194083214,
		-0.04991665109992027,
		-0.06269122660160065,
		0.04166480526328087
	],
	"y" : 
	[
		-0.08557727187871933,
		-0.004275797400623560,
		-0.02067285589873791,
		-0.1019743308424950
	]
}

C++ file
--------------------------------

Code: Select all

vs[0].Set(5.443939194083214e-02f, -8.557727187871933e-02f);
vs[1].Set(-4.991665109992027e-02f, -4.275797400623560e-03f);
vs[2].Set(-6.269122660160065e-02f, -2.067285589873791e-02f);
vs[3].Set(4.166480526328087e-02f, -1.019743308424950e-01f);

As you see, order of vertices are the same after export for *.cpp and *.json. However in RUBE are somehow inverted:

RUBE file
--------------------------------

Code: Select all

"vertices" : 
{
  "x" : 
  [
    -0.06269122660160065,
    0.04166480526328087,
    0.05443939194083214,
    -0.04991665109992027
  ],
  "y" : 
  [
    -0.02067285589873791,
    -0.1019743308424950,
    -0.08557727187871933,
    -0.004275797400623560
  ]
}

But even if I reorder vectors in my project, to match order in rube project file:

Code: Select all

vs[0].Set(-6.269122660160065e-02f, -2.067285589873791e-02f);
vs[1].Set(4.166480526328087e-02f, -1.019743308424950e-01f);
vs[2].Set(5.443939194083214e-02f, -8.557727187871933e-02f);
vs[3].Set(-4.991665109992027e-02f, -4.275797400623560e-03f);

(changed index order to: 2,3,0,1).

This still does not work. However, RUBE opens this file and "plays". Maybe RUBE somehow reorder vertices on each project load in some validation phase, and this validation is not executed before scene export or something?

Please help!

[iforce2d]

This sounds like the convex hull check in Box2D is failing. Although it is pretty rare, I have come across a number of 'magic' polygons that cause it to fail, so for the editor I just disabled it. The benefit of the convex hull check is that you can give the vertices in any order you like without caring about the winding, but since it sounds like you know what you're doing, I would suggest you could also disable it too. RUBE will make sure all polygons have the correct ccw winding anyway.

I have attached the version of b2PolygonShape.cpp I'm using in RUBE, along with an svn diff in case that helps.

[fisher]

...RUBE will make sure all polygons have the correct ccw winding anyway. I have attached the version of b2PolygonShape.cpp I'm using in RUBE, along with an svn diff in case that helps.

Great! Now my magic object works Thanks for help and quick answer.

[seannybgoode]

I'm also having this problem, except I'm just figuring out RUBE here, and I don't really know what's going on. What is the option in the editor I can set to turn off ccw? I'm kindof lost as to what to do with this one.

[iforce2d]

As I understand it the problem occurs not in the editor, but when you try to load the .json into your game right? I think the only workaround is to use the replacement for b2Polygon.cpp above.

[dmagunov]

Hello,

Maybe this helps You:

Comment following C++ code in the file Box2D/Collision/Shapes/b2PolygonShape.cpp

if (b2DistanceSquared(v, ps[j]) < 0.5f * b2_linearSlop)
{
unique = false;
break;
}

[seannybgoode]

I ended up fixing it by replacing the offending shape. You're right that it just doesn't like some shapes. My approach has been to keep the shapes simple with a limited number of vertices.