I created a PhysicsImpostor on my players mesh. However I am forced to use BoxImpostor as the MeshImpostor only works on other sphere meshes. It overall works okay in terms of walking through terrain. However, a current issue is if I walk my players mesh against a wall, it will bounce back and fall over like a box. I would like to keep my players mesh always upright and standing like a person. How can I make this happen with PhysicsImpostor? I am creating a 3rd person RPG essentially, imagine my character has collision like a box and if it interacts with a building it will bounce back and fall like a box. I want the collision to work like a traditional player RPG.
Pinging @trevordev
Hey @Abstract,
The discussion here is related: Stop Sliding down Slopes (SSS)
“However I am forced to use BoxImpostor as the MeshImpostor only works on other sphere meshes.”
Does a cylinder impostor not work?
“if I walk my players mesh against a wall, it will bounce back and fall over like a box. I would like to keep my players mesh always upright and standing like a person.”
I might try to add an scene.onBeforeRenderObservable and update you player to the desired orientation every frame but I havn’t investigated too much into getting something like this to work before.
Another option is to try avoiding a physics engine for the player and use the simpler collision logic Babylon provides: https://playground.babylonjs.com/#U8MEB0#0
Hey @Wingnut I need help with this issue too! I’m making a multiplayer FPS game and when my players (cylinder meshes) collide they keep falling down.
Hiya S, welcome back to the forum. Sorry to hear you are having tip-over issues.
Um… why did you ping me? I was not involved in this thread at all. 
But yes, I have done SOME work in other threads, related to this.
Just like ALL moving physics-active mass-set bodies with tip-over tendencies (boats, trucks, airplanes, humans, wind-blown towers, etc)… CG (center of gravity) is the key. Keep the CG at a low altitude, and the player will remain upright. (lower-value’d move-forces, impact-restitution, ground-friction… helps, too. We’ll talk more about these, below.)
“Weebles wobble but they don’t fall down.” [ YouTube ] Why? Low-altitude (low-height) CG.
SO, you should/could… make your player be a compound physics object. Create a heavy and possibly-invisible “base”, and then parent an upper body… onto that. Keep the CG… real low… near or UPON the floor. Reduce friction(s) to keep its heavy masses moving nicely, and use low movement “thrust” impulses/forces (and low bounce restitution).
Apply those lateral thrust forces… LOW ALTITUDE as well… near the ground/floor. Perhaps, to allow you to set friction VERY LOW (and thus thrust and wall-impact-forces can stay low-powered)… use linear damping to slow-down/stop a moving player, and NOT friction values (braking).
High-value ground->player friction values… are no good. Friction helps things tip-over. Conversely, using linear damping for your player brakes… will help eliminate tip-overs.
Here is a linearDamping method that we call “Raanan’s Leather Boot” (@RaananW showed it to us, long ago, and it is similar to “scrub brakes” used on bicycles with no brakes… push your boots against the ground to stop.)
playerBase.physicsImpostor.setLinearVelocity(playerBase.physicsImpostor.getLinearVelocity().scale(.95))
That line is put into the renderLoop… and performed constantly, even if the player is not moving (should be no significant performance loss by doing it constantly, but you MIGHT with to wrap-it into an IF/THEN, somehow) (yet still inside renderLoop).
Adjust the .95 value, as wanted. The nearer to .999999, the less brakes you get. And again, reduce ground-to-playerBase friction as low as possible, and thus keep move-the-player applyForce()/applyImpulse() LOW-POWERED, too. And, keep player and wall restitution (bounce)… low-valued, as well. (have I repeated this enough, yet)
Often… players tip-over… because of over-powering everything… friction, restitution, move-forces, etc. Many times, game programmers DO THIS… because they want their gameplay to be fast-moving and exciting But we are working-in JS land… so there are SOME speed/perf limitations that we must deal-with, and high-forces on the player physics… is NOT a good solve for that.
Ok, I hope I have been helpful. When building compound physics shapes (made from multi-mesh - parented together)… there is a proper “order of sequences”. Um… I can’t remember what it is. I think it is…
- create parent (player base?)
- set its impostor/physics
- create upper torso
- set upper torso parent to be player base
- set upper torso physics (which will go check if upper torso has parent, and do extra stuff)
I THINK that is the order. Experiment as need, and perhaps others are nearby that can verify the order.
I want to show you one OTHER TYPE of physics-mover system… which was taught to us by @fenomas, I believe… or maybe @adam, or maybe both…
https://www.babylonjs-playground.com/#15AFCG#30
Use cursor arrows. The little box (later to be set invisible)… is driven by physics forces from the arrow keys. It has a physics joint… that attaches it (downward) to the green player. It allows a bit of “flex” between the little-box move-forces… and the ACTUAL player. This was done… because… a keypress has a LOT of physics force.
Example… navigate the green box until it collides with the red box. Do some more bumping. IF we DIDN’T have that somewhat-flexible joint-connection between little box and green box… a tiny collide of greenbox-to-redbox… would send the redbox flying OUT OF SCENE. The keypress has LOTS of physics power, by default. We must “soften” the keypress by installing some flex (built-into physics joints)… to keep the “wall bump impact”… gentle.
This system might ALSO help you, @sahilnare. Give it a test-drive in your game, perhaps.
Here’s some other WASD and arrow-key physics-nav playgrounds that I have bookmarks-for…
https://playground.babylonjs.com/#15AFCG#9
https://www.babylonjs-playground.com/#U4F9K1
https://www.babylonjs-playground.com/#IFN77Q#17
https://www.babylonjs-playground.com/#IFN77Q#23
Keep in mind that there may be higher “fragment identifier versions” or those playground series. In other words… https://playground.babylonjs.com/#15AFCG#150 <= version #150 or even higher… MIGHT be available in THAT series of playgrounds. Other programmers may have advanced that series of playground… AFTER I bookmarked early version #9… years ago.
There, how’s that for a big fat reply/comment? Tumor-causer, huh? Party on!
5 Likes
Thanks! I pinged you because you help a lot on the forum.
So I made the height of the cylinder imposters small and increased its mass and it’s wobbling considerably less now.
I was not going to use the physics engine and instead use the default checkCollisions method but I needed the characters to jump so I used the CannonJS engine.
I was also having problems with rotationQuaternion since rotation is not used with physics imposters but it’s been solved now.
Anyway thanks for the help!
1 Like
I fixed my “falling down” stuff using player.physicsImpostor.physicsBody.angularDamping = 1;
You won’t find that property in babylonjs docs because it’s Canonjs related stuff, but Cannonjs docs also very terse, if we talk polite: canonjs docs about angularDamping property 