Frozen Motor Bearings on the Oimo Car and Oimo Paddlewheel

Questions
1

Hi guys. I am re-starting this topic… on behalf of myself and forum friend @Theodore_Lee.

It is a continuance of: older thread

Overview: Theo discovered that Ranaan’s Oimo Car… had broken “motor” on its back wheels. Normally, I think space-bar makes the car move forward. Perhaps it is ANY key other-than left/right arrows (steering).

The setMotor on some Oimo joints… is failing, but NOT in BJS 2.4. Last I checked, the #6 demo (link above) works fine in BJS 2.4 (another thing Theo discovered - see title of his older post).

Theo and I did more investigation… here - using lines 364-374 to try to FORCE the Oimo setMotor to start working (without needing key-press). No joy.

But we learned that ENABLING line 361… showed some “micro-rotations” at console. This COULD indicate that the setMotor IS working, but something (else) is wrong.

MY THEOry… the wheel’s transformNode is not allowing the Oimo joint-motor to rotate (much). Problem in Oimo plugin… something in setMotor area. OR… the wheel needs a property set… some big ugly-named thing like wheel.getWorldMatrix().allowExternalStuffToRotateMe = true; heh.

Here’s another playground… we’ll call “paddle wheel”. Its Oimo motor/bearing is also not-rotating. It suffers from the same issue as the rear wheels on the car.

So… as usual, we ping @RaananW in hopes that he has a miracle in his back pocket. @temechon was a pretty good physics pilot, too, but we lost him, somewhere, somehow. (I hear he’s been cuddling with a super-model) :stuck_out_tongue_winking_eye:

NOTE: The setMotor in the Cannon plugin… is working, but that might be completely impertinent to the Oimo problem. Different plugins, different motors, different methods.

As best I can tell… something happened to core… after BJS 2.4… that is making the Oimo setMotor fail… or ONLY allowing micro-moving. If you read the old forum thread, you see that Theo has begun trying to convert the Oimo car… to a Cannon car. NOT an easy task. AND, that won’t fix our broken Oimo car wheels and paddle wheel.

Here’s a link to Raanan’s Oimo Car Tutorial, as needed. As you can see, the Oimo Car is more than just 4 wheels and a body. It has spring-based “suspension”, which is pretty cool, and advanced.

All help/ideas… welcome. TWO avenues of help, needed. ONE… help Theo get a CannonJS version of the Oimo car… operational. AND/OR… help us find the Oimo setMotor problem, which could be a problem RELATED-TO BJS mesh transformNodes or similar. Remember… no problems in BJS 2.4. I think that’s a big hint. Thanks!

2 Likes
3

Pinging @trevordev to help as well.

2 Likes
4

Yeah, T-dev is definitely another coding/physics superstar… but I was worried that he might be working-on Ammo plugin motors/joints right now. Stopping Ammo dev… to visit Oimo joints/motors… could pop a gasket on the poor guy.

I think Mr. Wingnut needs to conjure-up some serious intestinal fortitude, and kick this bug’s butt. But I’m SO lazy… lately. Too much Christmas egg-nog, perhaps. :slight_smile:

5

True he is working on ammo but in vacation as well so it does not help :slight_smile: He ll be back on Monday if I remember well

6

nod thx. I started working the issue a bit,

https://www.babylonjs-playground.com/#1PVBTF#86

This has a fresh OimoJS plugin… in the playground. Those with interest… read onward. :slight_smile:

Watch console when hitting run. I am following line 766 setMotor call… thru the plugin, and then I query the actual native Oimo joint props… to make sure the values “got thru the pipe”. It appears they do.

I haven’t ever found any “nice” Oimo docs/api, so i usually use its source repo. Here’s a link directly to the joint limitMotor setMotor func. link

The properties in Oimo src lines 45/46 (motorSpeed & maxMotorForce) are the props dumped to console at PG lines 773/774. They both look correct.

Line 755… I quit calling update(). I am working ONLY with wheel1/joint1 now… the boundingBox wheel. I’m quite sure that we do not need to set motor speed/maxForce continuously. That was for driving the car with keypresses. We can set the motor ONE time, and it should spin forever (with 0 values in upper/lower limits == no limits set).

@766, I set the motor speed and maxForce… and follow it thru to Oimo native-land… with the console logs.

So, I’m STILL hanging-onto the idea/theory… that the wheel1 shape (mesh) or its transformNode… is refusing to rotate. Somebody super-glued the tire… to the road! :slight_smile: That HAS TO BE it. heh.

