[Physics] Camera parenting a Box impostor

[X3MC2]

Hi there,

I'm stuck and I can't seem to find a workaround for achieving this, basically what I wanna do is set the Camera as a parent for a small Platform which has a Box impostor of Mass 0, and make a crate which also has physics (Mass 1) land on it. But the problem is that the platform acts as if it has no physics at all, instead of landing on it, the crate goes through , here is the PG : http://www.babylonjs-playground.com/#18UP4N

 

Any help would be really appreciated. Thanks. 

[Wingnut]

Hi again X3, good to see ya.

    You are mixing the BJS built-in collision system... with 3rd party physics engine stuff.  CAN be done... but... carefully.  Most people don't mix them.

So, let's go with the all-physics engine version, and turn off all that ellipsoid, checkCollision, etc.  We'll save that for a rainy day. 

http://www.babylonjs-playground.com/#18UP4N#1

There's the physics-only box-drop, looking proper.  I switched to arcRotateCam because I like them better.  heh.  AND... I had to NOT SET platform.parent = camera (line 29).  It seems that physics impostors HATE being parented to camera.    Not sure why.  I think they hate being parented to anything.

Is there a way to avoid parenting platform to camera... for your project?  Would that be ok?

Generally speaking, physics impostors love to be free.  They dislike being controlled by parents (don't we all?) 

There might be other ways to keep camera "soft-attached" to platform... that won't bother impostors.  I will await your words and keep thinking.  Others may comment.

[X3MC2]

Hi there Mr.Wingnut  , actually I need to parent the greenbox to the camera (Player) , I'm working on a small demo where you play as a steward (The camera)  and have to deliver a cup (The crate) on a platter (The green box) while avoiding dropping it. 

So the greenbox should be carried, and the only way to do this is to set the camera as its parent, but there is something wrong with the parenting of a rigid body, after some invistigation, it turns out that parenting does not dispose the physics impostor of the child, the physics body is still there but does not follow its mesh anymore after parenting. Its like the parenting is only applied to the physicsImpostor.object, the physicsImpostor.body and its shape are being left alone. Well atleast this is what I noticed after some tests.

One more thing, I cannot create a compound object between the camera and the greenbox since the camera does not have physics, and even if I do add a physics impostor to it, it does not work well with the native controls.

 

[Wingnut]

Yes, your tests are perfectly accurate and show expected behavior.  And thanks for telling me the premise of your project... that helps us all... think of other ideas.

11 hours ago, X3MC2 said:

it turns out that parenting does not dispose the physics impostor of the child

Correct.  Do you think the platter (green box) should turn off it's physics when it is parented to something?  If it does, the crate (cup/goblet) will immediately fall-through the platter, yes?

11 hours ago, X3MC2 said:

the greenbox should be carried, and the only way to do this is to set the camera as its parent

Are you SURE it is "the only way"?  What if you turned OFF the camera keypresses, and instead use keypresses to "drive" the green box itself, and maybe the camera follows the greenbox/platter?   In this playground, line 49 proves that cameras can follow physics-active mesh.

With this new direction of thought, now you need to study how to move a physics-active mesh... with keypresses/mouse/whatever.  This is one avenue.

There is another avenue.  Turn OFF the physics engine, and "fake" the physics (go back to built-in system... scene gravity, intersectsMesh, checkCollisions, etc).  No physics enabled.

I think, with the built-in gravity system, ONLY cameras are affected by it.  So, box won't drop by itself.  Even though parenting things to the camera... is much more "plausible" (wise) when no physics engine is turned-on, let's STILL not parent to the camera.  Let's ONLY do camera.setTarget(whatever)... okay?

So where does that leave us?  You must make the box fall... yourself.  We have an excellent utility function for moving .checkCollision-active mesh...  moveWithCollisions().  Many users place one inside the render loop, and then adjust its "throttle", leaving it at zero-throttle when not needed. 

This is fine, you can probably figure out how to do that.  BUT... the game is "about" balancing one thing atop another... while walking.  SO... now we have troubles for a non-physics-active scene.  We would need to "fake" the whole balancing system, too.  When player.move(forward)... we need to fake a "goblet wants to tip-over backwards" simulation, yes?  If the goblet/vase/beverage rotates too far, it goes beyond its fulcrum point, and tips over... UNLESS... the steward quickly pulls the tray towards himself, or takes a fast half-step backwards.  You would need to create the entire system... that fakes this activity.

Although building the fake physics to do this... might seem difficult, it might not be.

SOME adventurous people might try building the "proof of concept" using BOTH methods.  I think you will find that the fake physics will be faster and easier to have full-control-over.  The physics engine version will be more realistic.  The goblet might bounce a bit... when it tips over on the tray.  Then some potential rolling, and possibly falling to the floor, with a little bounce and roll, there, too.  It would be LOTS of work to "fake" those tiny details.

Back to the physics... you will want to "walk" the green box.  I suggest using WASD position keys at this time.  Possibly use Q and E as rotate-around-Y  (steward turns).  Would you want to try to move (applyImpulse) the greenbox... in a way that is similar to a human walking?  I think that can be done.  Start with a physics-active box on the floor (like greenbox).  Give him high friction, and then whack him with an impulse from behind (thrust vector 0, 0, 3 perhaps)... applied at player center [player.getAbsolutePosition()].  That should shove him forward a few units... and he'll slide to a stop due to friction.  Later, player will likely be invisible, yet still physics active and taking thrustings.  Greenbox platter might be compounded or tight-jointed to him.  And our beverage goblet placed gently atop the greenbox serving tray.  Thrust gently with the wasd keys, Mister Steward, or you will tip over that huge stack of pancakes. 

Waiter/Waitress training school!  Fun idea, X3!  And it should be darned fun to code, too.  Make sure your mind is free from limiting thoughts such as camera == player.  That is not necessarily true.  We can disconnect the keypresses from camera, and attach them to other things, or use different keys, or never attachCamera to canvas.  InvisibleBox == player, sometimes, too, yes?  Camera can ride-along behind, in a tow-along camera wagon. 

Just some idea/thoughts.  Hope this helps.  You don't NEED to use applyImpulse to thrust physics objects.  You can also set their velocity/linearVelocity, and also set their angularVelocity, for rotating.  But you must use friction, or restitution-free invisible stoppers, to stop physics motion.  OR... just go set body.linearVelocity to 0,0,0... when you want it stopped.  If you are really good, you can make the linearVelocity adjustments you do... "act" like human walking steps.  A little heavy-on initial take-off horsepower, a softer foot-moving-forward time period, then the heel hits the floor (a potential Y-axis jarring), and then ball of foot hits floor (a smaller jarring), and then... possibly stop forward movement... possibly by using an "inverse" thrust to zero linearVelocity.  (a taper to stop).  (braking thrusters) 

[X3MC2]

Forced the physics to update the body of the child, now it seems to work: http://www.babylonjs-playground.com/#18UP4N#2

But its nowhere near a robust solution, it needs more tweaking .