Cannon JS and overtuning model

[TomaszFurca]

Hi, some time ago I enable physics in my game, I choose cannonJS. 

1. First problem is with overturning model. When player model collision with somethink other model, it overtuning on below ground, but not fall down in space. Fall down only when i move outside ground - its OK

look at http://babylon.furcatomasz.pl

2. What you mean about moving character. Now i using translate function? What is better choice translate or applyImpulse? 

 

Tom Furca

 

[Wingnut]

Hi Tom.  Very strange physics, eh?  Tommy Tipover.    

Beautiful scene/game, nicely done.

Could I ask questions...

1.  Where does player get physics added?  Inside Simple.js...

else {
    shadowGenerator.getShadowMap().renderList.push(sceneMesh);
    sceneMesh.physicsImpostor = new BABYLON.PhysicsImpostor(sceneMesh, BABYLON.PhysicsImpostor.BoxImpostor, { mass: 0, restitution: 0.1 }, scene);
}

... or somewhere else?

2.  Does player sword have physics, too?  Could it have high mass, and tip-over player sometimes?

3.  Is there ANY "tip-over-the-player" animation installed, and could it be accidentally running?

We HAVE seen SOME problems in newest BJS... with physics.  Well, I have seen some.    Others have not yet verified/validated what I am seeing (in my tests in another thread). 

In MY opinion, there was some change in boundingBoxes (for newest BJS)... that might be causing problems. 

We I have been studying/investigating how/why, but I am not a good programmer for framework-level issues (I am slow, and weak-brained in matrix transformations, used heavily in calculating bounding boxes).  Sorry you are having problems.  Opinion... use BJS 2.5 for now... see if that helps.

[TomaszFurca]

So I load characters to cache (variable in game object) and after connect any player i clone loaded mesh. After clone mesh, it got physics impostor usign this code:

mesh.physicsImpostor = new BABYLON.PhysicsImpostor(mesh, BABYLON.PhysicsImpostor.CylinderImpostor, { mass:80, friction:0.01, restitution:1}, game.scene);

sword have impostor too:

sword.physicsImpostor = new BABYLON.PhysicsImpostor(sword, BABYLON.PhysicsImpostor.BoxImpostor, { mass: 0, restitution: 0 }, this.game.scene);
        

Already I work on BJS 2.5. Next example is barrels, when you collide with barrel it falls down below ground, but no fall down in space, only fall down in space when go to outside ground.

Barrel Impostor: 

sceneMesh.physicsImpostor = new BABYLON.PhysicsImpostor(sceneMesh, BABYLON.PhysicsImpostor.CylinderImpostor, { mass:0.2, restitution:0 }, scene);
                        

 

[Wingnut]

Ok, thanks for info... well done.  Yeah, you have "muddy" ground.  Impostors "sink" a little bit.   

I know what you mean.  Thx for report.  Let's ping @RaananW, our physics God.  But I think he is already aware of this issue, and I am also working-on a similar issue... for latest BJS/Cannon heightmapImpostors.

Let's also ping @Dad72.  He has AT LEAST shown interest in this issue, and he's an excellent coder/thinker.  (Thx for any ideas you might have, Dad72, or ANYONE.)  Raggar has also shown interest, though.  He LIKES my "lost programmer" tests in the Wingnut Chronicles thread, anyway.    I'll take all the encouragement I can get... thx Raggar. 

I believe some changes in BJS 3.0 preview... boundingBox class... is causing the problem, but I am still trying to test things.  (I am junior-grade coder, though... and big dog coders are busy right now, it seems.)  I am having a very difficult time gathering a "team of helpers" for this issue... and the boundingBox-related bug reports from users are increasing daily.

Can you stay with BJS 2.5 for now?  I think that would be wise... until we (all) learn more.  thx.

[Dad72]

I'm not sure, but try the restitution has 0001 instead of 0. I think the physics is not a fan of the values 0.

Do you have a PG who reproduce it ?

[Wingnut]

I made one, D.  http://www.babylonjs-playground.com/#1RKZXB#44

