[SOLVED] DynamicAnimControl collision shapes are too big

Troubleshooting physics
1

I’m using DynamicAnimControl on the Sinbad model which is scaled down by a factor of 10. DAC didn’t seem to get the hint, so it’s still calculating collision shapes as if Sinbad was still 10x bigger. What should I do to make the shapes smaller?

DynamicAnimControl dac = new DynamicAnimControl();
dac.setMass(DacConfiguration.torsoName, e.get(CharacterShape.class).getMass());
dac.link("Waist", .01f,		new RangeOfMotion(1f, -0.4f, 0.8f, -0.8f, 0.4f, -0.4f));
dac.link("Stomach", .01f,	new RangeOfMotion(1f, -0.4f, 0.8f, -0.8f, 0.4f, -0.4f));
dac.link("Chest", .01f,		new RangeOfMotion(1f, -0.4f, 0.8f, -0.8f, 0.4f, -0.4f));
// etc...

I should mention that I’m only configuring the DAC when Sinbad dies, so this code is seperate from where I actually create Sinbad.

1 Like
2

The shapes are too big because no matter how you scale Sinbad, the physics collision margin is still 0.04 units for all link shapes.

You can either:

  • scale everything else up OR
  • reduce the global margin before the collision shapes are created, using CollisionShape.setDefaultMargin(0.004f) OR
  • reduce the collision margin of each link body after it is created, using
for (PhysicsRigidBody body : dac.listRigidBodies()) {
       body.getCollisionShape().setMargin(0.004f);
}
1 Like
3

Thank you, that worked! :+1:

Edit: Although the collision shapes are working correctly now, the physics debug meshes for them are still the wrong size. It’s not really that important, but it’s very messy for physics debugging.

1 Like
4

yes, the main problem is that default JME scale [1unit : 1meter] is not compatible with default Bullet margin Scale.

so if someone doing FPS like game, or on close camera view, then Minie require game to be like [10unit : 1meter] scale.

1 Like
5

That’s unexpected and probably fixable.

  1. Which solution did you use?
  2. Are you using Minie or jme3-jbullet?
6
  1. I looped through each collision shape. It seemed more flexible.
  2. To be honest, I’m not sure. Minie is included in my project, but I haven’t done anything directly with it yet.
1 Like
7

If you’re using Minie, your app should print a startup message to System.out similar to:

Libbulletjme version 17.0.0 initializing

If Minie is in your classpath, your app will have access to various classes that don’t exist in jme3-jbullet, including:

  • com.jme3.bullet.collision.shapes.MultiSphere
  • com.jme3.bullet.util.NativeLibrary
  • com.jme3.bullet.SolverType

The reason I’m curious is because I made a quick attempt to reproduce the debug-mesh issue using Minie and was unsuccessful. On the other hand, there is a known issue with debug meshes in jme3-jbullet that might explain what you’re seeing.

1 Like
8

That message does not appear on initialization, so no, I’m not using Minie even though it is in my classpath.

That other issue is similar to mine on the point of the debug mesh not updating.

1 Like
9

That other issue is similar to mine

Indeed. And now I’m 99% certain that switching to Minie will solve your debug-mesh issue.

1 Like
10

Ok, I will look into that. Thanks for your help! :grin:

1 Like