Perhaps THIS is where I could use MUCH help. Does anyone know of ANYTHING… involving transformNodes… that “continuously” (constantly) “freezes” a mesh in-place, rotation-wise? If so, can you help me set the transformNode to “free-wheel” and stop freezing the transform? (thx)

Back to the original Oimo car playground: For anyone who is theorizing that the physicsImpostor IS properly “bound” to the mesh shape… BECAUSE the front wheels “steer” with left/right arrows… THINK AGAIN! :slight_smile:

When the front wheels turn (steer)… they are rotating around a Y-axis JOINT. The front wheel itself is not rotating around ITS Y-axis. SO… the physicsImpostor COULD still be “detached” (unbound) from the mesh, or frozen in-place by an uncooperative transformNode. The working steering system does not prove anything helpful for our X-rotation issues.

7

Hi gang,

Correction: It is a Y-rotation on wheel1… that is failing. The Y-axis is the axle for all the wheel spheres.

I tested a manual Quaternion y-rotation on wheel1 MESH… in lines 762/763 (in below playground). Wheel1 MESH… quat-rotated a-ok.

https://www.babylonjs-playground.com/#1PVBTF#88

In line 780, I check wheel1.physicsImpostor.physicsBody.angularVelocity… AFTER the line 775 motor setting.

The physicsBody HAS some significant angularVelocity. See console:

wheel1 pbody angVel Object { x: -1.058689672062019e-23, y: 2.070190789568217e-21, z: 0.051969882945920906 }

Does this mean that the physics Impostor/body IS rolling and mesh isn’t?

Does this mean that when Oimo sets its shape.quaternion (to make the shape spin), BJS is not honoring that setting? Some kind of disconnection between Oimo (joint-) shape quaternion and BJS mesh quaternion?

Time for more tests…

https://www.babylonjs-playground.com/#1PVBTF#95

In that PG, lines 782-784, I am reporting wheel1.physicsImpostor.physicsBody.quaternion to console… every 2 seconds. As you can see from console, that quat is continuously changing… rotating. hmm.

That’s all I got, so far. Assistance welcome, as always.

8

Continued work #98

Here, I have “hijacked” the BJS PhysicsImpostor class… into the playground. It is a “universal” class… used for Oimo, Cannon, and possibly Ammo.

This is the baby that “transfers” quat rotations from the OIMO-based physicsBody… to the mesh.rotationQuaternion. It is unlikely that there is a problem, here… because…

https://playground.babylonjs.com/#5W5B6W#6

The spheres are rotating as they move. This proves that the BJS PhysicsImpostor class IS transferring “rotation orders” from the physicsBody.quaternion to mesh.rotationQuaternion.

Our issue is with the rotation of mesh… via Oimo joint-motors. Still, I want to insert some console.log checks inside the BJS PhysicsImpostor class. I want to watch-for some rotation numbers arriving from Oimo physicsBody.quaternion. I WANT PROOF! :slight_smile:

Something is “dropping the ball” along the way. We’re hot on its trail. The paddle wheel PG spheres… roll fine, but the paddle wheel axle/hub… doesn’t. hmm.

1 Like
9

@Wingnut

Heres that wheel playground working with oimo https://playground.babylonjs.com/#5W5B6W#9 @RaananW might know more about this but it looks like oimo requires a lot higher motor speed to work vs cannon, as setting the cannon variable to false gets the wheel spinning. Im still not sure why it stutters to start though. I can put this on my backlog to help fix this after i get to some other issues (Unless you find the solution in the meantime).

2 Likes
10

Thx for the work/reply, @trevordev. You spurred me onward to do more experiments, and I have good news.

https://playground.babylonjs.com/#5W5B6W#10

(Running on forceFactor = 1)

The answer: Don’t put ‘new’ before ‘BABYLON.OimoJSPlugin(100)’

Oh man, that issue haunted me before, too. I always thought Oimo ran ‘different’… when ‘new’ was used/removed, there.

Raanan use to tell me… “doesn’t matter, should work the same either way”… but there was always a difference between ‘new’ and no ‘new’.

I don’t have the AmmoCar completely working, yet. Version #103 (with its ‘new’ removed)… is locking up at scene RUN with: e.physicsJoint.motorEquation is undefined. I might need some browser cache clearing. Physics doesn’t always clear-out real well… between playground runs.

But a slimmer 1-wheel version #102 is working JUST FINE with an 8/12 setMotor in line 221. YAY! (Wingy dances around pathetically until he poops himself a little.)

Sooooo… I have to say… beyond a shadow of a doubt… “hmm”. :slight_smile:

2 Likes
11

Crap! When I removed ‘new’ from scene.enablePhysics(undefined, BABYLON.OimoJSPlugin(100));…