Just a simple tester of box, sphere, and cylinder impostors.  It looks fine, but for me, it starts in "slow motion mode", in IE or FF.

If I change to playground #31... things go faster.  Then change back to #44, and IT is faster, too.  Strange.

But, I don't see sinking or tip-over.

Did you try his game, Dad?  WASD... best used with repeated-tapping of keys.  Held keys have pause-before-repeating.  Fast-tapping better.

His player sometimes tips-over, his barrels sometimes tip over or act strange, and there is some sink-into-ground.  Works fine in 2.5.

I have been fighting similar problem with Cannon heightMaps... in The Wingnut Chronicles... but perhaps not pertinent.

Again, I see no problems in my little demo here, except slow motion issue.  Cylinders act okay... so do other impostors.  hmm.

[TomaszFurca]

@Wingnut What you think about muddy ground?

@Dad72 Yes, but only on my server, because i using type script, socket IO  - http://babylon.furcatomasz.pl - move your player (WASD) to fireplace. Hold W and after some time player fall down below ground.

[Wingnut]

16 minutes ago, TomaszFurca said:

What you think about muddy ground?

  I think something is broken.  I think, for SOME reason, ground impostor is too tall.  Same with barrels and player... impostors not same size as mesh (possible boundingBox issue)

@Dad72 Did you see where Deltakosh removed one line from boundingBox...  this line...

https://github.com/BabylonJS/Babylon.js/commit/2b6bd17eaaa5cecc04846d024156ae4d45974c9f#diff-41ae912076ef4fd19635291ed24630a8L86

this.center.scaleInPlace(0.5);  removed.

Maybe ok, maybe not. Perhaps physics plugin USES boundingInfo.boundingBox.center?  But now it is NOT .scale(0.5) anymore.  Thoughts, anyone?  Thx!

[Dad72]

There may be a bug as you said with big impostors. Should be displayed to see if it is.

If this bug is reproduced on a PG, it will be easily corrected by Deltakosh or RaananW

[Wingnut]

"easily".    (Wingy hugs Dad72, and isn't even sure WHY)

Here's heightMap demo #43  (maybe not apropos, because Tom's scene uses box impostor for ground)

But... for me... #43 only has physics in 1/4 of terrain (which is "muddy"), 3/4 of terrain is pure fall-thru, and scene is in slow-motion speed .

Now look at #32  Fast-mode again?  For me, sometimes.

Still slow-mo?  Try #31, it NEVER fails to go into fast-mode.  (ignore green ghost box)

In fast mode, yet?  If so, change end of url to #43 again, hit enter.

Fast mode on #44?  No fall thru or mud?  Anyone else seeing this, or something similar?  (Wing pulls some hair out)

 

#32 contains the mod I PR'd, that you commented-on, Dad.

But then, my mod failed the rectangle test.  My imposter alignment mod worked fine... but ONLY on square grounds.

So, I closed/cancelled the PR.  Wingy didn't test well enough... and went back to work, and then went off on the boundingBox tangent, and left the phsyics plugin alone. 

Exciting story, eh?  (snorrrrrrre) 

[TomaszFurca]

I don't understand what i can do in my code...

I change impostor on my ground to BABYLON.PhysicsImpostor.HeightmapImpostor. After change, every mesh with physics impostor fall down in space, do not stay on ground. 

When i create mesh "ibox" from your code character stay on ibox mesh, but i didn't add impostor to ibox. If mesh like barrel stay on ibox mesh, it flood into ibox, like earlier on scene ground with physics impostor box.

How to divide my ground to smaller impostors/boundingBoxes like heightmap?

 

 

 

[Raggar]

For the time being, I've chosen to use simple shapes instead of heightfields. This might be a option for you, too.

I know it would be a lot easier to use either a map or a mesh, but I think the performance is better this way. Only speculations, though.

[Wingnut]

Tom, that iBox was just an attempt by me... to make impostor visible (by trying to make green ibox match heightmapImpostor position/rotation).  I failed at that, so far.  You should turn-off that green ibox forever, it was for Wingnut's testing.    It was never meant to be active physics object.  Just a ghost mesh to attempt to see how the heightmapImpostor was positioned and rotated.

