gltf and oimo physics, strange movement

[ponponboy]

hi guys. Im new-comer babylon world!

I have a question, I have load glb file, then use Oimo physics.

so this glb-loaded Cube starting Let's dancing. why??

plz look this!

https://playground.babylonjs.com/#6UZ7BJ#1

[Wingnut]

Hi PPB, welcome to the forum.  Thanks for the report and playground!  Interesting!

I have no solution, yet.  Just begun work.  Newer test playground...

https://playground.babylonjs.com/#6UZ7BJ#2

Problem is OimoJS only, I think.  Swap lines 8/9 to switch-to CannonJS.

I think we better ping physics genius @RaananW to ask for assistance.

Meantime, Wingnut grabs his Sherlock Holmes pipe, hat, and magnifying glass, and begins his investigation (likely fruitlessly).

Extra issue:  I see (overly?-) large differences in restitution (bounce amounts)... between Oimo and Cannon.  hmm.  Still testing/learning.

Stay tuned, ponpon!  More comments coming.

update:  PG #4 - In lines 28-32, I raise the root!  (ar ar)  (raised a little per frame)    Things act weird.  Adjust values in line 30... to vary the weirdness.   PG #5 is even MORE weird, as I lower the root. 

[ponponboy]

Thank you Wingnut! I have never try CannonJS!

I will try to use CannonJS this time ;D

[Wingnut]

My pleasure.  Sorry it is taking so long to find the Oimo problem.  I wonder if there is a "physics test suite" that is tested each time a new version of BJS arrives.

Also, it seems helpers don't like working-on physics issues... because it's difficult.  I'm that way.

But, this bug/problem is sliding thru the cracks, so we (I) had better get to work on it, as best I can.

Oimo's motorEnabledJoint.setMotor() also appears to be failing, somewhat.  We have a report about a failing physics car.  Its steering turns, but its wheels won't roll.

What caused these Oimo issues?  How would we know, without making new BJS releases pass a physics-suite test/benchmark? 

Otherwise... we're just "fishin' in the dark", it seems.  Those mesh in ponponboy's demo... are moving back and forth about once per second.  SOMETHING is checking SOMETHING... once per second... in the Oimo plugin.  The ignoreParent parameter IS involved (line 26 of #5 PG below), I think. 

Big question might be... WHY is something checking/changing something once per second? 

My initial thoughts... is that there is a periodic "onParentChanged" observer/poller... happening somewhere.  But I'm wrong... often.  I'll keep thinking... maybe do more testing.

Fellow forum helpers... c'mon aboard if you can.  https://playground.babylonjs.com/#6UZ7BJ#5

If Albert Oimo saw that, he would be ashamed of that playground.     hmm.

[Wingnut]

Hi PPB and thread followers.  Two new playground versions:

PG #7 is a "troubleshooters playground"... hijacking-into PG scope... some recent versions of the Oimo plugin (probable cause), the BJS PhysicsEngine (unlikely cause), and BJS PhysicsImpostor (unlikely cause)... classes. 

Generally, I insert some console.log() in various functions... to see if I can determine WHAT is running periodically (causing the mesh to keep jumping, for no reason at all).  If I/we can get a console.log() to fire with EACH mesh-jerk, I/we will be near-to a reason/solution.  No luck, so far.

PG #8 is almost identical, except it turns-OFF the .glb loader, and creates the mesh in-scene.  These mesh include an invisible parent named root, and two children... box and cone.

As you can see, these two versions ACT differently.  I'm not sure why.   I THINK the reason is:   In the .glb version, the cone and box have differently-sized bounding boxes, so their impostors differ (from each other) in how they act.  In my #8 made-from-in-scene-mesh version, both impostors are identically-sized, and thus perfectly mimic each other.  (Both cone and box... use boxImpostors.)

Maybe MORE concerning:  WHY do both of these playgrounds... report THREE impostor-adds at the console?  Shouldn't there only be TWO? 

Ok, ok, I'm not TOO concerned with that, because the PG #9 working-better-but-restitution-weak CannonJS version... also shows 3 impostor-adds.

I'm still testing and learning.  All my tests were/are done in Firefox.  My IE won't run any of these PG's.

Help/ideas welcomed, of course.

Update: Here's another... PG #10.  Non-glb-loader.  Here, I un-parented the box and cone children (from root)... and added the impostors directly-to the cone and box (without using a loop thru root.getChildMeshes).    

Works good.  I increased restitution on cone's boxImpostor... so box and cone would bounce differently from each other.  ALSO, the ignoreParent param has been removed from the impostor-adding lines (1420 & 1423).  Looks good.  No mesh spasm-jumps.  SO... this LIKELY indicates that the issue involves parenting, and/or ignoreParent parameter.  hmm.  Interesting.  We're hot on its trail!

