solved PhysicsImpostor on loaded meshes cause error

[yLacaute]

Hi,

I am trying to load the Dude.babylon, set its position and enable physic engine in order to he collides with the ground.
It is almost working : https://www.babylonjs-playground.com/index.html#YYQ1LC#35
I tried different way of loading and it change nothing.

I have some problems :

• As soon as I add the physicImpostor, I have an error message in the console, even if the dude is loaded and displayed  :
  BJS - [18:05:26]: Unable to import meshes from Scenes/Dude/Dude.babylon: Error in onSuccess callback
• As soon as I add the physicImpostor, positionning start to bug (every character are in the same place)
• Finaly, I have to use MeshImpostor and I would like to simplify collision with a box, but replacing MeshImpostor by  BoxImpostor doesn't work, why ? How to not use MeshImpostor ? (I tryed to create parent mesh but without success)

Thanks
 

[Wingnut]

Hiya yLacaute, welcome to the forum.

   Well, first of all, you are trying to put physics on a fairly complex mesh, or should I say... GROUP of meshes.  The Dude model is 6 meshes total (a root and 5 real substantial partners).

And, it's animated, and physics engines don't really like animation, unless physics forces do the animating.

So, what we really need to do... is stop the animations, and merge the meshes, and then try some boxImpostors.

You'll notice that I also "force-in" some try/catch code-blocks.... to help us find any errors that might be happening in either of the loaders onSuccess areas.

These try/catch error checkers... reported to me that you had tried to put a physics impostor on a mesh that had no shape... no size... no substance.  (newMeshes[0] and task.loadedMeshes[0])  Both of those are "root" meshes, I believe.  Essentially, a "gizmo" or "master parent" to control the model.  Sometimes, a 'root' is a blank mesh, and the physics engine doesn't like adding impostors to those.  These try/catch blocks reported that problem... something like "no shape was found".

You can do more testing as needed.

https://www.babylonjs-playground.com/#YYQ1LC#38

Both our dudes now have their meshes merged (line 15 area and line 75 area).  Merging meshes always makes the multiple-materials... turn into a single material.  It also hurts the chances for turning-ON the animation again.  But physics engines are picky and particular.  Physics engines want "ragdolls" for human-like characters... with "physics joints" at each place of animation pivoting. 

Extra crap:

Believe it or not, I have NEVER seen anyone... "walk" a completely physics-enabled skeleton armature... using applied physics forces.  Not even in the most advanced games or defense department battlefield/combat sims (like I've ever seen DOD hand-to-hand combat sims) :).  Generally, when classic animation is used on a skeleton, movement transformations are forced, no matter the friction, gravity, restitution, or applied physics forces.  Physics impostors are often reluctant to being forced-around by anything except "approved" physics forces.

Here is a playground where we used a "proxy" object (the small gray ibox) to "physics-move" the green player box.  A physics joint is attached between the little gray ibox, and the green player box.  You may use arrow keys to force-move the gray ibox.  The forces are transferred thru the joint... to the green player box.  This "joint between manual-forcing-and-physics-impostor" method... seems to work pretty well.  At least the green player box isn't flying off into space after collisions with other boxes/impostors.  It is quite common for physics-active things... to get out-of-control, sometimes.  Out--of-control is the LAST THING you want for a player-controlled character.  So, this "connector joint" between the arrow keys... and the green player... works pretty well... as a "buffer zone".  We can make forceful/powerful arrow key moves, but those abrupt movements are "softened" by the joint... so that green box never flies off into space after a violent arrow-key collision with something. 

Generally, when physics impostors are added to mesh, the physics engine wants to be in total control of all movements  (but programmer is allowed to do setLinearVelocity, setAngularVelocity, applyForce, applyImpulse).  For a physics engine to simulate "real" physics forces, it needs to calculate its friction, gravity, restitution, mass, and applied forces... or else the movement won't look/act real.

@TomaszFurca showed us a pretty nice game world, recently.  http://babylon.furcatomasz.pl/

Good nav, good animation, good gfx, NO physics engine.  The rocks and trees... you can walk right thru them... but there is a broken wagon in his scene... that you cannot walk thru.  It has a different type of collision sensing (non-physics engine).  Sure, our player can't kick-around the broken pieces of the wagon, but it is STILL pretty good.

Perhaps you can have some fun with the physics engines... WITHOUT trying an animated multiple-mesh model.  To be frank, I don't think ANYONE has completed a completely-forces-driven, fully-jointed, walking/running/jumping/crouching/turning physics ragdoll, yet.  Most people who have tried it... are in insane asylums, now.    (just kidding).

More info:  Gruesome thread:  http://www.html5gamedevs.com/topic/32958-physics-movement/

Maybe:  http://www.html5gamedevs.com/topic/32052-terrain-slope-problem/

A person named @Mythros wanted a standard animated nav-able character like we see in Tomasz Furca's gameworld, but he/she wanted it to slide down certain steep terrain slopes (as well as struggle to climb them).  I think it was @Raggar that showed Mythros some basic up/down ramp-sliding... but NOT using a physics engine.  Instead, measuring angle of face-normal of terrain/ramp beneath player... to determine if ramp was angled enough to make player slide/struggle-to-climb.  Gruesome.  (I can't find that playground, yet.)

