Frozen Motor Bearings on the Oimo Car and Oimo Paddlewheel

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 :slight_smile:

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”. :slight_smile:

Also, maybe in TransformNode class… if (hasPhysicsImposter(this.ownerMesh)) { return “Sorry, this mesh’s transformations are under the control of THIS physicsBody”}; (clickable). :slight_smile: 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?) :slight_smile: (Obviously, Wingnut has wandered-off, mentally, yet again.)

@Wingnut @JohnK

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.

1 Like

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 :upside_down_face:

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

You can check these results using https://eloquent-boyd-caa2cd.netlify.com/

(code on github GitHub - BabylonJSGuide/investigation: testing changes in bjs that affect oimo use)

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

  1. probably hard to find
  2. 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.

Ok keep us posted thanks a ton

Is THAT a “definitive stance”?

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.

heh. How’s that for some den-mothering? :slight_smile:

Well as we are not sure if this is in BJS I’m not sure we are carring over anything. This is why I’ll wait for @JohnK investigation

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.

If it doesn’t, we’re liars. :confused:

Also to make sure we have more data, @trevordev will do another round of investigation

1 Like

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)

And to give even more meat to this discussion, see who did the latest PR on Oimo codebase:
Fix minification process by sebavan · Pull Request #85 · lo-th/Oimo.js · GitHub (yes it is @sebavan)

Even more:

The last three all come from us trying to fix Oimo

And then the fourth one is more than a YEAR ago.

The official car demo is broken: Oimo.js Vehicle
So how can we expect it to work with bjs?

That’s why i said: let’s move on until we found a way to fix Oimo directly

So when a forum user asks “What version of Oimo is recommended for this plugin, and is it fully functional?”

How do you answer? :slight_smile: (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

And that also why we spent time and energy on supporting Ammo, in order to provide a better Physics support (as they are still actively supporting it)

That’s not good enough justification to kludge the Oimo setMotor… which needs backward compat. (imho) How much to hire Raanan, I wonder. heh

Well so let’s fix Oimo right? And we probably need to hire Oimo developer then (if he is still around)

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?

Seriously? Where did you see that?