solved Collisions with workers 'shaky'

[Convergence]

To save performance I check the easy-to-use scene.workerCollisions  of Babylon 2.x

However, when an object is colliding with another object, it will bounce back slightly when a collision happens. This is visible when an object for example is colliding with the ground mesh due to gravity, it won't stay still, but  rather bounce up and down ever so slightly. 

http://www.babylonjs-playground.com/index2_5.html#2E0XAJ#1 PS. 3.0 did not seem to have worker collisions using this code?

Another issue I have with collisions in general (main thread or off thread) is that if the ground has the slightest of an angle, the mesh will 'slide down' to the lowest point, even though in real life most objects have friction preventing that. Any way to 'fake' friction when using the built-in collision system?

[GameMonetize]

3.0 removed worker collisions from the main js file.

You can still use it here: https://github.com/BabylonJS/Babylon.js/blob/master/dist/preview release/babylon.worker.js

Unfortunately, due to poor way to synchronize between main thread and worker, the issue your are mentioning are tough to fix

 

Regarding the sliding issue, this is because initially collisions were made to do FPS camera. If you want better "collisions" between objets I suggest using one of the physics plugin

[Convergence]

5 hours ago, Deltakosh said:

3.0 removed worker collisions from the main js file.

You can still use it here: https://github.com/BabylonJS/Babylon.js/blob/master/dist/preview release/babylon.worker.js

Unfortunately, due to poor way to synchronize between main thread and worker, the issue your are mentioning are tough to fix

 

Regarding the sliding issue, this is because initially collisions were made to do FPS camera. If you want better "collisions" between objets I suggest using one of the physics plugin

Thanks for the reply

Is there no way for get the angle of collision (and pray, the mesh id of collision) back from the worker? 

 

[GameMonetize]

Not now  But if you are brave enough you can try to update the code to do it

[GameMonetize]

What about using camera.onCollide event?

it will give you the mesh which collided with the camera

[Convergence]

13 hours ago, Deltakosh said:

Not now  But if you are brave enough you can try to update the code to do it

I might give it a try.. would you mind to point me to the function name that does the 'pushback'?

13 hours ago, Deltakosh said:

What about using camera.onCollide event?

it will give you the mesh which collided with the camera

cool, I'll have to check it out

[GameMonetize]

Around here: https://github.com/BabylonJS/Babylon.js/blob/master/src/Collisions/babylon.collisionCoordinator.ts#L304

[Wingnut]

hehe.  Oops, there are TWO kinds of "push-back" happening here.   Possible confusion. 

#1 - "push back" = message returning from worker thread.  I think Deltakosh was talking about THIS type... not sure.

#2 - "push back" = tiny re-positioning of mesh AFTER collision (in opposite direction of collision)... to "clear" collision condition. (causes jitter/shaky, maybe?)  I have no proof that this type of "push back" happens at all. 

Convergence... which did you mean?    (this is kind-of funny - it makes me smile)

Let's tour @Dad72 demo:

http://www.babylon.actifgames.com/moveCharacter/

Use Z key and mouse... to drive "dude" into wall.  Keep holding Z... see jitter/shaky. 

Some of us think speculate that this jitter is caused by collision, then push-back out of collision, then collision, then push-back out of collision, rinse, repeat.  #2

This #2 push-back (ahem) might be done automatically... SOMEWHERE in framework code.  But maybe not. 

[Convergence]

18 hours ago, Wingnut said:

hehe.  Oops, there are TWO kinds of "push-back" happening here.   Possible confusion. 

#1 - "push back" = message returning from worker thread.  I think Deltakosh was talking about THIS type... not sure.

#2 - "push back" = tiny re-positioning of mesh AFTER collision (in opposite direction of collision)... to "clear" collision condition. (causes jitter/shaky, maybe?)  I have no proof that this type of "push back" happens at all. 

Convergence... which did you mean?    (this is kind-of funny - it makes me smile)

Let's tour @Dad72 demo:

http://www.babylon.actifgames.com/moveCharacter/

Use Z key and mouse... to drive "dude" into wall.  Keep holding Z... see jitter/shaky. 

Some of us think speculate that this jitter is caused by collision, then push-back out of collision, then collision, then push-back out of collision, rinse, repeat.  #2

This #2 push-back (ahem) might be done automatically... SOMEWHERE in framework code.  But maybe not. 

 yeah I'm referring to #2, personally I'd call #1 a callback. Yeah the BABYLON source can be a bit abstract at times with many nested function calls having very similar names.

 

[Wingnut]

Yeah... but these worker "callbacks" actually carry "payloads"... so would that be "pay-backs"? 

