1
votes

I tried already several things including: sensors, raycasting, fixture distance, AABB, overlaping fixture vertices, intersectors. Unfortunately i could not get anywhere close to present a almost working code example here. I also was looking trough all possible sources, ten times.

The slicing/splitting methods from several resources do not exactly going along with what i need to achieve, it is done with a entry and an exit point trough an actual fixture. Where in my case there is empty space where the "cut" would need to be.

Pictures:

destruction example 1

destruction example 2

What you see here is a single body which was triangulated and has several fixtures in it. The pictures represents possible states after the player did cut trough it. I am using the breakable class from dermetfan in order to get rid of fixtures on collision.

I would like to detect when pieces of the body (fixtures) are loose/apart from eachoder, not connected inside the body like seen on the pictures. Since the body physics are still intact after removing fixtures it rotates and moves as it was not broke in any way.

If i would have those fixtures i would clone them destroy the original and create a new body in order to let the "broken" part behave as a separate.

Update: Please keep in mind that it is possible that there are X "sides/pieces" since there is no limitation on destruction/paths. The problem is to identify those parts/collection of fixtures which are detached visually. It is not an initial one time only impulse, each fixture triangle is destroyed separately one at the time.

2

2 Answers

0
votes

You seem to be wanting to build a slice mechanic, and for that, I am not sure the breakeable approach is the right one. You might want to look at this article to see if you might want to take a different approach to it. If you are on your path of using a mesh of fixtures though, then this is a general approach that might help.

To solve this problem, I would want to arrive at a data structure that helps me do it. For this, a graph of nodes and edges would seem ideal. The nodes being the fixtures and edges exist between neighbouring fixtures that are still attached.

I would build this graph at the time of creating my body and use the userdata in my fixtures to store it. Building it at 'slice' time with the visual overlaps of your fixtures would be more expensive, and possibly more flaky.

As you make your slice, you could then destroy edges, and at the end use a connected graph finding algorithm to identify your pieces. There are many results in a google search for this, but here is an answer you can start from.

Once you have your pieces, you can create new bodies and fixtures for each piece. If you have the vertices of each fixture in your new piece, you can use this approach to get your new outer edge and build the piece in the same way you built the parent piece.

0
votes

Sounds like you need to implement the post solve method and hook that implementation into the world. There's source code that demos this in the Breakable demo of the Box2D Testbed demo. I don't know if there's a Java port of the demos but C++ code for demoing breakable behavior is available. If that's not already source you've looked at, I suggest doing so.

Anyways, basically, you implement a post solve method and hook it in to the world. It will then get called with contact information and impulse information. You can interpret that information to identify things like the initial fixture that gets contacted with the fixture of the penetrating body (the bullet or ground or whatever it is you want to fracture your main body by) and the amount of impulse involved. You'll probably want to do something similar to the demo code in terms of calculating the max normal impulse amount (as opposed to the tangent impulse amounts) and only start the break if that max is above a threshold amount.

If you want your separation to occur on the first contact that exceeds your impulse threshold, then you can use the contact information in your post solve method to get out the contact manifold and get a normal for the contact. With the normal you could write an algorithm to essentially follow its path through your main body to determine fixtures in a path of destruction. Those fixtures could be removed and the remaining fixtures on both sides of the path cloned into two new separate bodies and the old body removed. Then give the two new bodies each an impulse less than half of what the original fracturing impulse was along with a little outward impulse to give the separation some velocity. So long as your end combined impulsing don't exceed the original breaking impulse amount, things should look realistic enough.

If you want your separation only to occur after there's one or more fixtures no longer connected to other fixtures — which is what it sounds like based on your edit — I can see using another strategy entirely. Instead of creating the initial breakable object as a single body, I'd try having each fixture be already within its own body and connect adjacent fixtures/bodies using something like a distance joint. This would be computationally more intensive but if on every threshold exceeding impact from another body a body in this collection was destroyed, the simulation would eventually get separating fragments as a natural consequence of no longer having constraints connecting those pieces together anymore. You'd have to try it out on your intended hardware of course to see whether this would be performant enough for your needs.

Taking my own advice, I put together a demo of the latter strategy to see how it actually worked. I didn't use triangles in a circular pattern like you had, but just simply used 400 squares in a 20 × 20 configuration. I also wound up using weld joints instead of distance joints as the weld joints made the simulation look more like that of a whole object getting broken apart by bombs. Each square shape belongs to its own body and each body is joined to it's immediate neighbors with weld joints. The simulation never seemed to go below 60 FPS and I liked the results even without applying any additional impulses to newly separated parts.

Here's a screen capture of what the demo looks like after the large aggregate object has gotten bombed apart:

Testbed Breakable Two Demo

Admittedly I did this within the Testbed of my own physics engine. The source code for the demo is available online too if that helps — while it's in C++, all the concepts should apply to Java Box2D as well.

Hope this helps.