Tom, have you decided NOT to use BJS 2.5, then?  I suggest staying with 2.5 if it works.  3.0 is alpha, and it has problems or something.  I don't know if I am smart enough to find them... yet.

Raggar, I think Tom's game currently uses a box impostor for its ground.  It is a simple shape already, yes?  *shrug*   Maybe I didn't understand correctly, and maybe you were commenting about Tom's last post. 

Thx for your input... definitely!  We'll take all the ideas we can get.

[TomaszFurca]

I using BJS 2.5. In 3.0 my scene is displayed in 50%.

I decided to disable physics right now, because i spent a lot of time without success result, but i have a lot of other stuff to do in my game - maybe back later to use physics.

[Wingnut]

2 hours ago, TomaszFurca said:

In 3.0 my scene is displayed in 50%.

Hi Tom.  Could you please start new Q&A thread... and talk about that?  That would be great.  Include many details, if possible.   Thx.

Also, would you please start new Q&A thread with most-of your last post.. in it?  Perhaps leave first two lines.. about not using physics - ok.  But move MOST OF post to a new thread.. maybe titled "Questions about MoveWithCollisions" ?  That would be great.  This really helps forum helpers.

For THIS thread... I would like to stay on PHYSICS subject because it is unsolved.  I want to keep talking about CannonJS physics (here)... so others can keep thinking about problem.  Understand?

I know... lots of work for you, sorry... but... we want to do great problem solving.  If you start two new threads... #1 about 50% problem, and #2 about moveWithCollisions, that would be great.  (and you can edit last post and remove moveWithCollisions stuff, if you wish).

I will pay attention to this thread and both new threads... I promise.    thx!

Can you please keep  http://babylon.furcatomasz.pl  working the same... for a month or 2 or 6?    Probably not, huh?  We would like to have a URL to see your issue.  Can you give us a new URL for COPY OF same scene?  That would be fine.  ( maybe http://babylon.furcatomasz.pl/brokenphyz/ ).  I want more time for others to see issue (if possible).   thx agn.

 

[TomaszFurca]

Okey - new topic is created.

Tomorrow i will create new instance in new subdomain of my babylon game for your tests. It will be avaiable for long time, for time when you check it. After do that, I will change all URLs in this topic.

This is topic about moveWithCollisions 

 

[fenomas]

Hey, it looks like your two questions never really got answered:

1. You can prevent physics bodies from rotating with:

player.physicsImpostor.physicsBody.fixedRotation = true

That's usually what you want for things like player characters.

2. Manually translating (moving) things in a physics simulation usually breaks the simulation. The best two options for moving characters around are:

