Yep, that’s what I meant by making CannonPlugin API… match the OimoPlugin API. CannonPlugin’s setLimit() is an embarrassing attempt to make CannonPlugin mirror OimoPlugin. But it’s bad, and will cause forum questions… as users expect Cannon setLimits to match Oimo setLimits, and failure is the only possible outcome. Cannon maxForce can NEVER “act like” Oimo joint-angle limits. The two setLimits are adjusting different values. Setting Cannon maxForce (via its kludgy setLimit) can never have the same functionality as Oimo setLimit. Impossible.
Can ya hear the forum questions?
“How come setting Cannon setLimits… is not working as expected, and is affecting my maxForce?” x 1000
This will make forum physics helpers… jump off bridges. heh. Unfortunately, I can’t think up many alternatives at this time. RISC-processing is the only thing that looks plausible. (de-power the plugins… reducing the amount of wrapping done by BJS, and forcing users into using native calls… MOST of the time/way.)
Not a very user-friendly approach, but more ready for lots of future physics engines, and less mirroring maintenance between plugins. Essentially, we would only have a few physics commands. ActivateEngine, getPhysicsWorld, attachMeshToPhysicsBody, and that’s about it. After that, they’re on their own, amongst “the natives”.
Also, maybe in TransformNode class… if (hasPhysicsImposter(this.ownerMesh)) { return “Sorry, this mesh’s transformations are under the control of THIS physicsBody”}; (clickable). moveWithCollisions, animations, other transform attempts… OUTLAWED… if an impostor has the mesh by the balls. heh. (unless allowBidirectionalTransformations = true. Then… who knows what’s allowed?) (Obviously, Wingnut has wandered-off, mentally, yet again.)
From what I gather, we agree there is still an issue with Oimo’s setMotor that is external to babylon.
Current recommendations from JohnK are rename setMotor parameters from speed and maxForce to speed and force. And if force is not set in the oimo plugin, default to 1e6.
That solution sounds good to me, I can create a PR for that and PRs are welcome in the future for solving the oimo stuttering issue.
Hi @trevordev . I’m not convinced that it is external to Babylon. OimoCar works in 2.4, fails in 2.5. (Original topic of post)
JohnK tested/investigated to determine that the issue(S) arrived after a OimoPlugin world scale PR by @adam … a bit after the release of 2.5. This was documented in the posts above.
IMHO, we have not been able to assemble a sufficiently large/qualified team… to complete the debugging.
If someone wants to interpret this evidence… as being “external to BJS”, so be it. I’m done with this issue - have fun with it, guys.
I’m not angry. Sad. I’m trying to take a stance against bad solves, and apparently losing. Please don’t associate my name with any half-ass blow-it-off work-arounds. Thank you.
(Old man neighbor in apt above me… slit his wrists today. I could be a bit emotionally-weird. Sorry)
The think is that the oimo we used for 2.4 is not the same as today hence the thinking that this comes from Oimo and not BJS (furthermore that it works with cannon or ammo)
And this is not a definitive stance, we just need to move on and if in the future we found a good reason to consider that this is a bjs bug I’ll be the first to fix it
@Wingnut and @Deltakosh before reading what follows please be aware that I often jump to the wrong conclusion (as I already have done in topic) so it could turn out all of the below is a red herring! Reader beware
Also there is a distinct lack of native examples with complex joints with or without motors to see what works in the native environment so we might be on a hiding to nothing.
When I found the addition of the line this.world.worldscale(1); in the OimoJSPlugin as a result of commit 8d64a08 I thought I had found that this change in the plugin was the source of the problem. After further investigation it turns out (as usual) I was wrong. Looking further at the car demo of RaananW and using versions of babylon.max.js in the preview releases folder from 17 Oct 2017 commit b6ce1ef and from 18 Oct 2018 commit b25adf8 and versions of oimo.js from 15 July 2016 and 18 Oct 2016 from the preview release folders I found out that just removing the added line from the 18 Oct 2016 version was not suffcient.
The results are
BJS 17 Oct 2016, oimo.js 15 July 2016 car moves using up arrow
BJS 18 Oct 2016, oimo.js 18 Oct 2016 car does not move using up arrow
BJS 18 Oct 2016 worldscale line removed, oimo.js 18 Oct 2016 car parts separate on up arrow
BJS 18 Oct 2016, oimo 15 July 2016 car does not move using up arrow *****
BJS 18 Oct 2016 worldscale line removed, oimo.js 15 July 2016 car parts separate on up arrow
The ***** line itself implies it is not the simple addition of the worldscale(1) line
Of course it is a major problem that this was not spotted back in 2016 (but not surprising) and tracking the changes that look likely to be unrelated to oimo.js and caused this are
probably hard to find
even harder to correct given all the changes to BJS along with with a couple of changes to oimo.js over the last two+ years.
The main effect seems to be when using joints. I have been trying some experiments with joints (with all three plugins) and it is hard to determine whether the results are expected or there is a bug, since the maths of connected bodies in physics is in itself difficult.
There are 22 commits to check between 17 Oct 2017 commit b6ce1ef and 18 Oct 2018 commit b25adf8 so next I will go through these and see if anything obvious jumps out (but I doubt if I will see the link).
We may have to live without doing complex joint based models in the physics engine for a while.
EDIT I was right to issue words of warning on this post. Carelessness on my part lead me saving experimental values in the code. If you go to the netlify link above you will see the correct results.
Think about what you’re doing, here. You are “accepting” old-version bugs… that you know are being “carried-over” into new versions, and you/someone is using bubblegum to putty-over the problems… in the new BJS releases.
What does that do for users’ confidence in Oimo plugin code? Severely damage it, that’s what.
Is that REALLY who you/we are?
My father and my first sergeant would have paddled my ass black’n’blue… if I had ever done a half-ass repair on something, which risked the safety/confidence of future users.
So, back to this “move on” thing. Instead, why not “freeze”… and then put balls to the walls to fix it?
If we agree to “NO NEW RELEASES UNTIL OIMO WORKS PROPERLY”, then maybe that would light a fire under this issue and we’d get a decent team assembled and get the thing fixed. If it takes reverting back to 2.4, then let’s swallow our pride and do it. Get it right. Set 2.5 as “preview”, pull anything newer from the release channels, walk a better path… one we can be proud of.
Well, even if it IS Oimo lib problem, when we release Oimo plugin code… we claim a “works with xx version of Oimo” expectation/assumption, right? We make a claim. “This Oimo plugin works with Oimo 1.0.9”, for example.
We are not making that claim. Physics is based on external libraries, we share them as part of BJS code base for convenience only.
There is no way in the world where we can take responsibility for a piece of code we do not own (and who is not even actively supported anymore).
We will obviously do our best effort to try to pinpoint the issue and then get back to Oimo repo and hope to get a fix (if the problem is on Oimo side which I’m almost sure it is as Cannon and Ammo as no issue)
So when a forum user asks “What version of Oimo is recommended for this plugin, and is it fully functional?”
How do you answer? (I would be scared to answer that one) heh
Not sure about the pull request point you are attempting to make. Adam’s 2.5 Oimo scaling PR was long ago. And keep in mind… that perhaps we have TWO issues, here. Overpower issue might not be same issue as stuttering.
Can you guarantee that the oimo we used at that time (2.4) is the same as today? I’m pretty sure it is not the case.
The point I’m trying to make is that we are already doing more than expected to support Oimo.
And to your question, there is no answer because there is NO fully functional Oimo library. We can’t do better than the library we are using
But I’m scared. There seems to be some kind of RUSH RUSH RUSH happening… where we seem to be wanting to do crappy work-arounds instead of actual fixes. What’s the story? What is being hurried/raced and why?