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..

[0TK]

On a side note, did you see this issue #232 about allowing customized constraints?

Yes, I did read this and some other issues before posting. And looked deeper into it when you asked.

If this was a working feature, could you solve the problem here with a new customized joint to connect the bodies together?

Seems that…

• it could help make a partial solution more straightforward and less of a hack
• it would help implement other related things

however

• a full proper solution would generally require a different approach ( even if it might be facilitated by this feature in some ways )

.

---

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

Yes, your description seems to match.

you can confirm if something like this is what you are looking for.

Yeah, something like this.

[0TK]

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.

• this would allow to avoid iterating over all contacts and other constraints involved because that PivotJoint captures all pushing-pulling forces|impulses due to counteracting them ( and the RotaryLimitJoint captures lateral forces, possibly in angular|torque form )
• it could be possible to get velocities to work, however this would mean manually duplicating simulating more of what the physics engine does
• because the same "synchronizing constraints" are used both for detecting forces from different sources and applying synchronizing forces accordingly, there could be some self-affecting feedback from the previous time step to be taken care of for correct results
• there is a question of whether velocity damping and acceleration limiting would be properly captured as forces by the synchronizing constraints
• Velocity damping might end up being applied multiple times, once per each body, even though they are linked. Damping factors could have to be adjusted to compensate for this.
• this solution has shortcomings :
  • there can be a noticeable delay before synchronization
  • large enough forces could override effects of the synchronizing constraints and keep the linked bodies in locations that are not equivalent even for a long time

[0TK]

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

Some ideas I got:

* `impulse_vector`

Generally, I was thinking of something like this, too.

or maybe impulse_vect

If we are considering abbreviations, another way would be 'vtr', as in impulse_vtr or impulseVtr.

* `impulse_signed` or `impulse_scalar`

or impulse_directed ( which is a little longer, though )

(so depending on the type of constraint the property would be named differently (and return different thing ofcourse)

Or some constraints could return a one-dimensional vector, if this makes logical sense. Then the names wouldn't necessarily have to be different ( or could be like impulse_vtr1 and impulse_vtr2, according to dimensionality ).

---

by the way : I was considering that information about directions of impulses applied by constraints could help to implement a ( possibly temporary ) partial solution and some motivating examples, while a full proper solution ( which in itself may not need to discern impulse directions ) might take more work and discussion( about implementation details, different use cases,.. ).
Now, there already seems to be at least one example, though :)

[aatle]

Popping in for naming suggestions, I would advocate for impulse_vector (no abbreviation), similar to Body.rotation_vector. But if an abbreviation is desired, it should be impulse_vec to align with pymunk's Vec2d.

[viblo]

Just a heads up, I started to implement the property. Once I have something I'll share a branch here so you can try it out.

…

On Mon, Nov 17, 2025, 23:06 aatle ***@***.***> wrote: *aatle* left a comment (viblo/pymunk#295) <#295 (comment)> Popping in for naming suggestions, I would advocate for impulse_vector (no abbreviation), similar to Body.rotation_vector. But if an abbreviation is desired, it should be impulse_vec to align with pymunk's Vec2d. — Reply to this email directly, view it on GitHub <#295 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJD2CDHZASZI3CGUTTAQNT35JBIDAVCNFSM6AAAAACKOHIBRKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNBUGAZTSNBYGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>