[Sebavan]

ping @RaananW ?

[Wingnut]

Hiya @Sebavan! 

I already tried that, last Friday.  Raanan is in the Congo, building a disco club for Pygmies. 

err... he's busy doin'  SOMETHING.  And I'm thinkin' maybe... he's starting to hate this place... because of all the physics workload that's being "assumed" and "custodianed" onto him.  Uninvited "delegating".

Maybe I'm overly-concerned, though.  *shrug*

We need more physics helpers/testers.  We need a bigger physics-help team.

I TRY to advance things toward solutions... but I'm one of the worst JS programmers this side of the Manson-Nixon line.   Mostly, I build testing playgrounds for smarter people.

Right now, I'm sort-of in "think mode"... trying to figure out WHAT would "run" about every 1-2 seconds... (to cause the unwanted mesh movements)... within the Oimo physics plugin code.  I can't think of a reason to poll/check/run something... at that speed/rate.  Very strange. 

Dive-into the code with me, Sebastian!  Let's go!  Grab your scuba tanks.... it's DIVING time.  (Wingy hands you a shot of Jack Daniels to help you stay warm.)     PG 8... fill the plugin code with a million console.log()... let's figure out WHAT is running... every time the mesh jumps.  It's GOTTA be there... something to do with parenting.  All comers... welcome!  Yay team!

[Guest]

Well the first problem is that getChildMeshes predicate was misused (it is here to filter not to run through all meshes):

https://playground.babylonjs.com/#6UZ7BJ#11

Also as Oimo is less stable than Cannon, I forcefully unparented all meshes 

[trevordev]

Looks like this might be related to the -z root node scaling when loading gltf models as using babylon in right handed mode works. https://playground.babylonjs.com/#6UZ7BJ#12

[Wingnut]

Thanks guys, but, we already knew that the problem happens to parented mesh.  So, un-parenting WILL remove the problem.  That's not a fix. 

The ignoreParent parameter SHOULD allow the parenting, in theory.  It does this correctly for CannonJS plugin.

Also, right-handed mode doesn't fix the non glb-loader version.

https://playground.babylonjs.com/#6UZ7BJ#15

Oimo and Cannon ignoreParent parameter should work identically.  OimoPlugin ignoreParent has a problem.

I hope I'm not being a prick when I say, "stay on-target, gang." 

 

Here's another test:  https://playground.babylonjs.com/#6UZ7BJ#16

In line 45, I'm smoothly moving the root... along +z.

The children are following... in periodic "jerks".

Now change to CannonJS in lines 9-10.

Issue disappears.  

Problem COULD be caused by the OimoJS engine itself, I suppose.  We would need to determine if Oimo ever checks for its shapes... having parents.  I will try some searches of the Oimo source code. 

There's 24 occurrences of 'parent' in the Oimo source code.  Possibly one/some of them... ignore OimoPlugin's ignoreParent.    CannonJS source has NO occurrences of 'parent'.  Interesting!  hmm. 

Actually, there are 134 occurrences in Oimo.js file.  I have added console.log('test') to most/all places within Oimo.js... that seemed pertinent (15 various locations).  I still cannot find a console.log() that happens ONLY when the mesh jumps.  Darn.

Yesterday, in PG#8, I inserted MANY console.logs into the plugin, impostor, and physicsEngine code.  No functions were seen running "once per mesh jump".  THAT could indicate that the "jumping" is happening at Oimo engine level, and maybe not in the OimoJS plugin.

Thanks for helping, guys.  Let's keep trying.

[Wingnut]

Hi again.  I decided to read the docs about ignoreParent and see if there was info.

Then I modified the provided playground demo...

https://playground.babylonjs.com/#PRHF00#7

One odd discovery:

In line 40, I am moving the parent... upward 0.0015 per frame.  Everything looks good.  No significant Brownian jitter on sphere2 (I reduced its restitution a bit), and no "mesh jump".

Now change the value to 0.0014.  RUN.  After that, I DO see a "jump" and ground fall-thru, for sphere2. 

Do others see that?  Pretty strange.  Even my dog is making a "hmm" sound, and scratching his beard in deep thought. 

---------------

Here's another oddness and PG:  https://playground.babylonjs.com/#PRHF00#8

This one is REAL similar-to the PG #4 listed in the docs.  The only significant difference... is sphere #2 restitution (line 37).

For me... set line 37 restitution to 0.8.... no problems.  Set it to 0.7, and I get mesh-jump and fall-thru.  hmm.

