Hingejoint bugfix in Native Bullet, @normen?

Troubleshooting physics
1

I noticed the hingejoint in native behaving differently than jbullet, the pivots and rotation axises seamed off.



There are inconsistencies in the order of the vectors for pivots and axises used in the constructors and contructor calls in com_jme3_bullet_joints_HingeJoint.cpp and HingeJoint.java.



If you compare this code in com_jme3_bullet_joints_HingeJoint.cpp:

[java]

JNIEXPORT jlong JNICALL Java_com_jme3_bullet_joints_HingeJoint_createJoint

(JNIEnv * env, jobject object, jlong bodyIdA, jlong bodyIdB, jobject pivotA, jobject axisA, jobject pivotB, jobject axisB) {

jmeClasses::initJavaClasses(env);

btRigidBody* bodyA = (btRigidBody*) bodyIdA;

btRigidBody* bodyB = (btRigidBody*) bodyIdB;

btVector3 vec1 = btVector3();

btVector3 vec2 = btVector3();

btVector3 vec3 = btVector3();

btVector3 vec4 = btVector3();

jmeBulletUtil::convert(env, pivotA, &vec1);

jmeBulletUtil::convert(env, axisA, &vec2);

jmeBulletUtil::convert(env, pivotB, &vec3);

jmeBulletUtil::convert(env, axisB, &vec4);

btHingeConstraint* joint = new btHingeConstraint(*bodyA, *bodyB, vec1, vec2, vec3, vec4);

return (long) joint;

}

[/java]

to the native constructor in btPoint2PointConstraint.cpp,

[java]

btHingeConstraint::btHingeConstraint(btRigidBody& rbA,btRigidBody& rbB, const btVector3& pivotInA,const btVector3& pivotInB,

const btVector3& axisInA,const btVector3& axisInB, bool useReferenceFrameA)



[/java]

it indicates that axisA is used as pivotB, and vice versa.



Just swapping these from:

[java]

jmeBulletUtil::convert(env, axisA, &vec2);

jmeBulletUtil::convert(env, pivotB, &vec3);

[/java]

to

[java]

jmeBulletUtil::convert(env, pivotB, &vec2);

jmeBulletUtil::convert(env, axisA, &vec3);

[/java]

should solve it I guess (haven’t read all the code that thoroughly), but it’s probably better to go through the files com_jme3_bullet_joints_HingeJoint.cpp and HingeJoint.java to make sure the A,B,A,B,A,B pattern (bodyA,bodyB,pivotA,pivotB,axisA,axisB) is used consistently everywhere.

2

thanks I’ll check

3

Fixed this bug in svn, the other constructors mostly use Transforms so they should be fine. Thanks again.

4

Sweet:)