Report: A CannonJS Motor Bug or Anomaly

Bugs
1

Hi guys. I mentioned this “anomaly” in another thread, but it’s time to make it official and ask for input/help/info.

This APPEARS to be an issue “within” CannonJS. I don’t think Stefan Hedman, author of CannonJS… is maintaining CannonJS anymore, but I will still report this to him… when his website starts working again.

https://playground.babylonjs.com/#7YV8E0#4

There’s the baby, trying to lift a hinge-joint leg, using line 108 joint1.setMotor(-.4, 99999999);. I need the slow .4 speed, so don’t mess with that value… during these tests… as that will affect outcome.

As you can see, the CannonJS motor does not have enough/proper maxForce (set at 99 million)… to lift the 0.3-mass leg. The motor is slipping.

Now change to OimoJS, in lines 32-34 area. Run! :slight_smile:

This time (using Oimo), the leg does a little y-axis spin, then the motor runs perfectly (in opposite direction of cannon version). No slippage, constant speed, perfect.

Now change to AmmoJS, in lines 32-34 area. Run! Same as Oimo… a little spin, and motor runs perfect… slow and consistent, in the opposite direction of CannonJS.

Needless to say (but I’m still saying it for future Cannon users)… CannonJS is doing motors differently than Ammo and Oimo.

In lines 106 to 120… are 3 different methods of activating CannonJS motors. I am currently using version #1, BJS-impostor-based… so it works on all physics engines. If you would like to do tests with method #2 and #3, make sure you have returned to using CannonJS plugin.

All three methods of activating the CannonJS motor… produce the same results… weak/slipping motor… almost as-if maxForce is being ignored.

For the adventuresome: Set Cannon physics, and then activate version #3… which is Cannon “deep native”. I set minForce == negative maxForce… because that’s what Stefan does in HIS code… here.

Ok, consider this officially reported. Future CannonJS motor users with problems related to this… MIGHT be able to find answers, via this post.

As a sidenote, I am seeking continuous readout of motor/hinge current-angle during hinge-motor run. This is something I only know how to do… in Oimo. The other two engines do not appear to have hinge current angle well exposed, but I’m still learning.

I invite discussion and tests, and all the info/knowledge I can get. I will mark this thread as solved, if anyone wishes me to do so. For one of MY projects, this is a showstopper and might make me change physics engines.

If anyone has close-contact with Stefan Hedman, please contact him and ask kindly… if he would be willing to help us with this… if he’s interested. (AND invite him to our new forum, of course.) Thx!

2

I don’t think you can count on getting anything fixed in Cannon, unfortunately.
Just take a look at the Github issues. If you look at the different forks, some people have applied different patches, and it’s a bit of a mess. Personally I have left Cannon for Ammo. Ammo is harder to customize and alter as it needs compiling and has limited exposure of internal functions, but I strongly believe it is better than an engine that is no longer maintained. If people are going to use their own custom version of a physics engine anyway, why not use the most feature-rich and maintained one.
I’m not saying people should abandon Cannon, but they should be aware of its limits and lack of updates.

I took a look at the PG, and even switched the Cannon version with more recent versions(I’ve done some fork-hunting in the past). I can’t really pinpoint the issue, and don’t really want to dwell into the darkness of trial and error, as I’m quite the idiot when it comes to math-stuff, and won’t even begin to know where to look for error-prone issues in the library. Maybe someone else have faced the same issue, but I’ll suggest you switch to Ammo for the full suite of collisions and dynamics.

2 Likes
3

Hey, thanks Raggar, and it’s darned good to hear from you again. I wish you would visit more often, if possible. I hope you’ve been well.

Yeah, I think it might require an overload/replacement of the hinge’s rotationalMotorEquation… [source] and that’s a potential “big project”. :slight_smile:

It looks like the Jacobians could be involved, too. I wish they’d just go back to Jacobia and leave us alone. heh. I wonder if they are the “spooks” that I hear talk-of… throughout the physics-engine world. :slight_smile:

All in all, thx for the good input, Matt! I pretty-much agree with all your words, but reluctantly and sadly.

4

Also, it seems Ammo is much slower than Cannon. Here’s an AmmoJS version of “Daddy Long Legs”.

Let’s do some tests.

Focus the canvas, and press an X or Z to get the legs swinging. Notice speeds.

Now change to Cannon in line 39, and do it all again. Much more fluent, eh? Ammo is almost painful, by comparison.

Try Oimo. Ammo loses hands-down, there, too. I think we might have Ammo… badly installed, somehow. Just speculation. From the few Ammo softbody tests I’ve seen, they look slow, too.

My early tests of ropeImpostor… essentially un-usable. Certainly not as smooth as my Cannon chain-o-hinges. :slight_smile:

Ammo slowness in above PG: I MIGHT have various collisions happening in the Ammo version. The current collision groups/masks (lines 515-572) are for Cannon, and maybe I need to use different methods… when using Ammo. Leg segments should only collide with ground, and not with each other or with leg-segment partners.

Also notice various at-run-time leg-spins around Y-axis of these MeshBuilder legs. I need to play-with lines 85-88 - to set initial rotation on each leg (and its partner leg-segments). Those might need adjustments, still learning.

5