----------------

Some tests... seem to show that the box impostors must be laying flat (isSleeping/allowSleep)... before the jerking starts.  In this test, the parent/root is headed ONE way, and the impostors (after laying flat) are jerk-moving THE OTHER way.  Weird.

[Guest]

The real problem is that we cannot fix Oimo unfortunately. I went to their repo and the author seems to work on a new version. Hopefully this should improve the overall quality.

We could perhaps try to open an issue on their forum pointing to the faulty PG but I doubt it will change anything

 

[Wingnut]

Hiya.  We don't yet know IF the issue IS the physics engine.  I'm not convinced of that.

Yesterday, I put BUNCHES of console.logs into Oimo.js, and tested, tested, tested.  I could not find ANY places where Oimo was doing something to a shape parent... periodically, about every one second.  Some functions run very very fast, and it is impossible to see if a "bad poke" happens among the continuous stream of function calls.  My console.logs are essentially un-readable when they scroll-by @console so fast.

Had I found a syncMeshWithImpostor() or updateMesh() or ANY parent-related code that executed each time the mesh jumped, then I could believe Oimo itself is the problem.  But I didn't find it.

https://github.com/search?q=org%3ABabylonJS+ignoreParent+is%3Apr&unscoped_q=ignoreParent+is%3Apr

Second one... that's where ignoreParent was introduced, it seems.  Almost exactly a year ago.  BidirectionalTransformation is mentioned in there, as well.  I have seen this term in the plugins, too.  It's an awfully large term, but I think it means... positioning, rotating, or scaling (transforming)... works in BOTH directions for the child-parent.  Transform either the child or the parent, and its counterpart does the same.

In our test PG's, you can tell that root's POSITION is NOT completely ignored by children with impostors set ignoreParent: true.  Just... somewhat ignored.  The root/parent doesn't perform the physics motions that the children do.  All in all, possibly important info for those that want to begin/continue work on this issue.

And possibly, this WHOLE situation... is about "compound" physics structures (clusters of physics-active objects, stuck together)... which attempts to use our "standard" .parent system as the "glue" for compounding.  Perhaps we should consider creating/using .physicsParent... so that our standard .parent system can be completely bypassed for mesh whose physics are active. 

Not sure.  It seems we have been battling "compounds" for 4 years now... and our progress is questionable.  Thoughts welcome, always.

[Guest]

It must be the engine as it works with Cannon.js no?

(This scene is special in the sense that the root parent has a negative scaling on Z axis (because glTF is right handed unfortunately))

[Wingnut]

Quote

It must be the engine as it works with Cannon.js no?

It could be a problem in the Oimo plugin.  (likely is.) 

My theory... .ignoreParent parameter hasn't worked correctly in Oimo plugin... ever (one year), due-to ignoreParent testing PG not being thorough enough.  Unexpected Oimo "fallout". 

If it IS a problem with Oimo plugin, I hope to help RaananW find it, or find it FOR him.  He's helped me (and others) MANY times.

At least, I would like to learn the reason WHY it happens.  Doesn't everyone? 

19 hours ago, Deltakosh said:

(This scene is special in the sense that the root parent has a negative scaling on Z axis (because glTF is right handed unfortunately))

Not really pertinent.   https://playground.babylonjs.com/#6UZ7BJ#8  ...uses scene-made mesh and no glTF-loading.  Issue is still happening.    Are my briefings/progress-reports being read? 

[Wingnut]

Let's try a re-brief.

Original PG demo for ignoreParent... from the docs: https://playground.babylonjs.com/#PRHF00#4  (uses CannonJS).  Looks good, but mesh is falling-off ground while still bouncing.

Wingnut modified demo:     https://playground.babylonjs.com/#PRHF00#10   Bigger ground, switched to Oimo, target-locked cam, reduced speed of parent movement, reduced restitution for sphere - to end bouncing sooner. 

Sphere disappears quickly AFTER bouncing ends.  It "jumps" thru the semi-transparent ground... near scene origin.

If the original test/PG/demo was run with Oimo AT ALL, then it was tested with small ground.  Sphere fell-off ground before bouncing ended, which "hid" the Oimo issue from the testing person.

Yeah?  No?  Maybe?      I need...  onOimoImpostorJumpObserver.add(function(){ dumpCallStackForWingnutToSee() })    heh.  What function runs... when the mesh jumps?  hmm.

[Guest]

I'm not seeing anything wrong in the ignoreParent code (as it is the same for all plugins)

On a different note, even Cannon is not entirely satisfying and that's why I decided to boost the priority of this feature: https://github.com/BabylonJS/Babylon.js/issues/3079