Changing translation causes drifting of collider

Hello, I have been working on Unity physics and faced a really hard problem from my perspective. Searched every post and internet, also traced dots physics' code, yet I have not found any solution, I don't know if it is a bug or not.

Problem: I have a child entity with a physics body and a physics shape. I am updating parent's translation and rotation every frame from another system by changing Translation data. Rendering is correct, but collider is drifting (collider has the last frame's position probably). I need to get the child entity by casting a ray, yet because of the drifting, I can not get the entity at the correct position.
What I tried is:
1- Assigned the physics body component to parent, the drifting is gone, yet rayhit gives me parent's rigidbody and entity(as I mentioned, I need the child entity).
2- Made another individual prefab from the required entity and works great if I do update it's position like the other object. But this approach is so resource intensive because I have to make all the quaternion calculations again.
3- Tried to changing the update order of systems, nearly tried every possibility, no result.
4- After making an individual prefab from the required entity, I added Parent and LocalToParent compdatas in order to make it registered to parent, as I expected it is still drifting.

When I do not change translation:
5619400--582676--upload_2020-3-23_14-6-33.png
When I change the translation every frame:
5619400--582673--upload_2020-3-23_14-6-13.png
Update Order:
5619400--582709--upload_2020-3-23_14-29-48.png

What can I do? Thank you so much.

After adding:

jobHandle.Complete();
World.GetExistingSystem<TransformSystemGroup>().Update();

it is working as I needed to. But I am sure it is not the correct approach. are PhysicsWorld systems update in the incorrect order? Should not they be updated after Transform System Group?

This is among the perils of trying to put static colliders into hierarchies. Per the release notes for 0.3.0:

For best performance and guaranteed up-to-date values, it is still recommended that static bodies either be root-level entities, or that static shapes be set up as compounds. (emphasis added)

The issue is that for a static body in a hierarchy, we decompose a rigid body’s translation/rotation from its LocalToWorld component. By default, this will be the LocalToWorld value computed at the end of the previous frame. If you need a guaranteed up-to-date value before building the physics world, then you must, as you discovered, update transforms before BuildPhysicsWorld. It’s something we’re not entirely happy with, but it’s part of a larger conversation concerning the transform system .

The reason we do not is because we ultimately write back to transform components (for dynamic bodies).

1 Like