Clipping through imposters?

Fellow scholars,

I might even be able to answer my own question here; not sure what the solution is but let me describe the conundrum.

Running around my virtual world, just after I grabbed my virtual coffee, I decided to run into some imposters with my character. Everything looks good, and I’m running mindlessly into an invisible wall! but every now and then, the CPU or something skips a beat and something spikes, and I will clip through a collision plane imposter or a collision box imposter (thick ones too), worst case, the ground.

This can lead to the player ending up stuck inside an imposter :frowning: or falling off a balcony somewhere. I did a lot of forum reading, and my instinct is that this is something to do with the delta time and sub-steps of the physics engine.

I was going to find the source of whatever is causing it to glitch, but! thinking about it, CPU stutters are going to happen, so it might be better to figure out how to stop imposters from clipping through each other.

I’m running ammo as the physics engine; I did try all three, and ammo was the best for my needs, in fairness it could be ammo too, but what I don’t get is box imposters working correctly when colliding, then you get a CPU stutter, and the player imposter can end up trapped inside another imposter, I don’t think I can do deterministic lock step just yet. But hey! if that’s the only road :slight_smile: Like everyone else, I’m dreaming of BJS6 & Nvidia PhysX.

It’s almost like you want to pause physics steps if a stutter happens to avoid it doing whatever it’s doing.

Any ideas, high council?

Which physics engine are you using?

Ammo for physics :see_no_evil: :skull: is it an ammo thing?

Not necessarily, I think first you should try reducing the walking speed of your character and see if the problem still occurs. I’ve been down this rabbit hole a few times and one thing that I saw consistently being brought up was the speed of the object moving.

Let’s say you have the following setup:

 | --------> 10 m <----------|
 0                           |
/||\     ==> 10000 m/s       | wall
 /\                          |

In the next tick of the physics engine your characters new position would be extrapolated well past the position of the wall, and for whatever reason the physics engine doesn’t check if you had to move through any walls to get there. Could be something else too though.

Interesting; this is notionally what I thought was happening.

The imposters getting stuck in other imposters, could that be a mistake in blender on my part?, I’ve seen flipped normals before but pretty sure it’s not that because the collisions work(ish).

What’s your setup look like? I integrated the babylon.js inspector UI into my project by just exposing an html button that toggles the inspector UI. With that you should be able to toggle the various physics imposters outline meshes - in fact I think it enables rendering all of them.

Does this help? I’m not sure I can deal with the heartache of swapping the physics engine out again haha.

One more with the imposters a bit more visible.

Screenshot of perm mon during a healthy moment

Screenshot where it bugged out but also shows the valley of death figures; that GPU frame time does look high, but it’s noticeably where the framerate dips that the escapes happen.

One more with physics on perf mon; this one looks more hairy.

Continuous collision detection is one way to deal with this problem, but I don’t know if it’s supported by Ammo… Let summon @Cedric, he will probably know!

1 Like

yes, it’s supported by ammojs but not by the babylon plugin. you have to call these ccd function on the collision object/rigid body:


Way outside my comfort zone, but notionally, we’re saying carry on with ammo using BabylonJS plugin, and then, If I remember from several other forum deep drives, there is a way to make a native ammo fn call, and I need to set those two CCD functions for the imposters in the scene?

You need to get the ammo body from the impostor (impostor.body) and then apply these functions

  1. void setCcdMotionThreshold (float ccdMotionThreshold);

I can’t remember, but are the units of distance in Ammo the same as Babylon?

At the first test, I think this has indeed fixed it, thank you @Cedric & @Evgeni_Popov @arcman7 for all your help and support.


That’s awesome!

1 Like