# Problem with multiple joints

Hi im making a simulator for PopUpBooks. But im having problems with multiple joints. It is acting weird…
Here is whats happening:

Here the code for the joints:
front is the lefthand bottom plane
back is the righthand bottom plane
front2 is the lefthand plane thats standing up
back2 is the righthand plane thats standing up

``````Vector3f [] verticesF1 = new Vector3f[4];
verticesF1[3] = new Vector3f(0,0,-4);
verticesF1[2] = new Vector3f(-5,0,-4);
verticesF1[1] = new Vector3f(-5,0,4);
verticesF1[0] = new Vector3f(0,0,4);
Mesh f = makeMesh(verticesF1);
Geometry front = new Geometry("Front", f);

Vector3f [] verticesB1 = new Vector3f[4];
verticesB1[0] = new Vector3f(0,0,-4);
verticesB1[1] = new Vector3f(5,0,-4);
verticesB1[2] = new Vector3f(5,0,4);
verticesB1[3] = new Vector3f(0,0,4);
Mesh b = makeMesh(verticesB1);
Geometry back = new Geometry("Back", b);

Vector3f [] verticesF2 = new Vector3f[4];
verticesF2[0] = new Vector3f(0,0,0);
verticesF2[1] = new Vector3f(0,5,0);
verticesF2[2] = new Vector3f(-3,5,3);
verticesF2[3] = new Vector3f(-3,0,3);
Mesh f2 = makeMesh(verticesF2);
Geometry front2 = new Geometry("Front2", f2);

Vector3f [] verticesB2 = new Vector3f[4];
verticesB2[0] = new Vector3f(0,0,0);
verticesB2[1] = new Vector3f(0,5,0);
verticesB2[2] = new Vector3f(3,5,3);
verticesB2[3] = new Vector3f(3,0,3);
Mesh b2 = makeMesh(verticesB2);
Geometry back2 = new Geometry("Back2", b2);

front.setMaterial(paper);
back.setMaterial(paper);
front2.setMaterial(paper);
back2.setMaterial(paper);

Node frontPage = new Node("PhysicsNode");
frontPage.getControl(RigidBodyControl.class).setPhysicsLocation(new Vector3f(0f,0f,0f));

Node backPage = new Node("PhysicsNode");
backPage.getControl(RigidBodyControl.class).setPhysicsLocation(new Vector3f(0f,0f,0f));

Node backPage2 = new Node("PhysicsNode");
backPage2.getControl(RigidBodyControl.class).setPhysicsLocation(new Vector3f(0f,0f,0f));

Node frontPage2 = new Node("PhysicsNode");
frontPage2.getControl(RigidBodyControl.class).setPhysicsLocation(new Vector3f(0f,0f,0f));
frontPage2.getControl(RigidBodyControl.class).setKinematic(false);

frontPage.attachChild(front);
backPage.attachChild(back);
frontPage2.attachChild(front2);
backPage2.attachChild(back2);

planes.attachChild(frontPage);
planes.attachChild(backPage);
planes.attachChild(frontPage2);
planes.attachChild(backPage2);

//this is the joint i enable the motor on.
joint = new HingeJoint(frontPage.getControl(RigidBodyControl.class), backPage.getControl(RigidBodyControl.class), Vector3f.ZERO, Vector3f.ZERO,new Vector3f(0f,0f,-1f), new Vector3f(0f,0f,-1f));
joint.setLimit(0, 3.14f);

HingeJoint joint2 = new HingeJoint(backPage.getControl(RigidBodyControl.class), backPage2.getControl(RigidBodyControl.class),new Vector3f(0f,0f,0f) , new Vector3f(0f,0f,0f),new Vector3f(1f,0f,1f) , new Vector3f(1f,0f,1f));
HingeJoint joint3 = new HingeJoint(frontPage.getControl(RigidBodyControl.class), frontPage2.getControl(RigidBodyControl.class),new Vector3f(0f,0f,0f) , new Vector3f(0f,0f,0f),new Vector3f(1f,0f,-1f) , new Vector3f(1f,0f,-1f));
HingeJoint joint4 = new HingeJoint(frontPage2.getControl(RigidBodyControl.class), backPage2.getControl(RigidBodyControl.class),new Vector3f(0f,0f,0f) , new Vector3f(0f,0f,0f),new Vector3f(0f,1f,0f) , new Vector3f(0f,1f,0f));
``````

Code for the listener:

``````public void onAction(String name, boolean keyPressed, float tpf) {
if (name.equals(E_FOLD)) {
app.joint.getBodyA().activate();
if(keyPressed){
app.joint.enableMotor(true, 1.5f, 100f);
}else{
app.joint.enableMotor(true, -1.5f, 100f);
}
}
}
``````

