(Replying to PARENT post)

The code must somehow compute bouyancy in a way that reflects the object's arbitrarily complex shape. It's likely carving the object up into some number of smaller primitive objects whose equations for bouyancy are known. In order to make the whole object move as one rigid body, though, it's probably computing force vectors for each primitive, and then summing them together based on the overall object's center of mass and moment of inertia.

My guess is that the object's mass and inertia is calculated in a way that is sensitive to the handedness of the drawing. The code probably takes the absolute value of the result so that right-handed and left-handed drawings both end up with positive mass. When you draw lobes though, the signedness alternates and cancels out, leading to less mass. With even numbers of lobes of near equal size, you end up with near zero mass.

The forces being computed on each primitive are probably representative of that primitive's true mass. Subsequently applying those same forces to a rigid body with significantly less mass therefore results in extreme acceleration. f=ma, f/m=a. f/0=explode.

๐Ÿ‘คsgtnoodle๐Ÿ•‘4y๐Ÿ”ผ0๐Ÿ—จ๏ธ0

(Replying to PARENT post)

If you look at the source, you'll see that it doesn't really try to split the path into smaller primitives at all. It uses a simple algorithm (https://stackoverflow.com/a/33852627) to calculate the center of mass, and another algorithm to calculate the area (https://stackoverflow.com/a/33670691).

Both of these algorithms basically sum up the "signed area" of the polygons. This means that if you circle something twice, it'll count twice, and the sign depends on the direction of the winding.

The confusing part is that when the polygon is drawn, it uses the "non-zero winding rule" to determine which part to fill. So the filled parts of the polygons are all parts that contribute non-zero parts to the area (eg. positive, negative, two time positive etc.).

So the weird behaviour is that the physics simulation doesn't use the same rules as the visualisation!

So the nice thing about these algorithms is that it works for arbitrary complex shapes as long as the path has no self-intersections.

If you want to add support for self-intersecting paths, you need to decide how to deal with intersections. Presumably you'd want the physics to match the visualisation, ie. use the non-zero winding rule also for centroid and area calculations. To do that, you would first need to split the polygon into non-intersecting parts, and then calculate the area separately for each part, and then sum up the absolute values of the individual parts.

๐Ÿ‘คyarcob๐Ÿ•‘4y๐Ÿ”ผ0๐Ÿ—จ๏ธ0

(Replying to PARENT post)

If anyone wants to do this, you're looking for "approximate convex decomposition": http://codesuppository.blogspot.com/2006/04/approximate-conv...

It was one of the grand challenges in the 00's, quietly solved by John Ratcliff. Then a few people solved it after him.

It's a fun algorithm. You basically slice and dice, like chopping a potato, then recombine small parts together based on a heuristic.

๐Ÿ‘คsillysaurusx๐Ÿ•‘4y๐Ÿ”ผ0๐Ÿ—จ๏ธ0

(Replying to PARENT post)

I knew this was happening, but reading it, hey, maybe that's one way to get anti-gravity. Just loop the topology on itself. Obviously commenting in jest, but now I'm intrigued to see if someone has seriously considered this.
๐Ÿ‘คarithma๐Ÿ•‘4y๐Ÿ”ผ0๐Ÿ—จ๏ธ0