Discerning between pushing, pulling and lateral Impulses applied by Constraints

[0TK]

Greet you!

"Constraint.impulse" in Python returns just a positive magnitude. This seems to be confirmed also by joint implementation code at, for example...
https://github.com/viblo/Munk2D/blob/master/src/cpPivotJoint.c#L76
For each joint type, it returns either of...

• cpvlength(joint->jAcc)
• cpfabs(joint->jAcc)

How to obtain information about the direction of an impulse applied by a constraint?

If such information is not accessible, perhaps it would be possible to expose it.
For a logical interface, the result could be in the frame of reference of the constraint's axes of acting or degrees of (non-)freedom ( determined by anchor points for some constraints ). There could be separate properties for pushing-pulling and lateral impulse components or one returning a vector.
However, it seems that simply exposing joint->jAcc if it is in some other frame of reference ( like relative to the space ), so that it could be transformed manually, would still be better than this information not being obtainable at all.

Best wishes!

[viblo]

To better understand what would be a good implementation, do you have a specific use case for what you want to do with the direction/vector?

[0TK]

Generally, would like to link together ( at least two ) bodies ( in the same or separate spaces ) in such a way that…

• positions and angles ( relative to different frames of reference, determined by dynamic or static reference|"parent" bodies ) of two linked bodies should remain equal, ideally without any noticeable delay before synchronization
• all forces( from collisions and constraints ) applied to either body should still work ( affecting both of them, as if it was the same body )

I've been trying to implement this with a potentially simplifying assumption that the positions of both of the bodies happen to be constrained to move along a corresponding channel( relative to the corresponding reference body ) for each body. ( -- Kind of like sliders in a graphical user interface linked together to display the same value. However, the sliders as a whole can have different( potentially dynamically changing ) angles and positions relative to each other. )

[viblo]

Just to double check: You cant solve your problem by just using two shapes attached to the same body?

[0TK]

Hello, @viblo !

It seems that if this would work then in a very limited case, which is unlikely to occur in practice. Limitations could be at least that...

• all reference|"parent" bodies would have to...
  • have the same angle — only a translational shift would be possible
  • be constrained to have no motion relative to each other or be fully static
• the linked logical bodies ( represented as shapes of a single PyMunk body ) would have to...
  • be constrained not to have any rotation
    or
  • be circles with zero friction and no constraints causing rotation
• everything would have to be in the same space

[viblo]

I'm still not sure I fully get what you mean.

The space part I get, a body or constraint can only exist in one space at a time. So unless two bodies are aligned together "manually" each step from the outside, the bodies/shapes have to be in the same space so you can use normal constraints or a single body with multiple shapes. I guess this manual aligning of the bodies is what you want to use the direction of the jAcc value for?

But then you list a number of other downsides with using a single body with multiple shapes which I don't really follow. If the bodies experience the same forces, wont it be the same as a single body?

On a side note, did you see this issue #232 about allowing customized constraints? If this was a working feature, could you solve the problem here with a new customized joint to connect the bodies together? (As I think I mentioned in that issue it does come with some other downsides of course, but still)

Hello, @viblo !

It seems that if this would work then in a very limited case, which is unlikely to occur in practice. Limitations could be at least that...

* all reference|"parent" bodies would have to...
  
  * have the same angle — only a translational shift would be possible
  * be constrained to have no motion relative to each other or be fully static

* the linked logical bodies ( represented as shapes of a single PyMunk body ) would have to...
  
  * be constrained not to have any rotation
    or
  * be circles with zero friction and no constraints causing rotation

* everything would have to be in the same space

[viblo]

If I expose the jAcc, do you have some naming ideas?

Some ideas I got:

• impulse_vector or maybe impulse_vect
• impulse_signed or impulse_scalar
  (so depending on the type of constraint the property would be named differently (and return different thing ofcourse)

[0TK]

By the way, I've tried to clarify this message with some edits…

• Discerning between pushing, pulling and lateral Impulses applied by Constraints #295 (comment)

If the bodies experience the same forces, wont it be the same as a single body?

Their positions and angles are relative to different frames of reference, determined by ( dynamic or static ) reference|"parent" bodies. -- Meaning that, if this was implemented simply as "two freely moving bodies with all forces experienced by each also being transferred to the other", the transferred forces would have to go through a transformation from one frame of reference to another before being applied. ( Such an implementation wouldn't prevent the bodies' positions from drifting out of sync soon. )

I've been trying to implement this with a potentially simplifying assumption that the positions of both of the bodies happen to be constrained to move along a corresponding channel( relative to the corresponding reference body ) for each body. ( -- Kind of like sliders in a graphical user interface linked together to display the same value. However, the sliders as a whole can have different( potentially dynamically changing ) angles and positions relative to each other. )

In this example, the linked bodies would correspond to the moving heads|knobs of the sliders, reference|"parent" bodies would be some part of the surrounding frame of each slider.
A kind of interesting partial solution can be implemented by connecting each body to their reference body by constraints( like a combination of PivotJoint and RotaryLimitJoint ) with anchor points dynamically adjusted to match a shared position value which changes proportionally to forces|impulses experienced by those same constraints.

I guess this manual aligning of the bodies is what you want to use the direction of the jAcc value for?

Yes.

[viblo]

Did you check the custom constraint #232 ? If this was a working feature, could you solve the problem here with a new customized joint to connect the bodies together? (As I think I mentioned in that issue it does come with some other downsides of course, but still)

[viblo]

I tried to make a small example, and now I think I understand what you are after.

Lets say you have two sliders in a UI, one that goes left - right and another one that is up - down. If they were independent of each other you could make each slider with for example a groovejoint and a rotarylimit joint between the "sliderknob" and the "sliderframe".

But in your case you want to connect the two sliders, so that moving the knob of the left-right slider to the middle of the slider, would also move the up-down slider to the middle. And so on. And this connection should continue to work even if I take the top-down slider and rotate it 25 degrees

[viblo]

I made a very basic example from this method using velocity. Didnt feel that good, but post it here anyway for reference https://gist.github.com/viblo/0b4b9521312425b3463b39063335cda2
If nothing else you can confirm if something like this is what you are looking for.

But I wonder if it will be possible to make a good solution without a custom joint for this. Normally the joint applies its cached impulse first, then there's a loop that applies impulses from the arbiters and constraints for X iterations..