Update! (oh no). First, I did some more touring of Ammo softbodies, cloth, and ropes. SOME are getting some pretty good FPS… not all of them are “slow-mo”… so… I dunno. My “ammo is acting slow” claim might be short-sighted, so far.

Now, regarding that original topic… Cannon hinge-motor too weak to lift-a-lightweight-leg issue… I have found a strange work-around. Ready? (snore)

https://playground.babylonjs.com/#7YV8E0#7

Ain’t it pretty? Look at 108, the 1st (and best) of the three motor activators. -.4 speed with maxforce of 5. FIVE, I tell ya! YAY! Same .3 mass on the leg. Perfect consistent rotation… no slippage… with Cannon. YAY! (Wingy dances)

Still issues: Motor still runs in wrong direction, as compared to ammo and oimo. Probably related-to slight Y-axis leg-spin at run-time… seen in Ammo and Oimo, but not-seen in Cannon. These legs were aligned… using Cannon. [ammo demo] [oimo demo] Leg’s initial rot is at line 78 - leg1.rotation.y = Math.PI/4; - good for Cannon version, but not for ammo/oimo. Cannon version (#7) is doing a fast at-runtime leg-spin, TOO, but it is a FAST-spin to the 45 degree angle. But, the leg SHOULD have STARTED at that angle… and it didn’t. It appears to wait-for the joint-add, before doing the 45 degree spin. Not good. I need to check my joint axes setting… more on that… below. The run-time spins seen in Ammo and Oimo version (#8 and #9) are slower and more rot-degrees, it seems.

I think Ammo and Oimo are wrong, here… and Cannon is acting correctly. But PLEASE… anyone… carefully check my lines 91/92 joint axes settings. I was sort-of lost - for that (-.25, 0, .25), setting. It could be toasted/wrong. It should probably be (-.5, 0, .5) or similar. Direction vectors always eat me for breakfast… esp when comparing a 4-sided cylinder to a meshBuilder box. Do they have similar starting axes? Who knows? Needs tests. [latest super-clean Cannon test… no runtime y-spin… uses box, not 4-sided cylinder]

Keep in mind that we are using a 4-sided cylinder for this leg. The whole inconsistency pattern might change… when using var leg1 = BABYLON.MeshBuilder.CreateBox("leg1", {height:legLength, width:3, depth:3}, scene); Tests ahead. All-in-all, the three engines should y-axis spin/not-spin the same as each other, and have the same motor directions, no matter the leg-making method. Consistency is goooood. :slight_smile:

About Oimo setMotor: Oimo gives a warning when a setMotor is tried… that includes a maxForce second parameter. It simply rejected my line 104 setMotor maxForce = 5… and failed. Its fine with me that a warning should be given, but still… set the value for me! :slight_smile: Don’t fail… after the warning. joint1.setMotor(-.4, 5); fails… due to the ‘5’. Remove it, it works fine… for Oimo. I think @trevordev worked this issue… awhile back. Can ya fix us up, there, T-dev? Thx. I will re-visit Oimo’s stuttering setMotor issue soon… to try to find the reason. Meantime, please ONLY give the warning but keep functionality of other engines… by allowing maxForce 2nd param and not forcing a value into it. Accept user-set value, give warning, and install the value, please… and if all big-dogs approve. You MIGHT wish to tell in the warning… “For Oimo, very large maxForce values may be needed.” shrug. (imho) :slight_smile:

Anyway, back to the work-around…

See lines 105 and 106? Yuh, yuh, yuh, they MUST be included in all three motor-running methods (for cannon). Actually, only line 105 is needed. Remove/ignore 106 at-will.

How Found: I was console-touring-around on the joint’s bodyA (greenbox) and bodyB (leg) native objects, and I kept seeing bodyB invMass and invMassSolve being big fat numbers… +3 to +10… yet my li’l ol’ leg only has a mass of 0.3. What the heck is going-on, here, huh?

Time for a little kludge-kode, eh? You bet. Works great. I have no idea why, or why, or even why. :slight_smile: But I’m alive and well with motors… in Cannon, now.

Ya know what sucks? I just got done speaking AGAINST “workarounds” and kludge-fixes… in another thread. Here… I just-now accidentally promoted such things. :innocent:

7

Adding @Cedric for the Physics part.

8

I have the same problem. Motor flunks out - https://playground.babylonjs.com/#66Y3CP#7

So what is the recommended Physics engine to use ?

I assume these are the correct repo’s and not forks or something …

Cannon - https://github.com/schteppe/cannon.js … Last update 6 years ago.

Oimo - GitHub - lo-th/Oimo.js: Lightweight 3d physics engine for javascript … Last update 4 years ago (I’ll exclude 12 months ago on the readme).

Ammo - GitHub - kripken/ammo.js: Direct port of the Bullet physics engine to JavaScript using Emscripten … Last update 4 months ago.

So Ammo seems to win as @ Raggar said above.

Babylon Docs seem to suggest Cannon as the default although I could be misinterpreting that.

9

cc @Cedric

10

If web traffic is an issue and your physics need allows it, I would choose Cannon.
If ammo.js size is not an issue and you need more stability/advanced features like soft bodies, I would choose ammo.

Cannon is the default for Babylon because of Legacy reason (I guess). Now, because of backward compatibility, changing default engine can be an issue for a lot of people.

1 Like
11

OK Thanks. Makes sense. Ammo it is :sunglasses:

1 Like