solved Child meshes don't work with physics?

[Ridge Batty]

So....

to my great disappointment - yes, another one of those - it looks like parented meshes don't work with physics engine. Is there any workaround? I think it's impossible for me to unroll all parenting in the project, it would break animations and god knows what else...

BTW it looks like @Wingnut is currently working on similar issues (poor physics support). thumbs up to you for all the great work 

 

 

[GameMonetize]

Ping @RaananW to see if he can help you

But in the meantime, what are you trying to do with parented meshes? Do you want to build joints? (They are supported) or do you want to create a compound object? (Also supported)

[Ridge Batty]

I just want things to bump into each other, but the physics only detects the root mesh correctly. Even if I add impostors to children, they are not positioned/rotated correctly

[Ridge Batty]

Or do I need to parent the impostors somehow?

[GameMonetize]

Nope in physics world you need to use joints

[Ridge Batty]

Ok, so if I have a table mesh and  it has three child meshes (chairs around the table) I need to make joints to make them position correctly in relation to parent (table)?

[Wingnut]

Hi guys.  There is confusion here.  Although joints can be used to place mesh positionally-relative-to each other in what seems to be a compound structure, compounding via parenting is also honored IF it is done correctly (I think).

If I remember correctly, the ORDER of impostoring is important.  Try setting impostors on all the CHILD mesh first, and lastly... impostor the parent.  Try some tests with that, RB, if you would.  Report findings if you would be so kind.  thx

[Ridge Batty]

Yes Wingnut, that's exactly what I did! BJS even warns you if you don't add the child meshes first.
But I can only bump correctly into root meshes (which have no parent). The child mesh impostors are there, you can bump into "air" too.
I suspect their rotation and position is not inherited correctly.

[Wingnut]

Ahh, ok, yeah, we have seen this before.  Impostors out in space, with no mesh near them.  Have you tried doing the parenting AFTER all soon-to-be-children... have their impostors installed?  Parenting after impostoring.  *shrug*  (this is the last of my ideas) 

By the way, when the chairs and table are parented together, and then the parent is impostored, the impostor MIGHT be the extend-sum of all parts.

In other words, it might become one big box impostor, not irregularly shaped whatsoever.  This giant box impostor "encompasses" itself and all the child parts.  It might be one big box.  I think it is.  I dunno if that matters.

Helicopter boy... who was that?  Search forum for 'helicopter'... find that forum user.  I think he had his helicopter tail-boom... able to take hits... so he must have figured out how to do an irregular compound.  But... he might have "jointed" all the parts together, like Deltakosh suggests.

Just to add MORE hell, I wonder how child.bakeCurrentTransformIntoVertices() affects the impostor placements.  Generally speaking, a bake... leaves the mesh alone, but "resets" its origin .rotation to 0,0,0, its .position to 0,0,0, and its .scaling to 1,1,1.  Yuh, yuh, yuh, we're chasing geese, now. 

See this post by @RaananW, physics god?  " this is happening due to a new way to calculate the extend size of the object. So far it worked correctly, the problem here is the rotation (that should be supported, of course). "

That thread was about an impostor in mid-air, with no mesh nearby (same issue as Ridge Batty). 

Rotation, says Raanan.  So, if your children have been rotated at all... then try child.bakeCurrentTransformIntoVertices() immediately after setting the child's rotation.  Bake them before parenting, or after parenting, try it all. 

[Wingnut]

Deltakosh and Raanan (and others) are probably thinking "Wingnut, you are SUCH an idiot"... about now. 

There's some fancy boundingBox.extends work that happens in the physicsPlugins and physicsEngine-class objects.  Kind of scary for an old geezer like me.  heh

[Ridge Batty]

No, I have to give up. It simply takes too much time and I still have no idea what's the root cause of the problem. 

I guess no one has made a working FPS game using BJS? All the examples I've found so far are lacking in either physics or accuracy department, and I can see why that is the case.

Thanks for your efforts Wingnut, I tried everything you suggested and more! I made some headway, but there is something going on which requires more resources than my team currently has. I have to settle with some kind of hack, I just don't know what it is yet 

 

 

[Ridge Batty]

Futher development, I thought about trying Oimo.js but it doesn't seem to work at all:

 

 

[fenomas]

12 hours ago, Ridge Batty said:

Ok, so if I have a table mesh and  it has three child meshes (chairs around the table) I need to make joints to make them position correctly in relation to parent (table)?

@Deltakosh Does the physics system take parenting into effect? It looks like it just copies every impostor's position/rotation onto the appropriate mesh each frame, even though the impostor's transform is in world coords and the child mesh expects local coords.

Couldn't this issue be fixed if the "update physics object" function checked whether the target mesh had a parent, and if so transformed the (world) physics position into a (local to the mesh's parent) position using the parent's world matrix?

 

@Ridge Batty I think the easiest fix would be to unparent your chairs from the table. The whole point of parenting is usually that you want the children to move along with the parent automatically - if you want each chair to move independently from the table then the parent/child relation doesn't make sense.

If it's just an authoring issue, where the chair's initial positions are defined relative to the table, it would probably make sense to initialize them that way but still leave out the parenting.

[Ridge Batty]

Thanks for the suggestion, fenomas!

I thought about unrolling the parenting, but it's there for a good (or  bad?) reason;