The desire effect is that when i enable the motor for “joint”(limited from 0 to 3.14), it would drive “joint2”," joint3", and “joint4” to move, openning “front2” and “bage2” page like a popupbook would.
But it seems that when “joint” hits the limit of 3.14 or 0, the “joint” stopped moving, but somehow “joint2”,“joint3” and “joint4” which is driven by “joint” kept going…(the only joint i enabled is “joint”)
And somehow the joint connecting front2 and back2 is sometimes torn appart.

1 Like

Is there a particular reason you want to use physics as opposed to an animation? You could have the outer pages with physics drive an animation on the inner pages, less to go wrong

Interesting topic!

Here are two ideas:

• set the joint limit to be (0.04f, 3.1f) instead of (0.0f, 3.14f) → does error still appear?
• make the resolution of the PhysicsSpace finer (i.e. more calculation steps or something like that)

Yes I would like to do collision checks with it later in the project

Well, that could be done with animations driving physics.
There is a basic physics thing called “kinematic physics”.
The idea:
Let the outer pages drive the animation, like @QSDragon proposed.
Let the animation drive physics objects that are purely kinematic.
Throw your objects at the pop-up-book and they will collide with the kinematic stuff.

But why not first try the other thing - don’t use 180 degree (0 to pi), but 0,04 to 0,31.
Or make the calculation more precise - that solved some problems for me.

Yep I just tried it! I tried limiting the joint limit to that you suggested. Also I find changing the mass of all the pages to be the same(except the 0 mass for “back” which is stationay on the ground) stablizes things. No more random spinning!
Just sometimes when i fold it, the inner pages would go though the outer pages. Sometimes even stuck in it… any ideas?
Can You elaberate the calucation more precise part or make the resolution of the PhysicsSpace finer part. Not quite getting that part. Maybe because im new to jme
thanks again!

The other thing (animation instead of physics) seems a little bit too vague, even to me.
I mean, that might work if you design your pop-up-books in blender and export the animation.
But I guess, that’s not what you want, probably you want the user to design inside jME?
It’s a quite difficult idea that would need some more thought and countless hours of trial and error.

Hm … not really. But maybe it gets solved when you make the calculations more precise. This problem typically comes from collision-resolver with lower precision than needed. Can be seen in many games, even those made with CryEngine etc.
Problem with your pop-up-book is that you have very thin colliders. It’s not like having a box or sphere where the outside and the surface normal is easy to find. But even in those cases you can sometimes see spheres pushing through walls of bricks under circumstances (low frames per sec, many objects), so even that can become a problem if the physics engine is not configured correctly or the scene is overloaded with computations.

Oh and there’s more…
Did you know that there is a native bullet and a Java bullet version?
The native one might provide more computation power (good for higher precision of the calculation).
But I’m not much into that topic - I just returned to jME a couple of days ago.

Hey Sorry To bother again. Remember my situation? After some work I am now at a stage where I have to add more to increase complexity of the pages. But as soon as i add another structure the old problem came back… :

I tried to increase the iterations and the accuratecy of the physics space like it did last time to a point which makes the whole thing lagging, still it was of no use. The pages got stuck in between. I also did increase the hinge limit so it is further away from 0 and Pi. still no use.
I read from somewhere that large triangles for mesh might cause these kind of stuff. So i increase the triangle density for the mesh still… no use.
I am thinking of trying what you and QSDragon mention b4. About animating but im not too sure how it works. If i were to try the animating method, I animate the node that contains the front page. And all the other page what has joint with it will be driven?

Hm, animation would be made in Blender most likely.

Can’t speak for what @QSDragon suggested, but my idea was: a) have an animation first, not physics, but then b) add some physics based on the animated geometry (so that things can collide with it - what you would like to have for some reason). So … animated somewhere else, then scanned at runtime (where are the triangles) and then add physics-based triangles in kinematic mode exactly where the animated triangles are in each frame. So that’s not a physics simulation anymore then, but you could throw virtual objects at your book and they would bounce off the kinematic physics.

I was just starting to think that … maybe … there is a better way to do it analytically - since it’s a folding 2.5 dimensional world we are having here, maybe with math / analysis you could figure out how things behave and then compute all the angles with a clever algorithm that uses this math. Might be more promising than the other two ways (one of which - pure physics with the bullet physics engine - doesn’t seem to work - which is plausible, since you have a complicated edge-case which does not really work well with real-time physics / the second one is the animation instead of physics / the third one would be to look for the best suitable math or algorithm).

Sorry that I can’t help.

Did you web-search this topic?
→ Maybe someone else figured out the math/algorithm for this.
→ Maybe someone made a plugin for Blender or other Modeling tools like Maya.
→ Maybe take a look at how professionals make such a book - and learn from their method.