Player avatars and physics engines.  Yikes.  They have never played-together well.  @Raggar once took us on a fun journey... http://www.html5gamedevs.com/topic/29464-ways-to-achieve-ragdoll-effect-using-cannonjs/?tab=comments#comment-180514

Okay, this is probably WAY more than you wanted to know.  Welcome to physics engines, the funnest method EVER... to go crazy.    Others may comment soon.  I hope I have been helpful and not said anything incorrect.  Party on.

[yLacaute]

Great answer, thank you !

I am discovering BabylonJS without experience in physic engine, so your advice is really appreciated   I am trying to create a FPS, "like Quake3" (open source, fast, with jump, and maybe I am too ambitious, but also multiplayer). First, I had a moving character without physic engine, It was ok until I want to jump

• jump  animation are not compatible with collision (or I missed something), so I lost easing function
• "manual jump" (with cos/sin, etc)  works but it sounds a little bit crappy, maybe I just did it wrong
• and what about jumping when walking on a "bumper", calculate those things manually seems very hard
• also, even if not moving,  I had to apply gravity on the render loop in order to simulate gravity because it is too hard to detect when you must - or not - apply gravity for performance issue. (btw, why applyGravity exists only on camera ??)

Also, I don't need mesh collision precision, a box is enough, so I tried something similar to your example, but with a parent box mesh : my character become a box, the Dude meshes are the children, just for visual purpose. It works, but I wonder what is the difference between this box (+ boxImpostor) + children and your example with 2 box + 2 impostors + 1 joint ? Is it for controlling the center of gravity to have more stability ?

Anyway, using the physic engine for the main character of a FPS seems to be a bad idea, I understand that, I don't really need it. So if you have any suggestion to create a smooth jump please tell me  There is not example or explanation on all the internet .

Thank you
 

 

[Wingnut]

Well understood.  It may not be a bad idea.  Perhaps... just a bit challenging.  Let's pretend that the green box is invisible, and the gray ibox is also invisible and parented to root (meshes[0]).  Perhaps that will let us do something.  We might be able to manually-force or animation-force ibox, and player model and invisible green box near player's feet... goes along for the ride.  If we force the ibox into a parabolic flight,  player model flies too, because root is parented to ibox.  Invisible green "feet platform" box flies, too, because it is jointed to ibox.

You MIGHT get some good jumping/landing options with that, depending upon mass/friction settings and surface angles of the landed-upon objects/surfaces.

We also have "intersectsMesh" which might be a useful non-physics method.  IntersectsMesh has methods for mesh with ActionManagers attached, or no ActionManagers.

Have you thought about if/not a player body-movements animation will be happening WHILE player is in jump-flight?  That could make things more challenging.  That animation would probably need to stop upon landing the jump.

A friend once made a cannon for me.  https://www.babylonjs-playground.com/#25OQ8V#13  It doesn't use a physics engine, but notice the cannonball nicely impacts with ground and does bouncing.  But mainly, you would be interested in how to fly ANYTHING... with a parabola trajectory.  If you were to "master" moving mesh in parabolic trajectories/paths, you have yet another jumping tool.  *shrug*

I think SOME gamecoders work SO HARD to get the player nav correct, that they don't want to give-out their code, afterwards.  Sort of a trade secret.    I know BJS docs could use a complete moving-the-player tutorial... but... it's rough... especially if the model is blending animations between walk, run, jump, land, turn, fight, etc.  If I ever had to make a player character, I think I would use a no-arms, no-legs robot. 

---------------
There is another collision system... built-into BJS framework.  It uses... umm... camera.applyGravity, mesh.checkCollisions, mesh.ellipsoid, mesh.ellipsoidOffset, mesh.moveWithCollisions, those type of commands.  It was designed for camera-to-mesh colliding, but SOME have used it for mesh-to-mesh collisions, too.  It OFTEN fails at being used for player jumping... because it uses ellipsoid shapes (somewhat like sphere impostors) on all mesh and cams.  Ever try to put a bowling ball atop another bowling ball?  (slides off).  But, there is a setting... engine.collisionsEpsilon that allows us to adjust the slide-off tendencies of the ellipsoid colliders.

Massive testing of the  builtin collision system.... happened here:  https://www.babylonjs-playground.com/#WWCK0#82  Q and E keys, or shifted Q and E keys... move the cylinders/barrels upward and downward.  When the top barrel is moved downward, the collision happens too high, and gets stuck in collision state.  When the bottom barrel is moved upward, the collision happens too late, and gets stuck in collision state as well.  SO, this collider system isn't perfect.  It isn't designed for this activity, and it is especially bad at collisions from top/bottom.... which is exactly what you need... for jumping onto things.   Still, i wanted to show you the other system.  LOTS of extra code has been put inside that playground... and can be removed, to make a better testing PG.  Version 51 of the barrels playground... is a cleaner version.
---------------

