Offset arguments for multiple shapes with different masses

[shylent]

Hello,

I have a little question regarding composite objects (objects, represented as multiple shapes, assigned to a single body). You can't get anywhere without them, unless, of course, you don't get to deal with non-convex shapes :P

I can't quite understand what two "offset" arguments stand for:

• offset in cpPolyShapeInit - that is an offset from the body's center of gravity (how can it be known before attaching all shapes?) to what? To the shape's centroid? I simply can't get my head around this :( My guess is that this offset basically "translates" shape-local coordinates into the body-local coordinates. Is that correct?
• offset in cpMomentForPoly - what does this mean? Since cpMomentForPoly assumes, that the center of mass of the polygon (its centroid, essentialy, because the density is constant) is at (0,0), is this offset used for situations, when the center of mass is not actually at (0,0)? So if the center of mass of your polygon is at, say, (20,0), you use (-20,0) as the offset?

Let me give you a really simple example (forgive me my ascii art):

Code: Select all

|########|$$$$$$$$|
-8       0        8

The coordinates are body-local.
The body is composed of two shapes with different masses. Body's center of gravity obviously won't be at 0 in this example.
What would be the correct values of "offset" for both the cpPolyShapeInit and cpMomentForPoly?

EDIT:
Ok, so I've spent a bit more time pondering this and I seem to understand the problem a bit better now:

• When calculating the moment of inertia for the single shape (cpMomentForPoly), that is described in shape-local coordinates, offset is used if the centroid (and, consequently, the center of mass) of the shape doesn't correspond to (0,0) in shape-local coordinates.
• When adding the shapes to the body, it is desired, that the body will rotate around its actual center of mass, meaning, that the (0, 0) point (the point, that corresponds exactly to the body->position in world coordinates) cannot be chosen arbitrarily. A center of mass has to be calculated using the masses and initial offsets of all shapes, that make up the body and that value has to be used to "shift" the center of mass (or, rather the shapes themselves, since the center of mass has to end up at (0, 0) in body-local coordinates) to the desired spot.

Are these statements correct?

And I am really sorry for peppering you with incoherent questions.

[slembcke]

No it was a rather good question. One which I don't really ever explain. It also caused me to find a rather old and nasty bug. :O

The idea is that you create the poly shape vertexes relative to the natural center of gravity of the shape. Guessing the CoG of the shape is good enough 99% of the time really as few shapes are going to have uniform density anyway. Now, if you wanted to attach the polygon to to a body not at the shape's CoG, then you would pass an offset parameter to both cpPolyShapeNew() and cpMomentForPoly(). At least that was how it was intended to work.

How it works in practice I think is that people almost never use the offset parameter and just lay out their vertexes to match up without it. I myself cannot remember a time when I've actually used the offset parameter for a polygon that wasn't attached to a static body. Part of the reason why I've never cared enough to address this is that it really doesn't matter as long as the moment is pretty close. The moment calculation functions all assume uniform density, which is completely realistic anyway. So the built in functions are really only giving you estimates really.

Ironically, it is probably good that nobody really did it "right" anyway. I opened up the code for cpMomentForPoly() and immediately facepalmed. The way that the offset parameter is applied is not what I meant, but interestingly, it's probably beneficial this way. It does give correct more correct moment of inertia if you wanted the CoG of the poly to be at the centroid, which is probably close to what most people are guessing anyway. Interesting how that happened out of a complete mistake. That function is one of the oldest ones in Chipmunk and I probably haven't touched it for at least 3 years.

To address your question then. The offset you apply to cpPolyShapeNew() is a convenience that allows you to attach a shape to a body at an offset. The cpMomentForPoly() function calculates the moment of inertia assuming that the polygon's centroid is the CoG. The offset parameter offsets the polygon's vertexes but does not affect the centroid. The final offset of the centroid is used when calculating the moment of inertia. This is probably what 99% of users want anyway.

Now, what I need to do is make another function that does what I originally meant, and make sure to document both well enough that people can figure out what it all means.

[shylent]

Yes, I understand it now. Anyway, since the polygon shapes are defined by their vertices, the offset argument to cpMomentForPoly in its current state is kind of redundant (unlike the one for the circle).

If it is possible I have one more yes/no question (not really related to this topic, but nevertheless), - circle shapes are actually disks in terms of collisions, right? I am a little confused, because you can specify an inner and outer radius when calculating moment of inertia, but it seems, that circle shapes are actually not "hoops", but, in fact, "disks" (objects can't be inside them). Is that right?

[Rawlyn]

I've used the offset parameter heavily when using a polygon as a static shape. That way I can define my polygon points as a shape around (0,0), and position it wherever I like on my "static" body. It just allows an alternative approach I guess. (If you don't use it, just use cpvzero.)

Although it's blowing my own trumpet a bit I should mention that if you want concave polygons I wrote a quick-and-dirty method of breaking down a concave polygons into a small set of convex polygons in this thread.

I'm afraid it's in Python, but shouldn't be too troublesome to convert to C (well, I guess... not sure how you approach reproducing the dynamic behaviour of Python's lists in C though, but still... it must be possible somehow!). Oh, and it only likes anti-clockwise polys that don't self-intersect, and it knows nothing of holes...


Oh, and yes, circles are solid circles. Same goes for polys.

[slembcke]

Yes, circle shapes are solid and don't have an inside.

Hollow objects do have a higher moment of inertia however as they have more mass that is farther away from the CoG. That is why the parameter is there for cpMomentForCircle().