Related Discussions
...

Hi All,

As mentioned in the forum before, box2d's polygon shape's vertex limit is 8.
I'd like to create accurate box2d shapes for my animations, so before I go off and code up a polygon decomposition algorithm, I was wondering if this already being done somewhere in the spine runtime? Perhaps there's a triangle list I can access?

Thanks

2 months later

IIRC, you can bump the limit with b2_maxPolygonVertices.

Edit: You can grab the vertices when you update the attachment vertices. The region attachment of course is just 4 verts, and the first N vertices of the mesh types are the hull, where N is sp(Skinned)MeshAttachment::hullLength.

Thanks for the response jpoag.
I read on the box2d forum that significantly increasing the size of b2_maxPolygonVertices could be problematic, so I decided to stay clear of that until it became necessary. Instead, I'm using the bounding box feature to outline bounds at a lower resolution than attachment meshes. In cases, where we have to go over 8 vertices, we're using polygon triangulation. It's working well, but there's room for optimization since many triangles occasionally cause box2d to chug.

Thanks for your pointers. I found your other post with the links very helpful on the subject!

No prob James,
I thought I saw another response from you, but I can't find it now to respond to it.

Anyway, I ended up going with the first solution I mention in this post: viewtopic.php?f=7&t=3001&p=14588#p14588
We are using mesh deformation as well, but for those attachments, we either ignore them or use a bounding mesh to approximate the position of the mesh regardless of how distorted it gets.

It's working, but it could use a lot of refinement. Enemies and characters can interact with the environment well, but sometimes their animations cause them to be really unstable as their revolute joints try to keep up. I'm happy with this for now, but I wonder if there's a better solution out there...

Sheado wrote

I thought I saw another response from you, but I can't find it now to respond to it.

I had asked a lot of questions that I figured out the answers to when I read all the links in your other post.

Sheado wrote

We are using mesh deformation as well, but for those attachments, we either ignore them or use a bounding mesh to approximate the position of the mesh regardless of how distorted it gets.

I considered scanning through the animation and grabbing max/min verts on the mesh and then wrapping them with a poly.

jpoag wrote

Enemies and characters can interact with the environment well, but sometimes their animations cause them to be really unstable as their revolute joints try to keep up.

Given your approach, I'm assuming that the designated central Bone is only affected by physics simulation and that the child bone physics bodies are able to relay the impulses through the joints (albeit dampened). Also, the revolute joints have upper and lower angle limits, does that affect the stability?

Ah, i see. Glad my rambling was useful to somebody =]

For the meshes, we ignore them because it's supposedly very expensive to update or create fixtures on every frame. Scanning though and wrapping with poly would probably work fine, but it sounds expensive.

As for the box2d to spine synchronization, the central bone is used for steering the character around. All bones with physics bodies are subject to physics simulation, but we use revolute joints with no angle limits and extremely high torque so that the animation and physics simulation can for the most part stay synchronized (since we don't relay back the physics coordinates to the spine coordinates for the non-central attachments). This results in a character than can be steered around by its torso for example, yet capable of hitting its head on an obstacle which in turn affects the torso's (and the rest of the body's) movement.
Not sure if I'm describing that well.. hopefully that made any sense =]

It does. Thanks again. =)