Multiple non-compound collider children of a mesh

Questions
1

Hi folks!

I don’t have a playground for this issue yet, because I want to understand the intended behavior before I spend a lot of time creating a repo for behavior that is not supposed to work.

Here’s a playable version of the game being described.

I have a game about a falling penguin, using the Ammo physics engine. He falls under gravity (with some wind resistance modelled via applyForce). When he hits a kinematically animated airplane, he bounces, unless he hits the propeller, in which case … well … that’s why we have checkpoints.

The airplane is a root mesh with several children: the visible meshes, and three collider meshes with physicsImpostors… one for the body, one for the wings, and one for the propeller. We initially parented all three colliders to a compound NoImpostor. It worked great, but we couldn’t tell if the propeller specifically was hit, so we got rid of the compound root. Here’s where we observed a weird behavior:

Version 1 - If each collider is parented directly to the same mesh, then only the first-added collider moves with the parent. The rest are left behind wherever they were created.

Version 2 - If we create an empty mesh parent for each collider after the first, then everything works the way we expected. Here’s a screenshot of the Inspector for one of the airplanes. The *.μ nodes have physicsImposters. The *.hack nodes are there as a workaround versus Version 1.

image

So, the question is: Is Version 2 the way it is supposed to work (no more than one collider shares a parent, except in the compound case)? Or should Version 1 work, in which case maybe there’s a bug (which I’m willing assist with the fix). Or should neither of these work, and a kinematic mesh shouldn’t have multiple collider children unless they are a compound?

2

Hello! First of all, what a fun game :rofl: I don’t know if I should laugh or feel bad for the penguin!

Moving on to the question… for ammo, I think you need the noImpostor to have multiple children (ccing @Cedric who maybe has more familiarity with Ammo than me), however, we do have the new Physics V2 plugin with Havok Physics and for that we worked to make parenting work much better, on Havok your case of having three colliders with a non-physics parent would work without issue: parenting check | Babylon.js Playground (babylonjs.com) Babylon.js Playground (babylonjs.com):

We recommend using Havok whenever possible as it has better perf too, and migrating from V1 is super easy :wink: Migrate from Physics V1 | Babylon.js Documentation (babylonjs.com)

2 Likes
3

Thank you!

Actually, the reason I was checking the behavior was that I was about to port all my Ammo code to Havoc, and I wanted to make sure everything was still working before I began the port. :sweat_smile:

I’m glad to hear that Havoc addresses this issue, among others. I’m going to leave in my hack for now, since it works reliably under Ammo. I will be keeping compatibility with both engines for the time being, since not all of the Ammo features I depend on are available with Havoc, yet. (Triggers being the most notable that I’m aware of).

1 Like
4

Oh, we do have triggers in Havok! Add observable for collision finished events/trigger events by carolhmj · Pull Request #14109 · BabylonJS/Babylon.js (github.com) it was added recent-ish, I think I haven’t updated the documentation yet to reflect it, sorry :pensive: I’ll tag myself to update it :slight_smile:

1 Like
5
6

AWESOME! :pray:

No worries… pending documentation is much better than pending features!

7

I can agree with that :rofl: Through it’s always better to have both, I updated the documentation with an example! Update collisionEvents.md by carolhmj · Pull Request #974 · BabylonJS/Documentation (github.com)

1 Like
8