[SOLVED] DynamicAnimControl collision shapes are too big

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

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()) {
1 Like

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

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

That’s unexpected and probably fixable.

  1. Which solution did you use?
  2. Are you using Minie or jme3-jbullet?
  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

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

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

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

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

1 Like