How to avoid clipping with fast moving rigid bodies?

Troubleshooting physics
1

So I have a fast moving rigid body (grenade) and it clips through another rigid body (map wall). Setting the accuracy to 1/500 basically resolves the issue but causes jerky movement when using a character control. Also reducing the linear speed and using a larger collision shape helps but then the grenade moves to slow for me.

Do you know any more ways to solve/reduce the problem?

s1.png796Ă—628 71.5 KB

    public ThrownGrenade(SimpleApplication app, Weapon weapon, Vector3f direction, Spatial mesh) {
	super(app, weapon, direction, mesh);
	this.length = super.getLength();
	this.speed = super.getSpeed();
	this.direction = super.getDirection();
	this.mesh = (Node)assetManager.loadModel(WeaponData.weaponMeshPath[weapon.getWeaponId()]);
	Vector3f bonePos = weapon.getPlayer().getMeshRigControl().getAttachmentsNode(WeaponData.bone[weapon.getWeaponId()]).getWorldTranslation();
	Vector3f posOffset = WeaponData.arrayOfGunPos[weapon.getWeaponId()][weapon.getPlayer().getCharacterNumber()];
	Quaternion boneRot = weapon.getPlayer().getMeshRigControl().getAttachmentsNode(WeaponData.bone[weapon.getWeaponId()]).getWorldRotation();
	Quaternion rotOffset = WeaponData.arrayOfGunRot[weapon.getWeaponId()][weapon.getPlayer().getCharacterNumber()];
	this.mesh.setLocalTranslation(bonePos.add(posOffset));
	this.mesh.setLocalRotation(boneRot.mult(rotOffset));
	Material mat = new Material(assetManager, "Common/MatDefs/Light/Lighting.j3md");
	mat.setTexture("DiffuseMap", assetManager.loadTexture(WeaponData.weaponMeshTexPath[weapon.getWeaponId()]));
	this.mesh.setMaterial(mat);
	rootNode.attachChild(this.mesh);
	BulletAppState bas = app.getStateManager().getState(BulletAppState.class);
	CylinderCollisionShape shape = new CylinderCollisionShape(new Vector3f(.25f, .5f, .25f), 1);
	rigidBody = new RigidBodyControl(shape, WeaponData.mass[weapon.getWeaponId()]);
	this.mesh.addControl(rigidBody);
	bas.getPhysicsSpace().add(rigidBody);
	rigidBody.setLinearVelocity(this.direction.mult(100));
}
1 Like
2

I believe bullet has an internal update loop of 1/60th of a second - or 60fps. So if the movement interpollation between frames just goes through it - your issue will arise.

e.g. in frame 38 it’s at point A - and frame 39 it’s past the wall - point B - the physics system saw no collision.

You could maybe fire a ray with a limit of the velocity to determine whether or not it’s going to hit something in the next frame, or make your “wall” bigger. Either way it’s going to need some kind of work-around or deterministic probability.

1 Like
3

Ok, so what can I do about it if I need the rigid body moving fast (as fast as you’d expect a thrown grenade to move)? Perhaps fiddle with the accuracy, CCD motion threshold and/or CCD swept sphere radius?

4

Sorry - I edited my post after writing it for a possible solution. ^^

5

The wall is already thick compared to the grenade collision shape, so perhaps I shoud use the ray solution. If I got it right, the ray should be used to periodically check if it hits an obstacle?

EDIT: a ray with a limited length.

6

Well it’s just an idea but yeah. You should know it’s velocity and direction - so you can use that with a ray - which will effectively be a step in front - or a future position. So if a collision was detected by the ray, you just set it’s position to the collision point and make it go boom. Or set it slightly behind so it will bounce and continue it’s trajectory.

1 Like
7

p.png796Ă—628 5.44 KB

But what if the rigid body should collide with the wall but the ray is slightly above so it does not register? Maybe I should add more rays?

1 Like
8

Nothing is perfect unfortunately. I would use the same ray with an agle of projection. Up down left right. A bit like a field of view indicator. Or you could accept not completely accurate results…i mean that grnade will decline in height and ur ray will see it at some point anyway if its fired in the direction its headed and not just straight ahead. There will be minor clipping but id take that as good enough to be fair.

1 Like
9

Basically, multiple limited rays from the same origin point at specific angles. Got it.

1 Like
10

CCD is (or should be) exactly that solution, it does a ray check if the object moved a certain amount within one frame. I did however notice that in jbullet CCD doesn’t always seem to work correctly, it seems it does work correctly in native bullet though.

1 Like
11

Maybe we’ll just have to wait for an update to improve jBullet.

12

This won’t ever happen, I am afraid.

1 Like
13

Why not?

14

Since our jBullet is already a modification, the original jBullet isn’t updated for years and bullet native is actually better in many cases (and in performance!)

Actually there is no reason to use jBullet (apart from maybe iOS)

15

Is it possible to download native bullet jars for jMonkey?

16

lol of course, the same way you got the other jars. If you use the SDK you also have bullet-native, it is even the default for new projects

17

Oh, because I though native bullet might have been written in another language and thus incompatible with jMonkey. :smile:

18

Note: written in another language != incompatible with jME/unusable by Java. Native code written in C is usable from Java. Previously to accomplish this you had to write some custom C/Java code to bind the native library, although modern Java libraries like JNR can ease the pain of using native libraries considerably without sacrificing much performance. C++ code can also be used from Java, although that requires significantly more care than linking to C code. (Other native languages like Go usually also have some way to interoperate with Java.) In general, avoid native code if you can. Sometimes it’s necessary, but it adds a lot of complication and can easily lead to JVM crashes that are difficult to diagnose.

3 Likes