1. Applying impulses or forces to the player body
2. Attach the player body to another (invisible, non-colliding) body with a joint (like a spring or a distance joint), and then move the invisible body around manually (by changing it's position values)

They each have somewhat different results, but it depends what you want. 

I don't know what's going on with your other issues, as most of the links in the thread seem not to work, but anything that you can reproduce in a playground link should be easy to address.

[Wingnut]

On 5/15/2017 at 5:27 AM, TomaszFurca said:

Already I work on BJS 2.5.

Somehow I misunderstood that as... "Already works in 2.5".  hehe.  Serious Wingnut confusion on that, sorry guys.

@fenomas the only pertinent demo is http://babylon.furcatomasz.pl/

WASD keys to walk player into barrels. Barrels roll-over like sphereImpostors with low-set pivotPoints.  And, they sink into ground.

I didn't ask Tom if he has adjusted any pivotPoints on the barrels, and I never searched the code for that.  His barrels use cylinderImpostors, ground is boxImpostor, and player is... I forget.

Tom is changing to non-physics and is creating a new URL for physics demo... soon.  I tried a basic playground... but could not repro issue with it.  Cylinder impostors acting well, there.

[TomaszFurca]

Today i spent all day for testing collisions and physics. I change my character mesh to box and box don't fall down below ground, so i think this is problem with models or babylon exporter.

For moving character i create invisible box which is parent of character mesh

let mesh = game.characters['player'].clone();
        let skeleton = game.characters['player'].skeleton.clone();
        let material = game.characters['player'].material.clone();        
let mainMesh = BABYLON.MeshBuilder.CreateBox(id+name, { width: 0.5, size: 0.7}, game.scene);

        mesh.visibility = true;
        mesh.skeleton = skeleton;
        mesh.material = material;
        mesh.parent = mainMesh;
        mesh.position = new BABYLON.Vector3(0, -0.4, -0.3);
        mainMesh.position = new BABYLON.Vector3(3, 7.1, 0);
        mainMesh.visibility = false;
        mainMesh.physicsImpostor = new BABYLON.PhysicsImpostor(mainMesh, BABYLON.PhysicsImpostor.BoxImpostor, { mass:1, friction:0.01, restitution:0.2}, game.scene);

Now my models do not fall down below ground, but i must write a lot of code, this is not useful. I must create this hack for every physics object, which have mass greater than 0.

I near future i will work with models to resolve problem, after any updates, give any response.

[Wingnut]

Hi Tom, thanks for good investigation and report.  Good info... but...

... you had boxImpostor on player, yes?  That should be fine.  But maybe it was too thin and too tall, in some way.  More mass needed?  *shrug*

BoxImpostor should AUTOMATICALLY avoid tip-over because of flat bottom.  Perhaps too tall and too small X & Z.  Like un-sharpened pencil.. not enough flat area?  Perhaps too much restitution power (rebound power) on player or on collided things?  Not sure.  Just thinking.

Did you try Fenomas' idea... player.physicsImpostor.physicsBody.fixedRotation = true;  ??  Perhaps you could not turn your player anymore. 

Your situation might require physics rotational "constraints" on X and Z rotation... but still allow Y rotation, for player turning.  I think that can be done... but not sure how... at this time.  (well, I know 2 bad renderLoop ways:  1. constantly set physicsBody.angularVelocity.x = 0 and .z = 0, or constantly set physicsBody.quaternion in some way.  Pure force. heh.)

Perhaps invisible box mesh with boxImpostor and fixedRotation... positioned above player's head.  Then physicsJoint connected downward into player's head, and that joint would ONLY allow Y rotation, and have constrained X and Z rotation.  I think that would work... somehow.   

Fenomas taught me... that there are MANY advantages in using a physicsJoint to connect the thing you are FORCE-moving with keypresses (the invisible box above player's head)... to the moved-by-impostor mesh.  You could consider it a "soft connection".  It has some "flex" that you can highly limit/constrain... but not stop completely.  It also allows springs and motors.  hmm. 

This "use-a-joint method"... is physics-engine-friendly.  It allows the physics engine to do its math, and better stay in-sync with its impostors.  (I hope I worded that tolerably, heh)  Talk soon.

[Raggar]

@Wingnut

I was talking about the post just before mine, yeah.

Cannon.js has some issues when it comes to heightfields, (Especially) when run on Node.js. I tried a heightmap as well as data pulled from a 3D model. It's just too unstable on Node.js, unfortunately. At least when using vehicles. It's not that bad with normal bodies and velocities.

So instead of using a heightfield, I use boxes and spheres to recreate the physics-bodies of the terrain. This is a slow and tedious task, but it's better than having your bodies fall through your heightfield. Why it is like that, I have no idea. I'm not smart enough to investigate

[Wingnut]

Me not smart enough, either. 

I think it is a boundingBox issue... but I've said this a few hundred times before.  It is FAR-reaching... affects physics, affects the collision ellipsoid issue that I'm wrangling... it's a big and important bug/issue.

None of the big dogs seem to be losing any sleep over it, which I totally don't understand.  Even the little guys should be "on this", right now... but it seems few care.

As you know, the people sitting around this campfire... none of us have our "Class-A Pyro-Technics license" and so... we stir the fire with our sticks... fairly aimlessly.  heh. 

We're just stirring and staring and drooling in fascination... with the campfire.  There is a type of mesmerization that happens... when campfires are stared-at.  Sometimes there is more drinkin' than thinkin' 

My best skill is in building playgrounds that test/prove stuff.  What to do after something is proved... well... that scares the hell out of me.  I could make a mistake that would burn down Babylon. 

[Raggar]

What weirds me out is the fact that the very first model I tried out, worked. I created it in 3Ds Max, but it didn't work properly before I imported the .obj model into clara.io and exported to .babylon. I believe they use the blender exporter. If only I had saved that model, I could simply edit it as it already had the right scale and position.

Maybe changing the offset of the shape would work better than positioning the heightfield itself.

The reason I'm not investigating this issue myself, apart from being grossly incompetent, is because I'm currently playing around with a racing game, and according to SO and Github, vehicles have many issues with heightfields.

There are functions to find the height of the points/faces, and then keep the body over that y-position, but I believe this will create more issues with the vehicle mechanics.

I tried Many of the previous versions of Babylon, with the same results.

 

[Wingnut]

Hi again.  Much of that... is good info... thanks for sharing it.  That might help locate the problem... cool.

I have had SOME luck... with standard heightMaps... but using the Cannon MeshImpostor and not the heightmapImpostor.

http://www.babylonjs-playground.com/index2_5.html#1YOCO9#40

Occasional fall-throughs, but still much better than current heightMap impostors.  *shrug*

Rumor has it that MeshImpostors ONLY interact with spheres, but I think I saw a boxImpostor interact with a meshImpostor, a couple weeks ago.  My mind has been a bit blurry, lately, but I think I got a decent bag of weed this time, and that might be causing it. 

One thing to note... car tires are spheres, or at least CAN be (scaled narrow).  So, if a guy was to build a 4-wheel soap box derby car, it MIGHT roll down that bumpy meshImpostor hill just fine.  Perhaps worth a try.  If you try it, tell us about your discoveries, if you have some.  Thx.

I have still seen some "start in slow motion" physics demos in BJS 3.0.  They seem to run faster... in BJS 2.5.  If you DO get a slow-motion demo start... you can browse to http://www.babylonjs-playground.com/#1RKZXB#32

THEN change the URL back-to the slow-motion demo, and it should run faster.  Not sure what the story is, there.  One of MANY sticks in our campfire. 

That #32 demo above... works pretty good, eh?  It uses a "Wingnut-hacked" CannonJS plugin _updatePhysicsBodyTransformation().  The terrain MUST be square.  Rectangular... has many problems. 

Oh yeah, if #32 doesn't "speed you up",  http://www.babylonjs-playground.com/#1RKZXB#31 will work. #31 has never failed me... for speed-up.  Go fig.  #31 has a LOT of code from the physics system... hijacked into the playground.  #32 has ONLY the "affected code" that I did hacking-on.  Until moments ago, I thought #32 ALWAYS started at proper speed... but... moments ago... it started in slow-mo-mode. 

Could be my computer, but it is not a browser-based issue.  Slo-mo mode happens in IE, too.  Raggar/anyone... if you DO see a "slow-mode" and "fast-mode"... could you verify it to me?  Thx.  It could be my computer.  FPS stays same... no matter fast mode or slow mode... on my computer.  And that #31 playground ALWAYS starts in fast mode... for me.  Love it.  Ignore/remove the green box overlaid on the terrain... it's just there for testing.

Anyway, meshImpostor might be useful for ya... until other things get fixed.  Party on!

[TomaszFurca]

Hi, after some tests we have small report.

When origin of the mesh is center of the mass, then animation is wrong, but collisions are correct. You can check it on video:

https://drive.google.com/open?id=0B9VobXUUD7rhQ3JzYVNaM2prd1E

Also check scrennshot from bledner:

https://z78i.imgup.net/18789217_18e2a.jpg

 

From the beginning of this topic we set the origin to zero position (location), check on screenshot

https://y02i.imgup.net/18745199_1ff15.jpg

additionally i record video

https://drive.google.com/open?id=0B9VobXUUD7rhTHdvZnhoYUJLSHM