To be straight, I'm not a pro at these player-control things.  Others, surely, have more experience than I do... at player nav/controlling.  Don't let the things I say... rule-out ANY methods, because, I am wrong pretty often.   And, people are ingenious and  inventive, and often do things that I thought were impossible.  My primary objective was to show you some things, and tell you some things... and maybe keep your project moving forward.  Some assorted things that you can run tests-upon. 

Others are LOTS smarter and more experienced than I.  Let's hope they comment and give more PG examples... soon.  I will be nearby, too.  Feel free to ping me anytime... ask questions, show me stuff.  I will always TRY to find decent answers and give semi-informed comments.  We're here for ya... just slow sometimes.    Be well, talk again soon.

[yLacaute]

Still a pleasure to read you

I continued with physic enabled (no friction, no bounce), but jump bring me a little problem : sometimes my character turn in the air so he collides the ground lying down (not on its feet) lol.
I must admit : I really don't need a physical engine for the main character...

Finally, I continued with built-in collision system, I managed to move my character, and I can jump on other objects !   Jumps are done with animation and the anime is stopped with ActionManager (OnIntersectionEnterTrigger).
The cannon sample is interesting, thank you. Btw, this sample  remind us how useful can be a physical engine, avoiding complex code

 

[Wingnut]

Thx!    There is a setting called .fixedRotation ... for physics.  Might be worth a playground search.

BUT... if you set .fixedRotation, your player will not be able to change directions... during jump-flight.  In fact, player will never be able to change directions, even when walking.

Perhaps instead... you can do this (or similar)... maybe...

var tmpAngVel;
scene.beforeRender = function() {
    tmpAngVel = player.physicsImpostor.getAngularVelocity();
    player.physicsImpostor.setAngularVelocity(new BABYLON.Vector3(0, tmpAngVel.y, 0);
}

This code SHOULD allow your player to spin on the Y-axis anytime (IF ever wanted), yet player cannot tumble around X or Z axis.  Might work.    Something fun to try.

Setting linear and angular velocities is pretty fun.  Don't forget to eat and sleep sometimes. 

Sometimes, you'll find some physics playgrounds that say "setPhysicsState" is not found.  Those playgrounds are not necessarily dead.  We deprecated/obsoleted 'setPhysicsState' about 1.5 years ago, and now use a different method.  With a tiny bit of modding, a PG with a setPhysicsState error... can be updated and brought back to life.

Also, when a mesh is physics-active, it uses mesh.rotationQuaternion for its orientation, and sort-of ignores .rotation.  This is why we use the .rotate() command instead of .rotation property... to mess-with rotation on physics-active mesh.  If you wish, we can call physics-active mesh... "p-mesh".  easier typing.   

Note:  Quaternions can give brain tumors.  They have 4 values... very strange critters, but physics engines LOVE them.  But yeah... mesh.rotate() or setAngularVelocity... for spinning stuff.  And mesh.translate() and setLinearVelocity (and also .position and .setAbsolutePosition())... for positioning p-mesh. 

Impostor applyImpulse and applyForce can also be used to apply forces.  They could be linear, angular, or both, depending upon where... on the mesh... the impulse/force is applied.  Often, people apply a force or impulse at location mesh.getAbsolutePosition()... but if you applied a force at mesh.getAbsolutePosition().add(new BABYLON.Vector3(.1, 0, 0))... (contact point slightly left-of-center), that will make the force... cause SOME spin around Y axis.

It will all become much easier... very quickly.  It doesn't take long to learn how to have good physics fun.  You sound like you are already "gone".  I think we better mail you some food, or you will forget to eat.... too much playing. 

[yLacaute]

That is what i would like to reproduce lol  Damn I used to play Q3 RA3, love this physic engine... 
Now I see that, I think... no, you should use the physical engine  Not sure BabylonJS will be able to manage so hard complexity of jump/speed/rocket jump/etc, what do you think ?

 

[yLacaute]

@Wingnut ?

[Wingnut]

  He's not here.  Oh wait, yes I am. 

Not a problem.   BabylonJS can handle whatever your JS environment/hardware platform can provide.

Like all webGL scenes, keep the models low-polygon-count, use textures for details.  If I were you, I would avoid physics engine, and build your own jumper... based upon Jerome's cannonball stuff.

No body bone/skeleton animations for player.  Some for enemies, though.  You might want to limit the number of enemies that are in-camera-frustum at the same time.  Maybe no more than 5 on-screen attackers at once.  Use sprites and billboarded (always facing camera) planes, for other effects.  Turn on some particles to "spruce up" the environment... during non-melee moments.

You must have fast gamepad fingers!  My hands got tired just WATCHING that video.