Sign in to follow this  
Ridge Batty

Child meshes don't work with physics?

Recommended Posts

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 :)

 

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.  :)

Share this post


Link to post
Share on other sites

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 :D

 

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites

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 :D

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.

Share this post


Link to post
Share on other sites

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.  :)

Share this post


Link to post
Share on other sites
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 :D

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.

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

@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

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites
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 :D

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.)

Share this post


Link to post
Share on other sites

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

 

 

 

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.