How can I entirely remove the effects of an impulse

[Herbert]

Hi guys,

I am wondering how I can remove all the effects of an impulse. I made a playground here(https://playground.babylonjs.com/#9T2J6Z)
So there are 2 same boxes, I hit the box1 with the impulse1 first, then I hit both boxes with the impulse2 respectively(I reset position, quaternion, LinearVelocity and angularVelocity before applyImpulse)

I expect them to have same track and final position, but seems box1 still have the effects from impulse1, what else do I need to reset to entirely remove the influence form impulse1?

and I am curious why the LinearVelocity and angularVelocity is not zero when the box stop on the ground from the dropping?

[Wingnut]

Hi Herbert!  I haven't had time to study your playground well, but I did see one issue.

http://doc.babylonjs.com/classes/3.0/physicsimpostor#setangularvelocity-velocity-rarr-void

(Pardon the 'Set the body's linear velocity.' text, there.  Supposed to say 'angular', not 'linear')

ANYway...

setAngularVelocity() requires a vector3, not a quat.  (PG lines 51 and 62) 

That MIGHT make a difference... not sure.  Party on!

[Herbert]

hi @Wingnut
thanks for the reminder,  but I change it to vector3 still the same.
https://playground.babylonjs.com/#9T2J6Z#2

I also reset the physicsBody's velocity and quaternion, still not work.
 

[Wingnut]

Hi again, Herbert.

https://playground.babylonjs.com/#9T2J6Z#3

In that PG, I turned-off gravity.

setTimeout #1 (line 43) - elevates box1, then 2 seconds later, setTimeout #1b applies delayed impulse1 (lines 46-48)

setTimeout #2 (line 52) - elevates box2, then 2 seconds later, setTimeout #2b applies delayed impulse2 (lines 61-63)

setTimeout #3 (line 68) - removes all forces on both boxes, then immediately applies impulse2 to box1 (line 81)

Things are "acting" a little better, eh?

Deduction:  hehe.  Not sure.  It seems we must wait for positioning to finish... before applying impulse.  ALL of your impulses are applied-at mesh.getAbsolutePosition() contact point, so there should NEVER be any rotation.  Any impulse applied at mesh center... should not spin the mesh.  Yet your boxes spin like hell, unless we delay the impulses.  It appears that these two lines...

box.position.copyFrom(startPosition);
box.rotationQuaternion.copyFrom(startQuaternion);
  (same for box2)

... require some time to complete.  It seems... in the earlier PG's... that the impulses happen BEFORE the boxes have established their NEW absolutePosition.  It make no sense at all.  *scratch scratch*   hmm.  Without the impulse-delays, the impulses apply off-center force, causing box spin.

Note:  I changed the direction of impulse2 from -z to +z, just for easy watching.  I also changed line 37, but it didn't fix anything, and I forgot to un-change it. 

I will continue to study and experiment.  Perhaps others will join us and have more ideas.  And, of course Herbert, if YOU have some ideas/thoughts, or discover something via more experiments, we want to hear about them.  This is a very interesting issue.   All of us want to determine why this is happening.  Stay tuned.

[BitOfGold]

I like riddles...
So I made a little logging here:
https://playground.babylonjs.com/#9T2J6Z#7

There are many differences between box and box2.
So if you want the box to land at the same spot, maybe dispose the physics body and make a new one with the same parameters.

 

[Herbert]

Hi Wingnut,

Your deduction make sense to me,  I should've noticed there should be no rotation. And, sure, I will keep testing

btw, is it just me, or the PG is a bit weird these days, the cursor would select on wrong position

[Herbert]

hi @BitOfGold
Creating a new one sounds good, thanks for your suggestion
But now I am also curious about the follow up riddle(why the impulse happens before position set as Wingnut mentioned) 

[Wingnut]

Hi H!  Yeah, the playground is being a bit weird.   There is "gray selection" and "blue selection" in dark theme.  Blue selection is the ACTUAL selection, and gray selection is "other occurrences".

Here's what I see.  If I fast-double-click on the word 'physicsImpostor', then SOME of the occurrences are in gray, and some in blue.

Then just keep clicking-around on some of the occurrences, and the PG app seems-to become confused. 

There's even a LIGHT BLUE selection possible.  I assume that is a blue + gray selection at the same time. 

And there's a LIGHT GRAY selection possible, too.  Not sure what ITS story is. 

I think a new version of the editor was recently installed.  It might take a little time to do some tweaks.  Thanks for the report on that.  I should try to find the docs for this new editor and see what I can learn... and perhaps update the playground tutorial with links to the new docs.

Just a reminder to playground "adjusters":  @JCPalmer made a suggestion a long time ago... to allow access to playground search... AT the playground.  At minimum, we should have a quick-link to the playground search page.  If we want to get fancy, allow the editor to be replaced with a full-powered playground search window.  When opened, it defaults-to "results page from previous search" (for users touring-through a search-results list).  If no previous search, it should be only the input field.  I love Jeff's idea.  We should somehow move forward with it, I think, and if possible.

Yes, we DO have playgrounds-at-the-search-page (playground links and eyeball icons)... but we DON'T have search-at-the-playground-page.    Not sure if plausible, but what-the-heck... still worth mentioning.

[Herbert]

But actually the color does not bother me too much, the incorrect position on the other hand makes it a bit hard to edit.
This pic is what I see after double click physicsImpostor.

[Wingnut]

Yeah, that is certainly incorrect highlight positioning.  I will try to investigate that, too.  You on desktop?  Laptop?  Lesser things?  Which browser?  Same problem in other browsers?

Anyway... I did some more playing on the PG.

https://playground.babylonjs.com/#9T2J6Z#9

One box, one re-positioning, one impulse (after 3 secs).

See value .000005 in line 42?  Yep.  SOMETIMES that is enough delay, sometimes not (on MY puter).  Sometimes box spins, sometimes not.  Weird.  Higher value = less spinning.  But I am still getting occasional spin with .001, so maybe micro-values in setTimeouts... aren't consistent enough to base tests-upon.

*scratch scratch*  :/

[Herbert]

About incorrect highlight positioning, both imac and macbook have this issue.
Yeah I think micro-values are inconsistent, even I set ZERO to setTimeout, it works sometimes.
The point is I think you are right, your experiment proves position's establish has a little delay.
 

[Herbert]

https://playground.babylonjs.com/#9T2J6Z#10
So If I don't want to delay the impulse, I have to manually update physicsBody's value.

[Wingnut]

Perhaps that simply takes more time... the same as a delay?   hmm.

uhn... https://playground.babylonjs.com/#9T2J6Z#11

(back to old way, but...)

Look at line 40.  physicsImpostor.forceUpdate();

Seems to work.  No need for line 42 timer.  I got 10 good RUN's without any tumbling mesh.

BUT... impostor.forceUpdate()...  calls impostor._init()... which removes previous impostor and installs new one.  That is precisely what @BitOfGold suggested we try.  heh.   But I sort-of like your #10 piece-by-piece value-installer, too.    It is an interesting (yet still puzzling) solution.

I think it's time for drugs, now. 

[Herbert]

I like forceUpdate~ I'll go for it,
https://playground.babylonjs.com/#9T2J6Z#12
since it recreate an impostor, I don't need to worry about init velocity,  quaternion and other stuff .
However, in my case, I want these two boxes not colliding to each other,  so I still need to reset collisionFilter after forceUpdate.
Still, it's better than my piece-by-piece setting

In case anyone else is interesting in this, I will put on the solved tag a few days later

[Wingnut]

Very nice!   I'm still curious as to WHY the physicsImpostor is slow to "catch-up-with" the force-positioned boxes.

https://playground.babylonjs.com/#9T2J6Z#14

  This time, instead of mesh.getAbsolutePosition() for impulse contact point, I use mesh.physicsImpostor.physicsBody.position.  I impulse the impostor's center, not the mesh's center.  Interesting results.

I also changed the position/rotation init lines (47/48 and 61/62) from copyFrom to clone.  No symptom changes seen... from that.

I have 5 console logs just before each impulse.  I am trying to "watch" IF/NOT the impostors are still increasing altitude (rising) when the impulses fire. 

Highlight the console log lines, then use the handy control-slash to activate them... and watch console.  The impostors show NO RISING during the 5 console logs.  The numbers in all 5 console logs... are the same.  The impulses fire when the impostors are about .000998 off-the-ground, according to the numbers.  The impulses shouldn't happen before the impostors hit a height of 20.  Strange.  Even my dog is scratching his beard.