Physics HeightmapImpostor not working

[satguru]

BABYLON.PhysicsImpostor.HeightmapImpostor doesn't seem to be working properly.

See this PG

https://www.babylonjs-playground.com/#97B3B7#7

Here I am dropping a box to the ground.

The box drops, halts below the ground, turns and continues dropping below the ground

[Raggar]

Have you had a look at this thread: 

?

[satguru]

@Raggar, Yes seems related

[satguru]

@Raggar, @Wingnut, @Deltakosh, @RaananW

Found something else.

I noticed in @Wingnut original example https://www.babylonjs-playground.com/#1RKZXB#45  all boxes with box/sphere imposters had some rotational/linear velocity when they were created.

In my example they did not.

I then noticed that I was setting friction and restitution parameters differently from @Wingnut

I was setting them using the setParam() method whereas @Wingnut was setting them in the constructor.

I rewrote @Wingnut example redoing the way the params are set.

see

https://www.babylonjs-playground.com/#1RKZXB#72

notice lines 37-42.

Works as expected.

So the constructor stuff needs to be looked into.

Of course the problem of box sinking into the ground, as shown by my example, still needs to be looked into.

 

[satguru]

found a fix for my issue

I was doing "grnd.freezeWorldMatrix();" before creating the HeightmapImpostor

Moving that after creating the HeightmapImpostor fixed the issue

see

https://www.babylonjs-playground.com/#97B3B7#9

notice lines 44 and 49.

As an aside I should have created box after creating ground but it works anyway for this example, so ok

 

 

 

[Wingnut]

41 minutes ago, satguru said:

I noticed in @Wingnut original example https://www.babylonjs-playground.com/#1RKZXB#45  all boxes with box/sphere imposters had some rotational/linear velocity when they were created.

Hi SG.  I think the "explode" that happened in that playground (which I didn't code)... was because the user spawned many physics active boxes in the same place, overlapping each other.  I never bothered fixing that.  I was working on different issues. 

Two issues I worked-on... were the "mud" (sinking into ground), and the other issue was... boxes coming to rest on their edges (not laying flat when coming to rest).  Your #72 playground still has both of those symptoms.  (But hey, thanks for fixing the exploding launcher.  Your launch is must nicer.)

The reason was found... for the sinking and edge-laying.  Don't convert ground to flatshaded... before setting physics impostor.  Just reverse the order of lines 67 and 69, and the #72 playground looks pretty good. (I'll let you experiment with that, but in my quick tests, it fixed it).

Lately, there has been some proposals for offering another method for doing BJS flat shading.  There is talk of doing it with post-processing.

Lastly, there was one other issue seen.  Just forum search for 6162.    It involves the cannonJSplugin .executeStep function.  When that little function is included into the playground, CannonJS scenes run much faster.  That is still being pondered... and has not been solved.  We'll talk. 

[satguru]

4 minutes ago, Wingnut said:

Hi SG.  I think the "explode" that happened in that playground (which I didn't code)... was because the user spawned many physics active boxes in the same place, overlapping each other.  I never bothered fixing that.  I was working on different issues.

Don't think the "explode" was because of overlap. Even with 1 box you have the same issue. 

Has to do with the way parms are set.

uncomment line 37 and comment out lines 39 to 42 and you will see that the explode happens again.

Yes, I see your point about flatshaded.

 

[Wingnut]

2 minutes ago, satguru said:

uncomment line 37 and comment out lines 39 to 42 and you will see that the explode happens again.

Ahh, look at that.  INTERESTING!  Good find, SG!

hmm  *beard scratch*.  What the heck?   

[Wingnut]

Ahhh, ok, I found the problem.

We were setting box positions AFTER setting physicsImpostors.

https://www.babylonjs-playground.com/#1RKZXB#75

Here I set positions in 38-40, and then use constructor-set params in line 42.  Also reversed the flat shaded/ground-impostor lines.

Works pretty gooood.

Still, the success seen via 'late' parameter-setting... is interesting, and worth investigating.

I didn't think there was a problem with constructor-set parameters, because SO MANY other physics playgrounds are using it successfully.

Learning learning learning.  Maybe someday, we can update docs... once we learn how everything works. 

Update:  Just for fun, I moved that CannonJSplugin .executeStep into top of version #76 playground.  No difference in speed seen... between #75 and #76.  Interesting!  That would indicate that things we discovered today... have affected the .executeStep issue, too.  So many things... seem interconnected, here.

[satguru]

@Wingnut

You are right.

Setting position of a mesh after adding phyiscsimposter creates an issue.

So in the following example (cleaned up a little bit)

https://www.babylonjs-playground.com/#1RKZXB#78

if we comment out line 3 and uncomment in line 12, we see the issue.

But if instead of constructor, were we to use setParam() to set the parms then setting the position before or after does not matter.

So using setParam() seems to be a  better approach for now