physics and heightMaps

[Davin]

Quick question to clarify.....   is the built in physics engine still the only one that supports height maps?

[Davin]

I retract my question!   I should read the release notes closer...

Quote

• new Heightmap Impostor for Cannon.js physics engine. PR, Demo (RaananW)

 

[Davin]

--- side note, the version of cannon.js bundled with babylon needs updating to work with the new heightmap impostors.

[Wingnut]

  Hi Davin!  Yep, it's all "crossing over" at the moment.  I'm sure the playground will have all the newest toys, soon.

The playground is where I get my freshest babylon.js, cannon.js, oimo.js, and hand.js.  The playground is one of the first places to get the newest stuff... because testing is done there, too.  Demos for the BJS 2.3 release are being made as we speak.  It's a time of great transition and unexplored horizons.  Clear your browser cache, so when you hit some of the new playground demos in the new 2.3 release list, they'll work great, and give you a good zip (bundle?) to take home.

To clear things up a bit, Babylon.js has no built-in physics engine (though it does have built-in gravity, collide, and intersect). 

What we have is "plugins" (interface objects) to two popular add-on physics engines... Cannon.js and Oimo.js.  Both have their use... and are commanded from Babylon.js... about the same.  We also have a "physicsEngine" class here, that is a common point between the two plugins. 

There's really only 6 commands to drive either add-on physics engine.  Scene.enablePhysics(), scene.createCompoundImpostor(), mesh.setPhysicsState(), mesh.setPhysicsLinkWith, mesh.applyImpulse(), and mesh.updatePhysicsBodyPosition().  No matter which add-on physics engine is being used, those 6 basic commands... will give you the power to take over the world. 

If you please, take a LONG look at this...

http://www.babylonjs-playground.com/#DLBW7#10

That's a CannonJS demo which has a little bit of everything in it, except physics links and compound Imposters.  Click the sphere to impulse it around.  Change power, hit RUN again, make more saves, show'n'tell 'em to us, and have fun. 

Particularly notice how a physics "body" is returned from calls to .setPhysicsState.  They are ghost-like things... and they love Quaternion rotation methods (yaw, pitch, and roll), but they HATE Euler rotation methods (Vector3 - x-y-z)    Once you .setPhysicsState on some mesh... that ghostly "body" is the boss, to a degree.

We have SOME power over that boss.  Once per frame, we check the .position of the ball in line 52.  If its < 0, then it has fallen off the landscape.  Then in lines 53-55, we re-position the ball... but the physics "body" is still the boss.  Line 57 is the line that tells the physics body to get a fresh .position from the mesh itself (ease-up on the bossing while we put the ball back into the sky above the land). 

Recently, the updatePhysicsBodyPosition() function decided change its name to updatePhysicsBody() (although the old name will be honored for a while).  This was done because updatePhysicsBody() updates position AND rotation.  It updates rotation from the mesh.rotationQuaternion values, and not from mesh.rotation.  Mesh.rotation CAN be used to control physics body (though unorthodox and unpredictable)... via a method such as mesh.rotationQuaternion = mesh.rotation.toQuaternion(). 

Also, monitoring the physics body rotation Quaternion... via monitoring mesh.rotation... can give bad or no results.  I'm not an expert in this area, but I believe that having the physics body Quaternion do continuous .toEuler() and send that value to mesh.rotation... would bog the physics.

Looks like heightmap physics is working in the playground.  Better grab the zip.    Party on!

[Davin]

Fantastic answer!

I'm having a little issue applying this to imported meshes -- My guess is, because its trying to use the parent mesh as the bounding box?  I was able to replicate it using the playground you gave as an example.

 

http://www.babylonjs-playground.com/#ROVSJ

[RaananW]

hi Davin,

Imported meshes are sometimes not centered or have weird transformation (it is very easy to scale in a weird way in Blender just to get the mesh to look like you want it to ).

Try baking the current mesh transformation and then applying the impostor like suggested here - 

 

[jerome]

Remember you could also code light functions and use a heightmap without any physic engines : http://www.babylonjs-playground.com/#RBXBG#6

if just need some simple features like "following the relief"

[Wingnut]

Davin, and others, I recently updated my previous post.  I forgot about mesh.setPhysicsLinkWith()... so there are actually SIX basic commands.  I'm getting old.  There is also new information there about mesh.updatePhysicsBody()... which was previously called updatePhysicsBodyPosition().  Its name was changed because 'position' is not the only property it can update.  It also updates the physics body rotation... from values found in mesh.rotationQuaternion.   The old name still works, but it's likely being phased toward eventual deprecation  (its death is on the far horizon).

My previous post is 4 posts north of here. 

Thanks to Raanan for LOTS of physics knowledge, including clarifying function names, adding tons of new physics features, and fixing my misconceptions and mistakes.  He reminded me about setPhysicsLinkWith(), even though I did some huge train locomotive wheel experiments recently.... that used setPhysicsLinkWith() OFTEN.  Go fig.   

Those Oimo-based link experiments begin with THIS forum post and continue for 6-8 posts.

[Wingnut]

Hi again!  Davin, if you don't mind me commandeering your thread... I have a question for all the physics Gods.

When the first physics demo arrived at the BabylonJS website, it had walls around the play area, and those walls all used...

border.checkCollisions = true;

But, I rarely/never set .checkCollisions when I do physics experiments.  AbstractMesh sets this property default false.

Does anyone know the story with this (or a pointer to some docs)? 

WHEN should users (like me) set .checkCollisions... when working with physics engines?  When needed?  When not?

Thanks for info!  Maybe this question belongs in its own thread in Q/A... to make it easier for others to find this answer?  *shrug*

[GameMonetize]

Hello checkCollisions is for collisions (with the FPS camera) and is not related to physics simulation

 

So short answer: checkCollisions is not required for physics