PhysicsCollider not updating with parent changes.

I have many entities that are being instantiated from different prefabs and manually being given a parent relationship. I'm then rotating the parent and the children are being moved successfully by the TransformSystemGroup.

So the problem comes when they each have a PhysicsCollider/Shape, and the collider only moves when I directly set the Translation on the children. If I move/rotate the parent, the objects do move properly but the PhysicsCollider doesn't move with them - Physics is blissfully unaware that they have moved.

It doesn't seem to make a difference if I'm using physics body or just the shape, the same situation occurs.

Do I need to configure a physics joint in addition to the normal parenting to get the Physics system to pick up the changes? or is there may be a way to flag the child Translations as changed?

Versions: 2019.3.a08, Entities:33, HybridRenderer:13, Physics 0.2.0

 

I would first make sure all PhysicsColliders have an associated PhysicsBody that is set to kinematic. I believe Colliders will only move with translation changes if a kinematic body is associated with them. If they don't have one then they're consider static and never move. Usually you want just one PhysicsBody on the parent to create a compound collider from all the child colliders. However, if you're parenting them all manually this probably wont work and you''ll need to add a PhysicsBody to each child individually.

If your parent object is a GameObject then you also need to add a CopyTransformFromGameObject component to it during conversion to keep the GameObject and entity in sync. Or you can create your own transform sync system like the one I made over here, if you like.

If none of this works for you than I'm afraid it's probably going to be a lot more complicated to get working and I can't really help you much then since I'm still learning the system myself. You could also try posting an example project of what you're trying to do, which may help others understand the issue better and help you fix it.

 

The way things work today, a hierarchy of GameObjects with PhysicsShape will be converted into a single compound collider that is effectively baked at conversion time. The GameObject with the topmost shape (or with a PhysicsBody) will become the body at run-time, and the entire compound belongs to it. Because it was baked though, modifying the locations of children at run-time will not (yet) affect the offsets of the leaf shapes.

You can move shapes independently, however, if they each have their own PhysicsBody components at authoring time. The catch here, however, is that it breaks the hierarchy, since each of the bodies will be un-parented at conversion time and simulated in world space.

Although we encourage people to think of the collision shapes as immutable data, you should also be able modify the leaf shapes today using a process similar to the one in this demo.

We'll be doing some improvements here that will come in stages (first, making the results of conversion clearer, sometime later making it possible to simply modify leaf shapes in a hierarchy and trigger the compound to be rebuilt, which will of course come with performance implications). That said, if you can provide more specifics of what you're actually trying to accomplish, maybe @steveeHavok or myself could help provide a recommendation to unblock you today.

 

Thank you both for the replies

What it all boils down to is that the collider's position is based on the Translation component of the root entity. Then when you parent objects yourself then update the parent, the translation that physics is looking at hasn't changed (because it's now being used as a local space position by the Transform system).

There may be a way to manually inform physics of the hierarchy and get it to apply the to world transformation. Perhaps the BVH should run off the RenderWorldBounds instead?

Anyway, my solution to get unblocked was to put a RigidTransform on my world anchor, and do the transformation manually in my movement system so that every game object's Translation component is in world space.

 

@Adam-Mechtley @steveeHavok I've encountered this issue myself; I'm trying to create gun turrets from separate base and gun prefabs (to keep things modular). These turrets themselves may be further parented onto mobile units, again a separate prefab.

In each case the collider is being positioned relative to world origin, ignoring the entity's initial rotation.

Further to this, although the colliders will rotate as expected colliders which are for child objects no longer follow the parent entity's translation. Colliders on the base entity, eg the unit or projectiles, behaves as expected. In each of these cases, the render meshes are behaving correctly.

These prefabs have kinematic Physics Body components and Physics Shape components set to either box or mesh colliders.

You can find the project here https://github.com/Ninjars/Cubetrastrophe/tree/stress-test
I'm creating my turrets with static functions here: https://github.com/Ninjars/Cubetras...pts/Unit Initialisation/TurretInstantiator.cs
See scene

battlefield/Gun Stress Test

for a demo of how the colliders are min-placing themselves (though you may want to reduce the "Count" value on the Turret Spawner object).

This script is attaching turrets to units: https://github.com/Ninjars/Cubetras...nd/Scripts/Unit Initialisation/UnitSpawner.cs
See scene

battlefield/AttackerTest

for turrets parented to units.

Other than tarahugger's solution of moving everything into world space (which sounds like an interesting but potentially involved solution), is there any other avenue of keeping colliders of child entities tracking the translation and rotation of the entity in its local coordinate system? Given the rendering system works there's nothing fundamentally impossible here, I just don't know how to begin working towards the solution

 

Did you find a reasonable solution for this?

 

the demo is not found,and weather it was possible to simply modify leaf shapes in a hierarchy today?

 

This problem is effecting me too. I can understand that it somehow makes sense to bake compound colliders for collision and physics calculations, but what if I want to have a moving object with multiple different trigger zones (e.g. hitzones). I dont want them to behave as one and as I need mutliple triggers with different reactions they need to have their own entities (which move with the parent)

I wondering where this limitation is coming from as the colliders could clearly use the LTW component for their position.

 

I just stumbled upon this warning:


The thing is - this seems to be a lie as the entity with the physics body is not unparented during conversion

 

If a tank and turret needs to be considered as a single rigid body, but also have independently moving parts, then there can be a significant recalculation of physical properties needed as elements are translated and rotated. For example, the mass distribution of a tank with a forward facing turret is very different from a tank with a turret facing sideways. The hierarchy's AABB, the body's inertia tensor (representing how easily the body can be rotated), and the body's center of mass are all going to change as the turret turns.
If you don't care about physical accuracy, you could of course just tweak the Transform of the ChildCollider within a CompoundCollider. The resultant body might not move in an appropriate way, and depending on how much the BoundingVolumeHierachy is violated you might miss collisions.
We do need to look again at hierarchies to make life easier while keeping performance up. For example, we could expose the likes of CompoundCollider.BuildMassProperties so that specific information can updated without needing to create a completely new CompoundCollider.