Box2D Forums

I saw a max limit for oval but didn't see for poly (perhaps missed it). With 8 coordinates the shape is fine. If I use 9 or more then beginning with the 9th, coordinates are placed in "strange" locations.

Yes, there is a max number of parts hard coded in on the C++ side in b2Settings.h. If you have more than that you're overwriting random memory.

You'll need to break the polygon up and call shape(poly, [coords]) more than once or shape(polys, [[coord], [coord]]) (polys instead of poly)

Yeah, that's what I ended up doing.

Is there any box2d or WCK function that would creates smaller polygons or a larger one? I sort of remember something for concave shapes but that probably wouldn't work for convex shapes.

You've got b2PolygonShape.Decompose if you want to split up at run time, or the JSFL decomposition script if you want to split it up before hand (assuming the shape is drawn in Flash). They both should limit each poly to the max number of points (8)

I did use the JSFL decomposition script originally and it gave a single poly with 16 points. (Actually 17 but 2 of those were really close). Didn't even time out unlike at other times with different shapes. That's why I was wondering if there was a limit when box2d couldn't handle that many points. I looked at it again after you mentioned the limit but didn't see anything related to that. Strange.

I looked at b2PolygonShape.Decompose and that was the function that I thought would only work for concave polygons. In the docs it says: "Decompose a concave polygon into a bunch of convex ones". That's why I didn't even try it.

In any event, b2PolygonShape.Decompose does work for what I wanted

Just to check if perhaps I'm taking a few extra steps:
-In my class that extends BodyShape, pass the coordinates to b2PolygonShape.Decompose
-Loop through the returned b2PolygonShape array
-Loop through each b2PolygonShape with GetVertexCount() and GetVertex()
-add those points to MyVertices arrray
-add the MyVertices arrray to a MyPolygons array
-shape(polys, MyPolygons)


Sometimes the JSFL script did time out. I'm guessing it might have had something to do with this part in the script:
//If we still haven't found an ear, we're screwed.
//The user did Something Bad, so return null.
//This will probably crash their program, since
//they won't bother to check the return value.
//At this we shall laugh, heartily and with great gusto.

Ok I think you're right, it doesn't look like the JSFL script checks for max points. Most of the decomposition code is adapted from other sources.

If you're using this script & it spits something out with more points than what's allowed I would just manually slice it in half. So lets say it outputs:


[[x1, y1], [x2, y2], [x3, y3], [x4, y4], [x5, y5], [x6, y6], [x7, y7], [x8, y8], [x9, y9]]

You can just split it up manually:

[[x1, y1], [x2, y2], [x3, y3], [x4, y4], [x9, y9]], [[x4, y4], [x5, y5], [x6, y6], [x7, y7], [x8, y8], [x9, y9]]

Or just build your polygon gradually, selecting only parts of it to run the script on, so you can guide the decomposition.

If the script is crashing you're probably just throwing way to complicated shapes at it...

I kept thinking that this situation was similar somehow and then I remembered that I tried to use the same 16 sided polygon (hexadecagon) for a wheel before. At that time, I used oval and I did find limits for that in the WCK code. Interestingly, the JSFL script had no issues with the hexadecagon but when I split the shape in half, the script had more trouble the the "half" hexadecagons. Those shapes didn't seem too complicated, yet ...

The b2PolygonShape.Decompose did decompose the hexadecagon correctly (with the largest shape having 8 vertices) and seemed to work fine while testing. Now I'm wondering, is b2PolygonShape.Decompose supposed to work for convex shapes given that the comments mentioned using it for convex shapes. This would be my preferred method and it seems to work.

It should work for both convex & concave shapes and give you polygons limited to the max vertices.

I see. Then perhaps the docs could be updated to avoid confusion.