CompoundBody sub-entity position & orientation

[BrianL]

If I have an entity with a non-zero centerPosition and I add it to a compound body, how is that centerPosition interpreted? Is it assumed to be relative to the centerPosition of the compoundBody? Or does the centerPosition always represent the world space center position of the sub-entity?

The same question goes for the sub-entity's orientationMatrix. Once it's a sub-entity of a compound body, is that a relative rotation or an absolute?

The reason I ask, is that I'm having trouble drawing (my own rendering code) sub-bodies in the correct place with the correct orientation once they've been added to a compound body.

[BrianL]

You can probably disregard this. I wasn't calling Space.Update(). I'm experimenting with some stuff related to compound bodies, hence the confusion. Calling update seems to generate the expected results. I'll post more if I need additional help.

[BrianL]

Okay, I'm back.

After sorting through some things, I'm still having some problems.

The situation is this:

I have an object that has several sub-pieces. I need to convert the object to a compound body, with each of the sub-pieces going into the compound body as sub-entities. The problem seems to be with the fact that the "object" has an orientation and the sub-pieces within the object also have orientations. However at the moment, the sub-entity orientations are nothing more than relative translations.

When I create the compound body and then create each sub-entity and set each sub-entity's orientation matrix and center position before adding it to the compound body via addBody, the results appear as though the orientation has been lost, but the translation has been kept.

This is all being set up before adding the compound body to the space. Are there some preconditions that need to be satisfied first? And I guess my original questions still stands. When adding sub-entities are their positions and orientations considered to be relative to the compound body or are they considered to be absolute?

[Norbo]

The positions and orientations of subbodies are absolute. So if you had a box at (0,100,0) and added it to a compound body previously positioned at (245,1235,34), the box would still be at (0,100,0).

Similarly, if a compound body is pre-rotated around the X axis 45 degrees and a box is added that has its own orientation, the box should appear to have its own orientation after being added. The relative rotation between the compound body orientation and the box is then the rotation from the 45 degrees rotated around the X axis to whatever the box's orientation is.

These relative positions and rotations can be accessed in the compound body's subBodyLocalOffsets and subBodyLocalRotations lists. The elements in these lists correspond to entities in the same index in the subBodies list. It is generally recommended that these are read-only since modifying them directly will throw off the inertia tensor (though it can be modified as well if you want).

There is one oddity that may not be immediately obvious when dealing with adding entities to a compound body. If you were to give the empty compound body some far off center position and then add a box to it at (0,0,0), the center position of the compound body would become (0,0,0). It recalculates the center position, center of mass, and the relative positions of any other entities in the compound body when entities are added.

[BrianL]

So I'm making progress. However, when I add entities to the compound body, like your last paragraph says, it seems to want to center them (maintaining their relative positions with respect to each other) around the center of mass of the compound body.

I guess technically speaking, there is nothing wrong with that though.

Am I correct in assuming that the center of mass will always be equal to the centerPosition of a compound body?

[Norbo]

Yes, it will be the same if you do not manually change the center of mass offset.

[BrianL]

These relative positions and rotations can be accessed in the compound body's subBodyLocalOffsets and subBodyLocalRotations lists.

I need further clarification regarding these two lists. Currently I'm observing the following:

I add the first child to the compound body. It's a cube centered at [0,0,0] with all sides being 0.25 in length.

I add a second child. It's a copy of the same cube except it's centered at [0,-0.25,0].

Immediately after the call to CompoundBody.addBody() the subBodyLocalOffsets are:

[0,-0.125,0]
[0,0.125,0]

Why is that? Is the call to addBody() doing some kind of average etc? If so, is that the intended behavior? How can I end up with a subBodyLocalOffsets list that looks like this:

[0,-0.25,0]
[0,0,0]

Thanks.

[Norbo]

The offsets stored in those lists correspond to the offsets from the compound body center. So after adding those two boxes, your compound body has a center at [0, -0.125, 0]. Adding the offsets to that gives [0, 0, 0] and [0, -0.25, 0], the box positions. This is the intended functionality.

With the method of construction the compound body uses, you won't be able to get [0, 0, 0] and [0, -0.25, 0] as offsets since that would imply the center is at [0,0,0]. The [0,0,0] box would need to be infinitely massive compared to the other box for the constructor to put the position there since it weights by mass (or volume, for kinematic compounds).

If you need those offsets specifically, you can directly write to those lists and see how the inertia tensor feels.

I'd recommend interpreting these values differently, such as externally changing them before rendering, without adjusting the compound's internal offsets. It's generally simpler.

[BrianL]

The offsets stored in those lists correspond to the offsets from the compound body center. So after adding those two boxes, your compound body has a center at [0, -0.125, 0]. Adding the offsets to that gives [0, 0, 0] and [0, -0.25, 0], the box positions. This is the intended functionality.

Okay I'm mostly sorted through my problems. I'm still wrestling with rotation, but I'll get to that later if I have to. Regarding the relative (local) offsets, they seem to be negated to me. Do you use them internally for anything or are they just computed and stored in those arrays for our use if we need or want access to them?

Am I right, are those improperly negated? Just want to make sure I'm not going crazy.

[Norbo]

You're not going crazy; they are indeed negated from what the documentation suggests. Those values are used internally to update the positions of subbodies, but there's no technical need for them to be negated like that. In v0.11.0 they should match the expected value (this will be noted in the version changelog).

With regard to the rotations, it may help to know how the relative orientations are computed and used internally. In pseudocode, the initialization looks like:

Code: Select all

subBodyLocalRotations[i] = (inverse of compoundOrientationQuaternion) * subBodies[i].orientationQuaternion 

And the subbody orientation update looks like:

Code: Select all

subBodies[i]. orientationQuaternion = compoundOrientationQuaternion * subBodyLocalRotations[i]

[BrianL]

Okay, sounds good.

The problem with the rotation turned out to be that I was setting Entity.orientationMatrix. However, that wasn't getting applied until the following update, at which point it was / is too late for what I'm trying to do. Setting Entity.internalOrientationMatrix did exactly what I needed.

[BrianL]

Somewhat related question, so I'll keep it in this thread.

I've noticed that sub-body entities don't seem to be calling any of the optionally registered update callbacks. Is this by design? Should I just manually loop through sub-bodies and update them when the parent's update callback gets called, since it's safe to assume that none of the children are being updated if the parent isn't being update?

[Norbo]

It is technically because the compound sub bodies do not and should not undergo a normal update procedure. For the purposes of gameplay logic, you could consider the sub bodies to 'update' when the parent updates. In the next version I may make the parent compound body call the update handler of its children as well.

[BrianL]

Okay, that's what I figured. Just wanted to be sure. Thanks.