Questions on Updating Heightmap Physics Impostor

Hey all, really appreciate all the hard work that’s gone into Babylon! Been enjoying my time with it.

I’m currently trying to create an undulating terrain with a sphere on it (so essentially over time the height of the terrain changes according to a simplex noise function). I managed to get it to render correctly, but I’ve been having difficulties with the physics part of it.

I’m using a ground mesh and modifying the y value of the vertices from the vertex data.
When I create a HeightmapImpostor for the terrain and call the impostor.forceUpdate() function after I update the mesh, the sphere bounces around a bit then goes through the terrain. Everything works properly when using a MeshImpostor, but as to be expected it’s rather slow, and the PhysicsViewer does not show the shapes of the Mesh/Heightmap impostors so I’m not quite sure what’s happening.

What would be the proper way to update the HeightmapImpostor for a terrain that changes every frame? Is this even performantly realistic with the physics engines, or should I try and roll my own “physics” approach for this? (I just need the ball to roll around the terrain in a way that’s reminiscent of proper physics, but I have no idea where to get started with that)

Any advice would be appreciated!

Hello and welcome to the forum !!!

Let me summon our friends @Cedric and @RaananW as they would be way more helpful than me with physics.

1 Like

Hi Anthony

Updating the mesh impostor everyframe will be slow. Some internal structures have to be updated and depending on your mesh complexity, it will take time.
If it’s a couple hundred triangles, it might run in realtime. If it’s thousands, it won’t fit.

Maybe with web workers but I’m not sure you’ll have total controls on impostor update. I mean, it doesn’t guarante that it will run at your frame rate.

If you have only sphere, I’d try to compute the physics. Especialy if you can compute the height from the XZ position.

To do that, start with the basics: your sphere is composed of a position and velocity. each frame, position += velocity * deltaTime. and velocity += forces * deltaTime.
Then compute the forces based on gravity and terrain inclinaison.

That’s Euler integration and that’s really useful when you code games.

Once you have the position, the sphere rotation is computed by the distance (current positon minus previous frame position). Basically, the more the ball rolls, the more rotation you have.


Thanks @sebavan for the welcome and Cedric for the reply! Really appreciate the guidance. I guess I’ll read into this a bit more. Thanks!