Quick note: Are you watching for customized world step speeds? I used to crank it up… to make physics run faster. AND… I think it can affect floor fall-throughs. Just something to watch-out for. A non-default step speed can cause a false deduction (when comparing general physics speeds).
Custom step-speed settings can easily hide in playground bushes… easy to miss. 
Following Raanan’s advice in his car tutorial
Oimo's default number of iterations (10) doesn't allow it to process the joint constraints correctly.[...]. To increase the number of iterations, set the first variable in OimoJSPlugin constructor:
scene.enablePhysics(undefined, new BABYLON.OimoJSPlugin(200))
[...] suspensions are now in tact and stay in the y axis
Hi J. I’m talking about time step, not iterations. I don’t think they are the same thing.
Three assorted code-lines from Cannon plugin… not in particular order/sequence:
public constructor(private _useDeltaForWorldStep: boolean = true, iterations: number = 10, cannonInjection = CANNON) {
this.world.solver.iterations = iterations;
public executeStep(delta: number): void {
this.world.step(this._fixedTimeStep, this._useDeltaForWorldStep ? delta : 0, 3);
}
I couldn’t determine much info… from investigating the Oimo plugin. I don’t know where/how it is setting its timestep.
Remember your “getting close” Oimo car from post 80? Here’s another version:
https://www.babylonjs-playground.com/#SFELK#97
The obstacles have been removed, but more importantly, check lines 337 and 339.
When timestep is faster, less maxforce power is needed. #96 needed approx. 6000. #97 uses 500. I THINK the vibrations are being caused by wheel facets, but… could be high-speed stuttering. I need to do step-speed tests on a stuttering paddlewheel, to see if stutter-rates change. I predict no-change to stutter speeds… when step speed is changed. Any bets?
All in all, I hope you watch for lines like 337 in all your testing playgrounds… to make sure someone hasn’t “slipped-in” a hidden scene.getPhysicsEngine().setTimeStep(whatever). Or perhaps we should set it for ALL Oimo test playgrounds, so we can ensure consistency.
That is a variable that could cause unexpected results for maxForce tests/deductions. Party on.
Update: I was wrong about time-step NOT affecting stutter rates.
https://www.babylonjs-playground.com/#WWNQ10#28
Lines 50-51 play area.
scene.getPhysicsEngine().setTimeStep(1/120); stutter slow
scene.getPhysicsEngine().setTimeStep(1/20); stutter fast
Try these values…
scene.getPhysicsEngine().setTimeStep(1/5);
joint1.setMotor(1, 1);
Maxforce (2nd param) of 1. Rolls fine (it seems). Wowzers! YAY! The wheel could still be stuttering real fast. How would we know if so/not? 1/2 seems smoother than 1/5, so I’m thinking 1/5 IS still stuttering… just very fast. So is 1/2. Fast stuttering MIGHT be normal for physics engines. But probably not.
Could a guy ponder… that maybe Oimo is getting a rotten deltaTime, or maybe no deltaTime at all?
Perhaps it is taking a step… whenever our browser gets-around-to-it, instead of running on engine deltaTime? hmm. Perhaps we NEVER tell Oimo how/from-where to derive a step speed.
console.log(scene.getPhysicsEngine().getTimeStep()) = 0.016666666666666666 (by default) (1/60)
I think that value is a ratio to apply-to a time-feed, but NOT the actual time-feed from engine delta-time itself. (speculating) Interesting. Notice the CannonPlugin constructor doing deltaTime value-setting, and none happens in the OimoPlugin constructor. hmm.
Aside: Changing iterations value in line 28… seemingly no affect. Also, wheel still rotates in different directions… stable/latest. hmm.
Grand Finale: https://www.babylonjs-playground.com/#WWNQ10#30 Returned to sphereImpostor, double-size wheel, mass:10, timestep:1/2, maxforce:1… rolling fine! Yum! BEEF! (Wingnut hugs Oimo for momentarily getting its shit together)
Don’t worry. We still have MANY problems. Older paddlewheel demo looks bad on a 1/5 timestep.
https://playground.babylonjs.com/#5W5B6W#60 Notice collision active ONLY on 2 paddles? I believe this is because collision-checking gets stupid… when rotation is struggling.
All in all, I think increasing time-step beyond 1/60… is a kludge-fix. It is not a solution or even close to it. But, maybe it is more evidence of SOMETHING. When we get it right, 1/60 will work as well as the 1/2 roll that we just witnessed. setMotor 1,1 should roll ANYTHING of ANY size/mass… as long as no collision/friction is present. Yes, it might take a long time to reach speed 1, but still… it should roll with a maxforce of 1. Maybe even 0.1 (imho - oimo).
So many parameters to play with.
Default time step, wheel velocity 10, maxForce 600, no obstacles car will move and very slowly pick up speed https://www.babylonjs-playground.com/#SFELK#98
whell velocity 10, maxForce 6000 is a workable solution.
I have now gone as far as I can in solving the question as per title though perhaps not completely satisfactory. The maxForce needed is much larger than the other two engines but provided users know that they can possibly live with it.
Hey, thanks for being on Team No-Fudge for a little while… I appreciate all your good work, John. Sorry if I bummed you out. It’s a grinder bug/issue, to say the least.
It’s unlikely that I can hold-off the workaround wolves by myself, using my tiny ground-holding campfire. I have resorted to burning the soap boxes that I have been preaching from atop. (Drama-Queening Inc.)
My apologies to anyone I made angry, and to @Theodore_Lee for my failing on this bug-find. Theo, you might have asked the biggest and most difficult-to-solve forum question EVER.
The topic won’t die in my brain. It’s there, forever, until solved or until someone decides that BJS no longer supports Oimo. I suggest that setLimit be disabled in Cannon, as it has been wrongly hotwired to maxforce and minforce in the CannonPlugin.
In general, I hope we quit using hotwiring/workarounds, and instead, refuse users when they try to use a plugin command that has no affect on a given PE. We don’t have enough forum helpers to help with the current level of forum physics questions. Let’s try to avoid generating even MORE physics questions/curiosities.
Let’s also avoid fooling users into thinking that Cannon setLimit (for example) does what it is supposed-to. Cannon appears to have no upper/lower angle limits on its hingeConstraint joints… and doesn’t react-to limit[lower/upper] inside joint nativeParams area.
Actually, it probably WILL react to that, as that is likely hotwired to min/max force, also. Somebody apparently thought upper/lower angle limits… were close enough to min/max force… to hotwire the two together.
I’m going to seek firing-up a paddlewheel on OImo pure native code, as much as possible. Oimo.js/joint.js at gh-pages · lo-th/Oimo.js · GitHub
I think I got it “turned on” yesterday… no errors in scene… but no mesh, either. I had to jury-rig OIMO.Euler and a couple other things… so I really didn’t make any progress. I welcome ANY assistance on activating the best-possible all-native Oimo hinge (in playground). Maybe @Raggar, God of native PE code… will visit and give advice. Thanks, everyone!
I encountered this familiar problem just right now with oimo js physics engine: using Hinge Joint & setMotor to drive the car wheel, and the wheel’s animation is very shake & strange.
And I changed to use cannon js physics engine, the problem is gone.
I think this is a big bug, hope the BJS team could fix it. I am using BJS v4.1.