My “we need to move on” meant: “because it is not under our control we should not lose time on that issue for now”
And just THE THOUGHT of the 1e6 “hotwiring” of the maxForce! Who does that kind of crap? That has “let’s hurry up so we can release SOMETHING” written all over it. No?
Honestly no, I supposed it was a try by @trevordev and @JohnK to find a workaround as (once again) we cannot easily fix Oimo
1 Like
Regarding 4.0 release we are still in alpha (and final release is supposed to land on april 30th so we have plenty of time)
Nod. Yeah, it sounds like we’re all on the same page… just viewing it from differing angles.
Deadlines and hurrying bug me (mainly because I am SO SLOW at helping with bug-finding).
We got evidence. Monster-sized mass numbers on the body1/2 objects… insanely larger than params dictate. Evidence is here, but… ran out of leads. Got John’s colorful 1-mass wheel spinning with a 13 maxforce… after I deleted mass property from wheel body2. Weird. <13 maxForce - stuttering… 115 times per minute. 
Still not good enough. Oimo car moved mass = 10 wheels with maxforce = 6. That’s the goal.
Thanks for the public discussion. Try to keep us posted on any deadlines/rushing that accidentally arrives. 
“lose time”? hmm. Sounds racing-like. What about “lose quality”?
1 Like
It turns out that It suffers from the same issue as the rear wheels on the car. is not true.
Here is an earlier version of the paddle wheel (PW#1) https://playground.babylonjs.com/#5W5B6W#1 that does run. The issue with PW#6 is in the following lines
//physics
let cannon = true;
let forceFactor = cannon ? 1 : 1500;
scene.enablePhysics(undefined, new BABYLON.OimoJSPlugin(100));
The PG has been set to OimoJSPlugin however leaving the line let cannon = true sets the forceFactor to be 1 so the paddle wheel is under powered and will not move.
Now take Rannan’s PG (CAR#1) from his car demo blog https://www.babylonjs-playground.com/#SFELK#1 the up and down arrows do not move the car. When you then over power the motor (CAR#2) https://www.babylonjs-playground.com/#SFELK#92 (lines 351 to 355) the car still does not move. So the problem is not (only?) the scaling issue, even the 1e6 option will not move it.
Not a viable option. I wanted to see what happened if the paddle wheel PG was set up during 2.4 and 2.5 whether the scale of the maxForce in setMotor would make a difference. What happens is that the PG of the paddle wheel completely breaks in all combinations - return to investigations and have a look. So PW#1 works in BJS 4.0 but not in 2.4 or 2.5. Too much water under the bridge to go back and potential for even more projects to break.
Current position is to give users the option of just speed parameter with setMotor, in which case to have maxForce = 1e6 and, of course to allow setMotor with both parameters. As I said I am no longer certain that scaling in oimo.js is the issue with the car demo not working.
At the moment I am guessing that the issue is joining two or more joints together (as that is what I have been working on and where there are issues in all physics engines or I just don’t understand them enough to achieve what I want) but that is just a guess.
I am happy to get PRs from Wingy, or anyone else, to the investigations github that look at variations on babylon.max.js and oimo.js. Except for one exception all commits should be for new files and should not overwrite existing files. Please be clear about dates and commits in Babylon.js that the files came from and any variations made and combinations used. The exception is index.html where you can add links to your new files if you wish.
1 Like
Add console.log(scene.getPhysicsEngine()._physicsPlugin.name); to see that it is running on Cannon.
But yeah, I should NOT have used paddlewheel #6 as a featured demo… it needs cannon = false, eh?
Best thing: Clean all that crap out of there, set Oimo PE… and set the maxforce with a basic number (line 100). https://playground.babylonjs.com/#5W5B6W#58 (possibly only 2 of 4 “paddles” are physics-active, too. Not thoroughly investigated, yet)
Sure it does… ya just gotta get the maxforce numbers bigger.
https://www.babylonjs-playground.com/#SFELK#93 (no need for up/down arrows)
Here’s the other one… powered up… https://www.babylonjs-playground.com/indexStable.html#SFELK#94 (looks like it needs some gravity)
It once ran maxForce = 6. Now… maxForce = 600,000,000. :o Looks good, let’s “ship” a new BJS release. (extreme sarcasm)
If I were you, John, I would STAY in “stable” or older… because we have no idea what the kludgers have been doing with 4.0 stuff. It can’t be trusted.
I wonder if we can tell the playground to run ANY version of BJS. But I suppose, we can’t trust if/not the Oimo lib will be the same as we used in 2.4/2.5. We might not be able to down-version that, in the playground.
What does that mean? It can be trusted. I’m far more confident on 4.0 with all the great work that @trevordev did recently than I am with previous versions
You’re allowed to trust it, and I’m allowed to not trust it, right?
SO many things changed in ES6/4.0, right? When troubleshooting an older bug, it is best to keep all possible new issues… out of the way.
In my opinion, troubleshooting this setMotor issue… within the ES6/4.0 environment… will invite more unexpected results. It is best to troubleshoot one issue at a time. Keep es6 changes out of our way, for least possibility of confusions. Common sense.
Defnitely 
And actually I tend to agree with you regarding ES6 changes.
1 Like
As you know (and so do most others)… I’m not qualified to be an authority on ANY of this. I dunno what happened in 4.0, i dunno what happened in es6 conversion, and I don’t know what happened when “webpacking” happens/happened.
Considering these things I don’t know, it is best (for me) to steer-clear… avoid it. I just feel that all troubleshooting on this bug… should use consistent playgrounds with consistent BJS versions.
And, I am suggesting using “stable”… for maximum “trust” in experiment results. Better?
1 Like
John, if you have ANY power/say… don’t let “them” do that. MaxForce is a very important value. It is the “limited-slip clutch”.
Most (future) simulations of belt-driven machinery… will use belt-tensioner clutching. Programmatically, it is an easing applied to maxforce… to get the farm implement “harvesting” or the snowblower “blowing”. Motor speed remains the same… but easing maxForce up/down… is the “engaging” of the clutch/belts/pulleys.
Has anyone even checked if it could be a negative number? Does that matter?
(Wingnut extends the Enterprise shields… to create a force field around 2nd param maxForce.)
Let’s remember: broken != turn it off
GitHub - BabylonJSGuide/investigation: testing changes in bjs that affect oimo use is nice work, JK. I’m not sure how to glean knowledge from it, but I’ll be at the meetings, and listening carefully, for sure.
My position on this is I can imagine projects I may write in which all I want is for my motor to turn and don’t care if it is a true representation of the real world. I and I expect other users would be very happy in this case just to give the motor a speed value. In other situations I and other users will want to represent a more realistic world physics and will need to set the maxForce for the motor to behave appropriately. It seems to me right to give users the option to do just speed or speed and maxForce.
maxForce is the torque of the motor so negative values should not work, though in a virtual world all things are possible.
1 Like
Yeah, single param allowed as a convenience? Yeah, that would be fine. Just don’t let anyone mask the real problem… cover-over some evil… with seaweed and snot… you know. (“seaweed & snot” is a ref to movie “Top Secret”)
Adding this one-param setMotor “feature” couldn’t come at a worse time, imho. Can we defer that idea for a year or more? I’ll give you some money to do so. heh.
https://www.babylonjs-playground.com/indexStable.html#WWNQ10#24
Ever notice… that this pretty-wheel of John’s… rolls different directions… in stable or latest?
Hmm. The predecessor to this pg (#13) is where a 1-mass wheel… rolls with a 13 maxForce (line 51)… by deleting some mass values.
This one does the same, but this time I just FORCED some seriously-reduced mass numbers… onto axle and wheel… in lines 90 and 101. Works the same… no need to delete mass props.
Still, 13 maxForce on a 1-mass wheel, is too high, and anything less… stutters.
Line 51 is calling BJS PhysicsJoint.setMotor, which hands-it-off to plugin.setMotor (in case anyone cares about that).
So, nothing learned, just like the last time I posted about this playground. heh. I sure am helpful, huh? Question is… how are the inflated mass numbers… being set on body1/body2 mass? Perhaps… a lead.
Maybe newer Oimo is doing something (different) with density … multiplying mass with it. Perhaps we need to do something different with our (native)JointConfig density… instead of hotwiring it to mass, as we do now. here, too
[sigh - discouraging - May BE time to bail on Oimo, but, sad]
But remember that for a rotating body the force (or more accurately torque) has to deal with the moment of inertia rather than just mass and for a cylinder that is mass x radius x radius x 0.5 and depend how fast the target speed is reached (acceleration). It is very difficult to determine what maxForce numbers are ‘realistic’ for any body.
Ok, I’ll go along with you on that (‘moment’-arily), even though I think you’re mistaken.
Oimo car used 10 mass wheel, on maxForce 6, and still does in BJS 2.4 (it used a -31 speed).
Set the pretty wheel to speed -31. Will it roll on < 13 maxforce? nooo. And it’s only a wimpy little 1-mass.
Does your “fly-wheeling theory” hold-up to that scrutiny?
It might be fun to remind… that Oimo changes the mass… based upon the SIZE of the impostor/mesh, too. Density might be involved in that. Do some wheel size changes. Shrink it to size 2, and you only need a maxforce of 2. A size 30 wheel needs a maxforce of 109. Why does size… matter? hmm.
https://www.babylonjs-playground.com/indexStable.html#WWNQ10#26
Test playground… no Wingnut adjusted mass values, size-30 mass-1 wheel, with 108 maxForce. Get her rolling with 109. Console: body2.mass value: 706.858etc
My post 44 was, as I warned it might be, misleading and I have edited it to state this. After thorough investigation I am now certain I was right the first time and it was setting worldscale to 1 that caused the initial problem. Check my netlify link in earlier posts which now shows the correct results.
This change is a direct result of questions raised (mid Oct) on the previous forum here and here
Summary of the above topics by quotes
dbawel - How might I apply constant movement using oimo.js such as would occur in an asteroid field […] even if I set no friction and a restitution of 1, no matter how I’ve tried to apply the impulse, I cannot keep to objects moving.
fenomas - Looks like a bug somewhere in the oimo plugin - restitution not getting applied, or it’s getting overwritten, ignored, etc.
dbawel - As expected, a restitution of 1.0 or slightly above (1.05) keeps the spheres in motion.
adam - It works if you set the oimo world scale to 1
fenomas - Apparently by default it scales everything by 100 - looks like it’s something to do with working will with three.js.
scene.getPhysicsEngine().getPhysicsPlugin().world.worldscale(1)
That seems to fix things. Probably ought to be added to the default oimo BJS plugin?
dbawel - I just spent most of last week discovering that there are many broken functions in using Oimo.js with the babylon.js physics - and all is well now that I switched back to cannon.js.
Benji - Checking back with Oimo: The Vector3s apparently have to be divided by 10 to get proper results (like -0.98 instead of -9.8 for gravity; rotation likewise)
adam - The default world scale of 100 in oimo.js seems to be the problem. I set it back to 1 in the plugin’s constructor.
Benji - Awesome! Great that you found the culprit. I’m curious to see how much of Oimo’s sometimes erratic behaviors that will cure.
It might have cured one issue but created others. It is a case of solving one problem without realising the knock on effects.
I am going to carry on investigating but will for now not report anything until I have triple and quadruple checked my findings so no more comments from me in this topic for a while. I will still report my experimental findings in the investigations netlify link.
2 Likes
Wingnut hugs all the working Oimocar demos… and hugs JohnK.
https://eloquent-boyd-caa2cd.netlify.com/
That’s just… good good good. Fine investigating, J-doggy! (I’m slow catching-up with your progress, sorry)
Those (working) OimoCar demos are powerful and fast, too… nice to see. ahhh. Life is a little better, now.
How does that saying go? “Too many chefs, and you get too many blackbirds… baked in the pie” ?
errr. No, that’s not quite right.
OK I promised not to jump in again until I was absolutely certain but I could not resist. Not quite the same as the version early Oct 2016 but getting close https://www.babylonjs-playground.com/#SFELK#96
Clues from old topics in previous post plus from this one
aWeirdo- it is […] a simple question of perspective . small scenes with small objects with a camera very close by, will produce appearance of very fast moving objects. Here is a PG with the camera a bit further away, and all objects enlarged(correctly scaled though)
Benji - have to be divided by 10 to get proper results (like -0.98 instead of -9.8 for gravity
Prym8 - Scaling up to like say 100 on everything on your scene helps as well, Omio likes bigger numbers
Check out the gravity demos from https://eloquent-boyd-caa2cd.netlify.com/
The 2.4 commit b6c with gravity -9.8 and the box falls through the floor divide gravity by 10 or scale up lengths by 10 and the box does not. It does not in the 2.5 commit either. So before 2.5 Oimo liked bigger numbers see the size of the lengths in Raanan’s original car demo. So what happens in 2.5 amd after if lengths are scaled by 0.1? That is what I tried in the car demo. Now we already knew that in current PGs maxForce had to be increased. So a scale of 10 is linear and torque or maxForce is based on volume I tried 6 x 10 x 10 x 10. (Why decreasing linear measurements requires an increase in maxForce I do not know). 600 did not seem to work but something smaller than 6000 might.
I had to change direction of the up and doen keys as well. Hope this feels like progress.