When we do the barrel-to-barrel collision tests in Tomas' #32 PG, there is very little jitter/shake... during held-keypress continuous collisions (head-ons, rub-arounds, rub-overs, rub-unders).   I wonder why.

I'm sure that I'm not using the correct names for these types of collider activities.  I HOPE folks understand what I mean. These are things you see... when you continue to apply moveWithCollisions in same direction, after initial/first collision has happened.  (holding-down keys... forcing continuous collision via moveWithCollisions(), or doing continuous fake gravity pull-downs with renderLoop)

Headbutt & The Work-Arounds.    Good band name.  The moved mesh either stops-dead (when colliding ellipsoids are somewhat aligned), or moved-mesh moves/rubs left, right, under, or over the static (non-moving) collider/mesh.

ANYway, perhaps the reason for lower jitters in barrel tests... is the low-power/magnitude of the moveWithCollisions(thisVector). 

Convergence, you were lowering mesh 1 unit of Y per frame... (within renderLoop).  That's a somewhat-powerful down-force velocity.  SO, I changed your line 33 to a -.01 down-force... to see if the amount of collider velocity... affects jitter amount.  No change seen.  hmm.

In the http://www.babylonjs-playground.com/index2_5.html#2E0XAJ#1 PG, does anyone else see that mesh goes well-below ground and then pushes-back out-of the ground?  I think that is #2 push-back in action.  #2 push-back... sounds messy, somehow.  heh, ewww.

*** Okay, @Deltakosh and/or anyone else... we'd like to find WHERE/HOW the collider does this #2 type-of push-back... on the moved mesh. 

I think it's hidden in the collider code somewhere.  I will do some good research today.  If anyone already knows where that code is located, we'd love to hear it. 

I saw some talk of "old position" in some code, there, but that may be for "the rubs offs". 

Why do these words, somehow, make me feel "dirty"?  heh

[GameMonetize]

Should be here (If I understood correctly): https://github.com/BabylonJS/Babylon.js/blob/master/src/Mesh/babylon.abstractMesh.ts#L1418

[Wingnut]

That's it!  YAY!  Thx DK!  Fastest answer to a forum question EVER, I think.  Too cool.

(It was directly UNDER .moveWithCollisions() code!  I'm pretty stupid, eh?  Yikes!)

Now we can do some studying.

I bet that Engine.CollisionsEpsilon is the determiner for WHEN a collider head-butts, and/or when it "rub-moves" left/right/under/over the static collider.

It is a collider positional-offset thresh-hold.   Wow, look at me speaking like a grown-up!

Yep, there's good stuff in THAT code... good learn-ables. 

[Convergence]

13 minutes ago, Wingnut said:

That's it!  YAY!  Thx DK!  Fastest answer to a forum question EVER, I think.  Too cool.

Now we can do some studying.

I bet that Engine.CollisionsEpsilon is the determiner for WHEN a collider head-butts, and/or when it "rub-moves" left/right/under/over the static collider.

It is a collider positional-offset thresh-hold.   Wow, look at me speaking like a grown-up!

Yep, there's good stuff in THAT code... good learn-ables. 

Yeah, changing BABYLON.Engine.CollisionsEpsilon to .1 seems to stop the jitter.. but I wonder what's the drawback because nothing comes free

[Convergence]

Ah, I found the drawback, when a mesh moves too slow it won't move at all anymore..

[Wingnut]

It affects the "dead-stop" zone.  It determines how far off-center the two colliders can be... before dead-stop changes-into rub-around.    (possibly drawback #2)

When you hit those "won't move at all" places... did you keep holding keypress for a really long time... like... jam a coin into the 'D' key and go have breakfast?    They still might be rubbing-around... just real real slow.  But maybe not.  If using barrel demo, you can watch the numbers, I guess... see that it's not starting a rub-around.

Interesting!

Just in case...   I made a new #37 barrels demo. (barrels initially Y/Z aligned) 

Same WASD QE R keys active.  Default collision epsilon. BUT, this PG has the position read-out to 12 decimal places, so we can see tiny position changes... if they happen.

Notice... hold 'D' key... left barrel Y position changes from 6.000000000000 ...to 6.000000001788 ... upon collision with other barrel?  Weird.   

Also, these #37 barrels have a reluctance (unwillingness) to climb-over/dive-under, for some reason.  Not sure why, but interesting.  Still learning.

[Convergence]

For now I've settled on a Epsilon of .02, seems to stop the jitter but allows my slowest-moving-mesh to still move at their normal speed  As an additional benefit it seems to stop the sliding down minimal inclines.

Thanks for the help!

If there are additional drawbacks I guess we'll find out