Joints Thought Gathering

Troubleshooting physics
1

Hi all.

I am thinking of a couple of ways of creating Joints. I just want your opinions on em (or more suggestions):



Thought 1:

Creating a single class named "Joint" whereby the constructor takes an argument on which type of Joint this is…And process is this way.



Then have multiple classes with only public final static variables on there so that you can access them from the Joint. So a typical Constructor would be:



Joint j = new Joint(JointHinge2.TYPE);
j.setParameter(JointHinge2.SomeVariableForODE, 3f);
.....etc




Thought 2:
Have an abstract class Joint which has setter and getter methods for:
    type(int). What type of joint this is[/list:u]
    attachPhysicsObjects(PhysiObject obj1, PhysicsObject2)[/list:u]

    All other joints extend this and define their own variables and behaviour. So a typical constructor would look like:


    JointHinge2 joint = new JointHinge2(physicsObject1, physicsObject2);
    joint.setSomeParameter(2f);



    Which way do you see best?

    Or even better, do you have another method that you like to see in there instead?

    Thx, DP
2

I’d go with “Thought 2”, since you sometimes want to change the joint type after it’s been initialised…



Also, I think the user interface should be similar to Nodes… so to attach a PhysicsObject you’d go through Joint.attachChild(PhysicsObject)

3

so to attach a PhysicsObject you'd go through Joint.attachChild(PhysicsObject)


Im afraid thats not possible there Per as Joints MUST have 2 PhysicsObjects. No greater, no lesser. So the only way I can guarentee that is through:


SomeJoint.attachChild(physicsObject1, physicsObject2);
PhysicsObject obj = SomeJoint.getPhysicsObject1();
PhysicsObject obj1 = SomeJoint.getPhysicsObject2();



Also, the second design doesnt' allow for type changes. It just an easy way to store and then later retrieve them from an arraylist without instanceof calls.

With the first idea, its just another way to set paramters. Also, you only ever have to do deal with one "solid" object and its interface stays the same. With thought 2, you would have to know the method name to set this parameter...etc

DP
4

Im afraid thats not possible there Per as Joints MUST have 2 PhysicsObjects. No greater, no lesser.

Ah.. then it feels very clear that those two PhysicsObjects should be provided in the constructor, like in the thought2 example.

I say +1 for an abstract super class - it feels like it's more OO and IIRC instanceof is very fast.
5

I prefer your second idea with an abstract superclass too.

6

thats cool.



Anyone has any other ideas they like to bring forth besides the above two?

7

Its almost done!



Box box1 = new Box("Box 1", new Vector3f(), 1f, 1f, 1f);
box1.setLocalTranslation(new Vector3f(0, 10, 10));
SimplePhysicsObject obj1 = new SimplePhysicsObject(box1, 1f);
      
Box box2 = new Box("Box 2", new Vector3f(), 1f, 1f, 1f);
box2.setLocalTranslation(new Vector3f(5, 10, 10));
SimplePhysicsObject obj2 = new SimplePhysicsObject(box2, 1f);

HingeJoint hJoint = new HingeJoint(obj1, obj2);
hJoint.setAnchor(new Vector3f(2.5f, 10, 10));
hJoint.setAxis(new Vector3f(0, 1, 0));



Its that simple!

So expect indirect ragdoll support for v0.3 while i find a good and customisable way of creating them for v0.4...

Ofcourse, more complex joints (like universal or JointHinge2) have more methods that need to be called rather than just set anchor and set axis :)

DP