Havoc: problems with parented meshes

In the following playground use WASD keys to navigate.
Press 1 to open/close sliding door.
Press 2 to open/close rotating door.
You can also push the box by running into it. Box collisions are logged into console.log.
https://playground.babylonjs.com/#4517EG#3

Problems:
a) When sliding door opens it creates the copy of the door behind (with some offset to the left).
b) Rotating door appears to be misaligned, it also opens incorrectly.
c) Box can not be pushed through open door. It still collides with physical bounding box of the corresponding door.

If you remove the PhysicsAggregate doors start to work normally except the fact that box now can be pushed through the closed door (which totally makes sense, because doors are not physical anymore).

The setup above worked just fine with Cannon. In Havoc it feels like the mesh and itā€™s physical collision box are totally out of sync when the mesh is parented. I also get very weird behavior when I try to attach PhysicsAggregate to stairs (several cubes different in size parented to a virtual transform node), but this worth a separate topic.

a): Unable to determine what creates the ā€œcopy of the door behindā€
b,c):
If it wasnā€™t for parenting, it wouldnā€™t have moved, but I think this is a bug related to parenting.
To unlock physics for movement, set disablePreStep to false, move it, and lock it again to get the physics that matches the movement.(PG did only disablePreStep is false)
https://playground.babylonjs.com/#4517EG#5

What is the meaning of ā€˜aā€™

I misjudged the collision to collision as harvokā€™s physics.
anyway
Since the physics assigned to the child are not assigned to the parent, in reality the position of the door is only the location of the parent and does not match the physics of the child.

https://playground.babylonjs.com/#4517EG#7

However, I think the pg above only broke the parenting system and is not a solution to the question.

Childcare in Babylon It seems to be a different process from Habokā€™s hinge and physics, and it is recommended to use child care using the hinge in a similar way.
Basically, values ā€‹ā€‹such as shape and position of a physical body can only have values ā€‹ā€‹with a given mesh, instance mesh, transform node, etc., so either of the following is sufficient.

  1. Childcare in Babylon is checked hovokā€™s enable then When parenting, the physical body value of the child is passed to the parent, and the child is changed to non-physical.
  2. Parenting is discouraged and hinges are used

but I think all the answers were a way to bypass rather than a solution.

Yeah, itā€™s just hiding the problem under the carpet. With such approach we have to leave all parents in (0,0,0) position, which is inconvenient. Also, it doesnā€™t work with rotating door. Also, it doesnā€™t work with more complex static objects, like these stairs: https://playground.babylonjs.com/#GZIEA0. When physics is disabled, it looks normal, and it worked more or less normal with Cannon. But PhysicsAggregate turns it into a brick submersed into the ground. There is definitely something wrong happening with internal variables.

Iā€™m taking a look at that today.

@splash27 Iā€™ve done some changes in this PR:

Parenting should be supported now. Let me know how it goes once the snapshot is available for testing.

1 Like

Sorry, my initial playground had poor parenting setup for rotating door, thatā€™s why some misplacement oddities happened. I just forgot to position both hinge and rotatingDoor into correct positions before parenting.
https://playground.babylonjs.com/#4517EG#11.

But the problems didnā€™t go away.
If I first do positioning and parenting and only then I attach the physicsAggregate everything looks okay while itā€™s not moving. However if I try open a door itā€™s forcedly closed immediately (true for both doors). Overall, it looks like after physicsAggregate is assigned I canā€™t move object anymore, by changing its parentā€™s position, which was possible with Cannon.

The stairs look okay if physicsAggregate is assigned after all steps are positioned. So at least it works with static objects now. But there is another oddity. With BABYLON.PhysicsShapeType.BOX everything works as expected, but with BABYLON.PhysicsShapeType.MESH it doesnā€™t work at all. A cube can be pushed through the stairs.
https://playground.babylonjs.com/#GZIEA0#1

@Cedric thank u for this great update. I think there is still a problem. If we donā€™t set position for the child mesh, it will automatically get the negative values of parent position, and it wonā€™t be 0,0,0. Do you think is that an issue?

Iā€™m listing all the various parenting cases this week and will continue dev with @carolhmj
This is a complex subject that can give a lot of regressions if not done seriously.
Iā€™ll keep you posted.

3 Likes

Any updates so far?

Issue is still on our todo list. No update so far.

Hello! We have a draft PR for that: [Physics] Better handling of parented bodies by carolhmj Ā· Pull Request #13914 Ā· BabylonJS/Babylon.js (github.com) with just a few issues to go over (mostly the stability of the solution)

1 Like

Update: PR has been merged! It will be in the next release :smiley:

3 Likes

My PG still doesnā€™t work: https://playground.babylonjs.com/#4517EG#11.
When I try to move the parent, the child element with physics attached doesnā€™t move. It was possible with Cannon.

a) , b), c) is resolved

https://playground.babylonjs.com/#4517EG#13

What is exactly not working on the PG?

@splash27 You have to use body.disablePreStep = false; to allow babylon-sided changes to affect the physics body (mesh rotation, position, etc)

Okay. It works now. Thank you so much.

I noticed one more oddity. Probably itā€™s not related to current parenting problem, but I started to see it on last release. If you will open browser console during my previous playground: https://playground.babylonjs.com/#4517EG#14 you will see two warnings:

Cannot read properties of undefined (reading 'rotationQuaternion')

Looks like they are caused by cloning walls:

let wall_4 = wall_1.clone("wall_4");

and

let wall_5 = wall_1.clone("wall_5");

Itā€™s interesting, that those warnings are caused only by those two walls above.
const wall_2 = wall_1.clone("wall_2"); doesnā€™t lead to warning.

Why is this happening? Is it a problem? Can it be avoided?

Itā€™s ā€œjustā€ warnings, so it should be ok to ignore itā€¦ as long as thereā€™s no actual error thrown.
But possibly something to do with cloning a mesh with a physics body/aggregate?

Here i moved cloning up, before any aggregates are added and the warnings are goneā€¦
I donā€™t know why it happens though :slight_smile:

1 Like

Thanks for bringing this to attention, it was indeed a bug in the way the cloning was done, it will be fixed by this PR: [Physics] Fix warning on copying a mesh with physics body by carolhmj Ā· Pull Request #13951 Ā· BabylonJS/Babylon.js (github.com) :slight_smile:

5 Likes