Joints in a ring

epoulsenepoulsen
edited June 2013 in Help request
I've recently looked at using joints, and I want to support them in my inkscape --> orx converter.

It looks like you create joints that attached to child objects.

But what about the case where you need a loop of joints (think of a tank tread, or a rubber band)?

I did a quick test, and having a A --> B --> C --> A parent/child doesn't work.

Comments

  • iarwainiarwain
    edited June 2013
    Hi!

    Sorry, I thought I already replis to your question, but somehow I failed. :/

    In theory, you should be able to to circular chains of joints.
    However you can't do it directly using the ChildList property, which means there's at least one joint that you'll have to add manually between two bodies (orxBody_AddJointFromConfig).
    That also means you are responsible for deleting that one joint.
  • epoulsenepoulsen
    edited June 2013
    Ah, okay.

    Why not simply have joints have a BodyA and BodyB parameters? Is it to support joints always having parents for the sake of auto-deletion when the parent body is deleted?
  • iarwainiarwain
    edited June 2013
    Mmh, not sure I follow. Both orxBody_AddJoint*() functions take two bodies as parameters. Did I miss something?
  • epoulsenepoulsen
    edited June 2013
    I mean for the config files. Right now, joints are only associated with 1 parent --> 1-or-more children.
  • iarwainiarwain
    edited June 2013
    Ah yes, in config, I see. :)

    Well, I'm not sure how it would work actually, could you give me an example on how you'd see that? If that works, I could probably update orx to support it.
  • epoulsenepoulsen
    edited June 2013
    Like this:
    [RevoluteJoint]
Type = revolute;
ObjectA = ObjectTemplateA; Naturally these objects must have bodies.
ObjectB = ObjectTemplateB;
AnchorA = [Vector]; NB: In ObjectA local space;
AnchorB = [Vector]; NB: In ObjectB local space;
Collide = true|false; NB: Allows collision between joint's parent and child bodies. Defaults to false;
Rotation = [Float]; NB: Default rotation between parent and child bodies, in degrees. If none is provided, the current rotation difference between both bodies will be used;
MinRotation = [Float]; NB: Only used if MaxRotation is also defined;
MaxRotation = [Float]; NB: Only used if MinRotation is also defined;
MotorSpeed = [Float]; NB: Only used if MaxMotorTorque is also defined. In degrees / seconds;
MaxMotorTorque = [Float]; NB: Only used if MotorSpeed is also defined;

    Mostly I'm interested in making sure that the map converter can handle these sorts of structures w/o any compiled code necessary for the programmer.
  • iarwainiarwain
    edited June 2013
    The issue with that configuration is that the joint would be creating the objects as ObjectA/ObjectB don't refer to instances but to "templates". There can already be many instances of ObjectA/ObjectB created, and they might have nothing to do with that RevoluteJoint.

    If the joint is creating the objects, it brings another issue: it's not very handy to hold onto a joint reference when everything is object-centric.
    That also means it cannot be part of a hierarchy as objects can only trigger the creation of other objects.
  • epoulsenepoulsen
    edited June 2013
    Hmmm,

    The whole object-definition vs instantiated-object thing just sort of gelled. I guess in my mind I was thinking of an .ini as a singular scene description rather than a set of templates you could selectively instantiate from. In hindsight, this is obvious :)

    The crux of the problem is the requirement of hierarchy for auto-instantiation of joints vs the potentially cyclic nature of the joints themselves.

    How about this:

    [JointGroupTemplate]
    ChildList = Object1 # Object2 # Object3
    JointList = Joint1 # Joint2 # Joint3

    Assume "-->" means "join"

    In the above example, Joint1 --> (Object1, Object2), Joint2 --> (Object2, Object3), Joint3 --> (Object3, Object1).

    Considerations / Restrictions:
    * All child objects must have bodies.
    * JointGroupTemplate must NOT have a body; would be it's own template type.
    * The number of joints must be either N or N - 1 where N is the number of children. N would mean cyclic, and N-1 would be open.
  • iarwainiarwain
    edited June 2013
    Mmh, in that case how would you represent one object being the parent of two jointed objects? Or one object being jointed to more than 2 objects?
    Lastly, if you simply want a single relation ObjectA -> ObjectB, you need to introduce a common parent which is most likely not wanted.

    You can already represent the open chain, it's only the case of closed/cyclic chain that can't be represented at the moment.

    However, I think we can already support this although it's a bit of a workaround: by adding a track on the first parent and last child, we could add the extra-joint provided that the necessary command exists. If it's not the case, it's easy to add such a command.
    Actually, a single track on the last child would be sufficient, but it'll be a more complex one involving recursion, not sure it's worth it. :)
  • epoulsenepoulsen
    edited June 2013
    Mmh, in that case how would you represent one object being the parent of two jointed objects?
    Not sure what you mean. One object jointed to two others? Or simply a parent object that have children with joints (regardless of what the joint is connected to)?
    Lastly, if you simply want a single relation ObjectA -> ObjectB, you need to introduce a common parent which is most likely not wanted.
    Does changing ChildList to ObjectList, and making [JointGroupTemplate] a sort of factory (which would require a factory concept) alleviate this problem? Would having some sort of generic instantiation grouping template that isn't itself an object be useful? Perhaps even specifying another object template as the group's shared parent? Or is that weird?
  • iarwainiarwain
    edited June 2013
    epoulsen wrote:
    Not sure what you mean. One object jointed to two others? Or simply a parent object that have children with joints (regardless of what the joint is connected to)?
    Yes, having ObjectA -> ObjectB and ObjectA -> ObjectC.
    Does changing ChildList to ObjectList, and making [JointGroupTemplate] a sort of factory (which would require a factory concept) alleviate this problem? Would having some sort of generic instantiation grouping template that isn't itself an object be useful? Perhaps even specifying another object template as the group's shared parent? Or is that weird?

    Those sound like pretty heavy modifications for adding support to a single case (which is the last link of a cyclic chain).
  • epoulsenepoulsen
    edited June 2013
    Those sound like pretty heavy modifications for adding support to a single case (which is the last link of a cyclic chain).


    True.

    I could simply have my mapgen produce the described config section, and then write game code to manually instantiate objects & joints.

    I was hoping for a fully data-driven solution, but custom (yet generic) code is fine.
  • iarwainiarwain
    edited June 2013
    And you still have the compromise of having a full data driven option by using a TrackList to create the last joint. :)
  • epoulsenepoulsen
    edited June 2013
    I'll admit tracks/timelines are a complete mystery to me.
  • iarwainiarwain
    edited June 2013
    Then a new world might open to you soon. ;)

    A good start would be the post I made on the orx-dev group.
  • epoulsenepoulsen
    edited June 2013
    Seems kinda FORTH-y, but without operators.
  • iarwainiarwain
    edited June 2013
    I've never used FORTH myself so I trust you on that judgment. :)

    Operators are commands as well. You can try them by opening the console (by pressing the backquote [`] key in game), and then type (no spaces after the commas in the vector!): 
    + (1,2,3) 2

    The result will then be (3, 4, 5).
    If you want to use spaces when typing vector parameters, you have to surround them with double quotes ["]: 
    * "(1, 2, 3)" "(4, 5, 6)"
    Which will give (4, 10, 18).
  • iarwainiarwain
    edited June 2013
    In our specific case, we'll need the Object.AddJoint/Object.RemoveJoint commands, which don't exist yet but should be easy to add if you want to go down that road.
Sign In or Register to comment.