- we can edit, add and remove "chairs" and dozens of decorative pieces from the models easily in our level editor
- parent/child hierarchy is used to define attachments points for weapon and armor mods etc...
- some animations rely on relative positioning/rotation of children
- and finally, our game project has over 400 individually drawn models, it's a daunting task to rebuild/rethink everything just because there's a glitch in the engine 

Yes I know I should have tried if it works before we even start. 

[adam]

You can use mesh.setParent(null) to unparent a child and maintain world position.

[Ridge Batty]

That solves the problem with collisions quite elegantly, but creates another problem when I lose the parenting.

For example, if I want to move a car, it forgets to pick up its tires, windows, etc. etc. child meshes 

Maybe this is the way it's supposed to be done. But if i have to write a second parenting system, I think using a framework starts to lose its meaning? I'm not thinking about myself as much as others who have less time and resources for making great projects.

[Wingnut]

https://github.com/BabylonJS/Babylon.js/blob/master/src/Physics/Plugins/babylon.cannonJSPlugin.ts#L126

phew.  For each child impostor... we're headed for line 229 _createShape, which is an extendSize festival.  All that extend/extendWorld bbox stuff changed about a year ago, yes?  Are we still cleaning-up FRR (far reaching ramifications) (fallout) from those mods to bbox/binfo?

I think the boundingBox extends/extendsWorld mods were fairly benign/harmless, though.  I found one minor problem with center/centerWorld in the Cannon heightMap code, but DK and I both searched for other impacts within the Cannon physics system, and found none.  Still, I think Raanan's words about rotations being a factor... should be thought about.

There's lots of child-processing code in that cannonPlugin.  Gruesome.  I suppose a guy should hijack that code into a playground and start messing with it - near line 97. 

[adam]

28 minutes ago, Ridge Batty said:

For example, if I want to move a car, it forgets to pick up its tires, windows, etc. etc. child meshes 

Wait.  You have a mesh with children and when you put an impostor in the parent mesh, the child meshes without impostors don't follow the parent mesh?

I thought you had an issue because you were adding impostors to the children too.

 

 

[Wingnut]

http://playground.babylonjs.com/#RLKVFF#43

test pg.  Four non-physics green cylinders... parented-to physics-active red box - zero-G.  Screen click fires applyImpulse at red box, red box moves, kids go along.  *shrug*

Feel free to make changes and do more saves.

[RaananW]

So, a quick answer before I dive into really understanding what's going on:

The physics system is using Babylon's parent system to create compounds. For the physics engine the parent and all of its children (who have a physics impostor) are a single object. or SHOULD be a single object. if this is not the case, I need to find the problem and fix it.

I will look at the examples now and will be able to give a better answer.

[Ridge Batty]

Thanks again to everybody for having the patience to tolerate my whining 

@Wingnut I used your PG example to illustrate my problem. Mouse click applies impulse to the ball and... it just misses the child mesh, just like in my project. I'm still willing to accept that there is some mistake I made myself, but that's ok. I just need to get this b*tch nailed down I don't care if it's due to my own simplicity. Anyway, check it out:

http://playground.babylonjs.com/#RLKVFF#45

[Wingnut]

Ahh, it's a child of a child.  (line 89)  yuh, yuh, yuh.  That might not work.

Make both cylinders be child of handle, no probs.  hmm.

http://playground.babylonjs.com/#RLKVFF#46

[Ridge Batty]

Yes, that will fix the problem no doubt about it. It's trivial to make the PG example work.

But when you have several hundred models drawn by artist with parent/child hierarchies and they have a designed function in the game... it starts to be a bit more trickier.

Then again, no pain no gain!

[fenomas]

15 hours ago, Ridge Batty said:

That solves the problem with collisions quite elegantly, but creates another problem when I lose the parenting.

For example, if I want to move a car, it forgets to pick up its tires, windows, etc. etc. child meshes 

I think you have two separate categories of problem, and need two different ways of handling it.

For things like tables and chairs, that have no parent/child relationship as far as the physics engine is concerned, you should probably remove any parent/child relationships from the meshes and make independent physics impostors for each object.

For things like car windows, or a character's arms and legs that have animations defined in local coordinates, you should probably be retaining the parent/child relationship for the meshes, and making one big physics impostor for the whole object, rather than adding each car window and character arm to the physics engine. You don't normally want every single mesh to go into the physics engine, you want a capsule for each character, a couple of boxes for the car, etc. (Hence the term "physics impostor")

Note that none of this should necessarily require you to change your authoring process or throw away your hand-made assets. But if the parent/child relationship is no longer useful at runtime (as with chairs) then throw it away at init, and if it is (character's arms) then retain it anc leave the child mesh out of the physics engine.

(If you have child meshes that need to be in the physics engine - e.g. a player's sword that needs to knock things over, or car wheels that need to physically interact with the ground, then these are a third case and will need custom coding for each individual object.)

[Ridge Batty]

Yeah you're right, it's not all done even if the child/parent relations would be inherited by physics objects.

@RaananW can you please confirm is the child/parent links inherited only one level deep by design or is there something in the engine which could be fixed?

Here's the PG (one more time) where the hit test fails for second level children:

http://playground.babylonjs.com/#RLKVFF#45