…it fails to USE OimoJS, and it falls-back to CannonJS. (fooling Wingnut)

That’s why the #10 paddle wheel works with low-powered setMotor. It is using CannonJS… not Oimo.

https://playground.babylonjs.com/#5W5B6W#11

See lines 82/83. Ya might need to drill the object sent to console in line 83… to see that it uses _physicsPlugin = “CannonJSPlugin”.

Crap, crap, crap. Ok, just ignore what I ever said about ‘new’. It NEEDS to be there, included. Crap.

Sorry for goose-chase and false hopes, if anyone had any. PG #102 single wheel spinning… was also running on CannonJS, not OimoJS. Hrmf! I’m an idiot.

Discovery excitement cancelled. Party cancelled. Time to go dig mud in the swamps again. erf.

Back to studying @trevordev’s 2500 times over-powered OimoJS paddle-wheel… https://playground.babylonjs.com/#5W5B6W#9 …see if I can fig why it stutters, and why it needs much more power than CannonJS or AmmoJS versions. (see line 81 - 2500 forceFactor if Oimo)

What the heck are we (am I) missing? hmm. (and crap) :smiley:

I know @RaananW has done some active dev in his OimoPlugin beforeStep/afterStep funcs (see lines 25 and 49 in OimoCar PG #98)… but most of the things happening within those… is over my head. Still, it’s a decent place to “sniff”.

PG #98 has a forced-set low-powered motor at line 1556… which SHOULD make the bbox’d wheel… start rolling… IF/WHEN the bug is solved. I HAVE tried to super-power that 1556 setMotor like Trevor did with the paddle wheel. It failed to roll the wheel, even at enormous values. I hope I have used the setMotor() correctly. i was hoping that Trevor’s over-power WOULD rotate wheel1… so we could have matching symptoms/clues between the two PG’s.

line 30: _this._deltaRotationConjugated && _this.object.rotationQuaternion && _this.object.rotationQuaternion.multiplyToRef(_this._deltaRotationConjugated, _this.object.rotationQuaternion);

heh. I don’t even understand how that code can execute… AT ALL, speak nothing of what it does. :smiley:

Keep in mind that our “problem” allows Oimo gravity-driven spheres to roll/rotate, but no rotation allowed for motor/joint-driven spheres. hmm.

12

@trevordev should be back today \o/

13

hehe. Buck-passin’… ain’t it great?

Truth is… I should have had this bug fixed by now. But I keep screwing around with other people’s playgrounds… having fun. I never get any REAL work done… cuz I’m always playing.

Its just GOTTA be something in OimoPlugin beforeStep or afterStep. My bug-sniffing dowsing rods are severely bent in that direction… and they are glowing! (none of that is true, of course).

C’mon Wingnut, stop playing with GUI diagrams and get the damned Oimo car working! Geez, I’m lazy… when it comes to difficult tasks. :slight_smile: (ok, ok, that’s a big fat lie. I’m lazy for ALL tasks.)

1 Like
14

Interesting find! Just been writing in some new doc pages about the need for large force values in Oimo. Will now have to add a conditional statement. Tried dropping new from Cannon and Ammo this just breaks everything.

15

Oh, pay no attention to the ‘remove new’ theory… I was totally wrong and chasing a wild goose. See my post that starts with “crap” a few posts-back. Removing the ‘new’ caused the scene to change to CannonJS.

Sorry about that.

1 Like
16

Thank you for letting me know. I understand, BJS finds an error so reverts to default. By the way have done my first PR of my physics’ engines findings. Need to wait for merge and deploy before available.

1 Like
18

SOME progress on the Oimo paddle-wheel.

https://playground.babylonjs.com/indexStable.html#5W5B6W#29

Line 1304… real slow motor speed set, but real high motor max-force set. hmm.

I’m looking carefully at lines 40-42… disableBidirectionalTransformation joint parameter. I think this parameter was created… at about the same time as when BJS installed transformNodes. TS src link I’m thinkin’ _tmpQuat has some kind of disease. It is under investigation/interrogation… right now. Might need water-boarding. :open_mouth:

But, if you know me, you know that I aimlessly speculate… on an hourly basis. :slight_smile:

There’s a property named _deltaRotationConjugated just above that area. That property name scares my dog, so it needs looking-into, as well. Remember, though: the ground-rolling balls… rotate perfectly in the original paddle-wheel demo, so the cause of THIS problem… only effects joints/motors. hmm.

Plugin joint-maker code at line 991. SetMotor code at 1150. Ideas welcome, always.

Native motor dump-to-console:
console.dir("r3.limitMotor1:", joint1.physicsJoint.r3.limitMotor1);
(you can see values there… matching the values used in line 1304)

For those further curious, line 1152 (in the plugin) chooses WHICH of the ‘rotational3’ motors on this joint… gets the speed/force setting. (or something like that). It is a motor-chooser line. For our joint, it chooses the LAST choice… joint.physicsJoint.limitMotor. Fascinating, huh? :slight_smile: Keep in mind that plugin.setMotor() is a universal/generic motor-activator… designed to service MANY types of Oimo joints that allow motors.

Last fun: https://playground.babylonjs.com/indexStable.html#5W5B6W#34
This is speed = 1, maxforce = 5. It IS rotating (barely) - watch for tiny movements in the bbx jaggies. Jaggy Jerky! Perhaps easier to watch rotation… by watching limitMotor1.angle being streamed to console.

19

Hi gang. Sick of this thread, yet? I am. ~sigh~

https://playground.babylonjs.com/indexStable.html#5W5B6W#38

Up until now, I didn’t remember that there are some generic/universal BJS classes that wrap the physics joints. One would think that THOSE classes would be the ones that Wingnut would hijack-into-playground… FIRST (considering this is a joint problem). But noooo… Wingy goose chasing, as usual.

Actually, these joint classes are the same joint classes used for CannonJS… so it is unlikely that they are bugged. But, when hijacked into PG, it allows us to “watch” values and actions… with inserted console.logs. And this allows/promotes forum-wide core-code bug-chasing collaboration (a really really good thing, especially when there is participation) :slight_smile:

Lines 1-52… are the joint classes. NOW I think I have ALL the physics classes that Oimo uses for the paddle-wheel… hijacked into the playground. Thus, it is the ULTIMATE bug-shooting arena… for finding the “stuttering motor issue”. (still a shortage of Wingnut brainpower, though)

Other than that, nothing new. Lines 1571/1572 show BOTH ways to activate an Oimo joint motor.

Various console reports are happening… even from the newly-hijacked joint classes. Party on, and on, and on.

20

@Wingnut If I set maxForce to 1e6 it no longer stutters, I think there might be an issue in oimo where maxForce does not work correctly. https://playground.babylonjs.com/indexStable.html#5W5B6W#40 , I might just force it to be a large number in babylon and log an error message saying its not supported if its specified.

21

Yeah.

But, that’s not a fix. I’ll keep working the issue. I’ll find it or die. :smiley:

The “rate of stutter”… is interesting. The rate is certainly not physics-step speed (which is much much faster).

WHAT… in the world of BJS… happens at a rate of about 120 times per minute? (anywhere within BJS)

It’s gotta be something stupid… silly… unexpected… right in front of our eyes, yet completely hidden.

How often… does BJS do ‘cache maintenance’?

How about system-wide isDirty checks?

Do these things happen at some repeating rate? Anyone know? (thx)

22

Semi-interesting discovery.

https://playground.babylonjs.com/indexStable.html#5W5B6W#44

(testing with user-built mesh as wheel) (1e6 work-around removed)

Line 1589 - with a 10-mass BOX impostor in line 1564, a maxForce of 8622 or higher… keeps rolling.

Line 1590 - with a 10-mass SPHERE impostor in line 1564, a maxForce of 13542 or higher… keeps rolling.

Weird. Why would the impostor-type of the wheel… matter at all?

Why would minimum-needed JOINT maxForce… change, when SHAPE impostor type changes?

Ok, that’s all I have THIS time. I’m still seeking info about ANYTHING that happens in BJS… at a rate of about 120 times per minute (same as stutter speeds).

I found another playground where somebody used highly-over-powered Oimo joint forces.
https://www.babylonjs-playground.com/#26QVLZ#72
See lines 71/72. sigh

This need for over-powering… apparently happened AFTER @RaananW’s OimoCar was created. His car uses/used a meager maxForce of 6. (lines 331-334).

Remember… the issue happened in BJS 2.5+. In 2.4, the Oimo car works fine and no kludgy over-powering was needed. I am assuming that the paddlewheel demo works fine in BJS 2.4 as well.

Does anyone have a really nice “diffs” reporter? (BJS 2.4/2.5)

I notice that we store a version of Oimo, too. Babylon.js/Oimo.js at master · BabylonJS/Babylon.js · GitHub I wonder if THAT got modded/changed between BJS 2.4 and 2.5 time-frame.

sigh. So many unknowns. I wish we would have “caught” this during 2.5 release testing. Now we’re buried up-to 3.3 in muddy over-burden, and we need to bulldoze back-down-to 2.5 level… to find pay-dirt. (fun gold-mining metaphors/symbolism, eh?) :smiley:

1 Like