How to relate xpbd Position to Bevy Transform

[floppyhammer]

What's the meaning of a xpbd Position? If I have an entity with a parent transform, when I add a Kinematic body to the entity, its Transform will be determined by its Position right? Is the Position global? In this case, if I move the entity's parent, the entity won't move as well, which won't happen if there's no Kinematic body attached.

[floppyhammer]

This is my use case. I use xpbd to simulate simple hair physics. When I move the model, the hair won't follow like it does when there's no xpbd bodies attached. I realize I need to move the hair's root joints manually (as they are kinematic bodies). However, it's impossible for me to do so if I'm unable to make sense of the bodies' Position.

[Jondolf]

What's the meaning of a xpbd Position? If I have an entity with a parent transform, when I add a Kinematic body to the entity, its Transform will be determined by its Position right? Is the Position global?

The Position and Rotation components represent the global transforms of physics bodies. GlobalTransform should be automatically updated to match these components. On the main branch, you can also directly use Transform instead of Position for moving bodies.

There are several reasons why we currently use these separate components: (from Bevy Discord)

Q: What is the Position component used for? I didn’t fully understand it’s purpose from the docs, and how does it differ from the transform translation?

A:

• The Position and Rotation components are synced with Transforms at the end of the physics loop
• Position and rotation should be global from the physics engine's view point
• Transform scale and shearing can cause serious issues and rounding errors in physics
• Transform hierarchies can be problematic
• There is no f64 version of Transform, so we would have to use a separate component anyway
• When position and rotation are separate, we can have more systems run in parallel
• Only rigid bodies have rotation, particles typically don't (although we don't make a distinction yet)
• With position and rotation, entities don't need to have a Transform at all, so you could sync them with some other data structure if you wanted to

There's also some discussion in #16.

If I move the entity's parent, the entity won't move as well, which won't happen if there's no Kinematic body attached.

Currently, we make entities with a RigidBody component move completely independently of their parents. For dynamic bodies, I think this makes sense to some extent. For example, if you had a skateboard as the child of a player entity, you wouldn't expect the skateboard to magically move or rotate when the player walks around.

However, I realize that it can also be very beneficial to have children automatically follow the parent, especially in the case of kinematic or static bodies. I will most likely adopt this behavior soon and also test how other game engines or physics engines handle body hierarchies.

[mattdm]

However, I realize that it can also be very beneficial to have children automatically follow the parent, especially in the case of kinematic or static bodies. I will most likely adopt this behavior soon and also test how other game engines or physics engines handle body hierarchies.

I am new to all of this and very naive. I see the benefit of this, but it also can make things very confusing. How expensive would it be to implement this by having some convenience sugar to automatically create joints when adding children? (By default, a Fixed Joint.) That way, there's just one rule for enforcing relative movement, not two.

[Jondolf]

Using joints might be possible, but I'm not sure if it's a good default. Generally with hierarchies, only the parent's movements are propagated to children and not the other way around. If we used e.g. a fixed joint, the child wouldn't be able to move separately of the parent at all, and they would instead be perfectly fixed together. Joints (and other constraints) might also have a bit of extra overhead, but I can't currently say if it would be significant compared to other approaches.

I'm open to different implementations though. I haven't really tested how other engines handle hierarchies yet since I've been prioritizing other features for now.

[Jondolf]

Also, joints don't affect kinematic or static bodies, so it wouldn't work.