Abnormal explosion behavior with cannon-es

Bugs
1

While using physicsHelper.applyRadialExplosionImpulse with cannon-es, objects affected receive a huge spin.

Here is playground:

  1. Lines 1-13013: cannon-es source code. Unfortunately, there is no way to import third-party library into the playground.
  2. Line 13015: beginning of the scene creation (this is where my code starts).
  3. Lines 13043 and 13045: here you can switch between cannon and cannon-es (cannon-es is selected initially).
  4. Line 13057: explosion parameters are declared after this line. Explosion is triggered automatically after 3 seconds. Debugging sphere is enabled.

https://playground.babylonjs.com/#TM16CA#3

What exactly is happening:

  1. With cannon-es even after weak explosion objects start to rotate as crazy. It may take many minutes for them to stop.
  2. With regular cannon same explosion does almost nothing, you need to significantly increase the explosion strength to see the reaction. However, after that objects react normally, as expected.

What is the problem:
The need to change the explosion strength during transition cannon->cannon-es is normal, because different physics engines may be configured differently.
However, the extreme spin of objects affected looks like a serious malfunction.
I realize that the problem might be hidden inside of cannon-es itself. But it also might be connected with passing parameters from physicsHelper.applyRadialExplosionImpulse to cannon-es.

Since the cannon-es support now is declared in BabylonJS and I face the problem while using BabylonJS APIs, I decided to raise an issue here first.

2

Unfortunately our physics Gurus @Cedric and @RaananW are in vacation and will only be back next week :frowning: so please bear with us during this time.

I am wondering if @arcman7 or @MackeyK24 who are HEAVY physix users might have a clue but I believe they are both relying on ammo.

3

@sebavan Yeah I definitely have not ventured outside of Ammo.js lol.

However, as someone with a physics background, maybe we can debug this from first principles.

@splash27 if you give your ground and the box object some friction values that will not happen:

2 Likes
4

Hi @arcman7,

That’s interesting.

What’s the difference between restitution/friction/rollingFriction in this case? I didn’t know that BabylonJS has also friction and rollingFriction parameters.

My guess that restitution determines which fraction of energy transfers from origin to receiver. While friction and rollingFriction dissipate velocity and angular velocity on each tick. Makes sense, but since I didn’t know that friction/rollingFriction exist I thought we can use only the restitution to determine how the object responds to forces applied.

Anyway, in this situation it feels more like post-fix or compensation for overwhelming amount of spin that the object receives. Thank you for workaround still, but it looks like that the main problem is that explosion itself gives non-realistic (broken) spin.

5

Mmm… in this case I actually think the behavior is correct. Bear with me a sec, imagine your floating in space; without friction or air-resistance there is nothing to stop you from spinning for an eternity. That is exactly what you see in the simulation.

So now maybe you’d argue that the spin of the box is too fast - try giving the box more mass. You will see that it now takes inversely more force to get it spinning faster again:

From what I can tell, the physics engine is just following standard Newtonian mechanics.

What’s the difference between restitution/friction/rollingFriction in this case?

Restitution = The coefficient of restitution

  • you can think of this one as “bounciness”

Friction = Sliding Friction = Kinetic friction (not static friction)
Rolling friction vs Kinetic friction

I didn’t know that BabylonJS has also friction and rollingFriction parameters.

If the babylon.js docs say a given physics framework is supported then I generally think its safe to assume that it’s full API is exposed in some form or another.

I hope this helps

1 Like
6

We don’t support cannon-es just yet, only an imported cannon from the cannon npm package. We still need to finalize cannon-es support (and move away from the older cannon builds).

2 Likes
7

Hey @splash27 just checking in if there’s anything more you’d like help with?

8

I think that adding the friction is fixing my problem, but I would like to know when cannon-es support will be finalized. Any estimations?

9

I’m not sure we have a timeline on that yet, @Cedric is that right?

10

Not on my side. I think @RaananW kept an eye on cannon-es.

11

We currently don’t have it on our timeline, no. We can add that as an issue, but I doubt we will find time in the near future to finalize the implementation