PhysicsImposter Collision Mesh Overlap

[nicktendo]

Hello there! Long time lurker, first time poster here...

In the following example: http://www.babylonjs-playground.com/#1NASOD#13

Why does the sphere mesh overlap (or fall slightly into) the box mesh as the box moves upwards?  Is there a way to make the sphere not overlap the box as the box moves the sphere upwards?

[Wingnut]

Hiya Nicktendo, welcome to the forum!

   No replies here yet, huh?  What the heck?

I did just a little testing on your playground (thx for providing that, btw).  Same symptom in CannonJS or OimoJS.

@RaananW probably knows exactly what causes this, but he's been pretty busy in real life. 

Also, there's been some minor changes to our boundingBox class, recently.  Check this out:

http://www.babylonjs-playground.com/#1NASOD#16

As you can see, I borrowed some code (2 funcs) from the BJS framework (physicsImpostor class), and moved it/them into the playground.

See console reports.  gbi sphere1 report to console... doesn't look healthy to me.  I don't think we should be using .centerWorld in line 56.

The sphere is elevated, so centerWorld might not be a good choice to get object center.  I'm not sure how to fix, yet, but... I will keep studying.

Sorry for the slow replies.  We are on the case, now.  Solution and more comments coming soon.  Thanks for the report about this issue.  Good eyes!

[Wingnut]

http://www.babylonjs-playground.com/#1NASOD#17

I tried another version of "get the center" that Deltakosh taught me, for another thread.  (lines 56-60)

Console report: gbi sphere:   Object { x: 1, y: 1, z: 1 }

That looks better.  But, the physics fails.  Darn.  hmm.  Perhaps .centerWorld IS the correct approach, but that darned mud.

Note:  "mud" or "muddy" is Wingy's term for when physicsImpostors sink-into other impostors a small amount - in case you hadn't heard.)

I'll have some pancakes and then get back to work on this.  (Wingnut pushes his finger into the spongy-surface of the sphere, and ponders.)

[nicktendo]

@Wingnut Thank you for the explanation, it's nice to know the issue isn't a result of my "newbness" with BJS

[Wingnut]

  Nope, you're doing just fine.  I wish I could say the same about our physics plugins or about my troubleshooting skills. 

And my pancakes weren't all that good, either. 

Forum friend @ian has been asking-for a way to "showPhysicsImpostor()"... and to be frank, I would LOVE to see a way to do that, as well.

I recently began SOME work on .showEllipsoid() (for the non-physics-engine collision system built-into BJS). (see the wireframe 'impostor tokens' here)

That system is about half-way complete, but parts of it COULD be used for .showPhysicsImpostor().  That could sure help US, here, now.  We could see if the impostors... and the actual mesh... were TRULY the same exact size.  I think they are, though.

Physics engines have a 'timestep' system.  It runs at XX speeds, user adjustable.  I'm not seeing much affect (upon sphere-sinking) in your playground... when changing it, though.

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

Same old stuff... just more Wingnut tools laying around.  I "brought in" the oimo and cannon "step" functions.  This playground is set-up to switch engines, easily, and I wanted to see the "step" function for each.  I did not modify either, though. 

Aside: In another thread, using CannonJS heightMap impostors, we saw some serious physics speed increases when we moved the Cannon .step() function into the playground.  I wanted to see if doing that... increased speed (increased sphere response-time) in your "lifter" demo, here.  No changes seen.  Perhaps a LITTLE improvement.

Remember in your other thread... where I implied that "force-moving" a physics impostor is really not "the right thing to do"... and that mesh with physicsImpostors SHOULD really be moved-with setLinearVelocity or applyImpulse?  Well, down in lines 71/72 of this latest playground, we are force-moving box.  So, I thought I would add a .forceUpdate in line 73... just in case.  Although .forceUpdate is rarely needed at a user-level, I thought MAYBE it might be needed for this forced-mover in lines 71/72.  But, no change in symptom.

The reason I am testing "time" and "step-time" so thoroughly... is because PERHAPS... our problem is HOW SLOW the physics engine is updating the sphere.  It is my (recently-deduced) opinion... that we have no "mud" problem caused by unmatched size/position between impostors/mesh.  What we actually have... is a "sphere impostor is slow to recognize collider position change"-situation.  Maybe. 

So far, timestep adjustments (line 65) have not changed the "sinking sphere" issue.

Also, I changed your 'ground' to be 'box'.  Added another ground, and now I am moving camera upward at same speed as box...  easier to see sphere-sinking.  Hope ya don't mind. 

I will keep studying.  Feel free to do your own testings, too.  I hope others test/comment, as well.  thx!

[Wingnut]

Another test.  Added an 'else' in renderLoop, re-aimed camera... that's all.  Change step in line 70... for more/less sphere sinkage-into box.

I'm not sure I can solve this.  Difficult to make sphere/box surfaces impenetrable.  hmm.  Perhaps others will have ideas.

[nicktendo]

@Wingnut Great progress here!  I ended up just implementing my own collision detection, and it's working out pretty well.  Using physics wasn't entirely necessary to achieve my end goal, and in reality added a lot more CPU overhead than just implementing the simple functionality I required myself.

As far as the sinking issue with the physics plugin - I'm thinking it may have something to do with the engine not beginning to "process" the collision until the 2 meshes intersect, which would mean if the colliding mesh doesn't happen to hit the "ground mesh" at precisely the surface (i.e. the distance the colliding mesh is moving every frame isn't evenly divisible by the initial distance between the colliding mesh and the ground), it falls into the ground mesh by whatever distance it was being moved every frame.  I think that's why the slower we move the colliding mesh the shallower it sinks into the ground.  I believe the ultimate solution to the sinking issue would be modifying the physics such that a function is triggered once the colliding mesh is within a distance where it's movement vector divided by 2 is less than 1, and on the last frame the position of the colliding mesh position is set to the surface of the ground mesh.  In this manner it may be possible to mitigate the sinking by taking manual control of the colliding mesh position for the last frame prior to collision.

Just an idea