A persistent bug in IKchains

If a man's hands are IKparented to something (say a 2handed gun), and the arms are set to IKon, and the gun is ordinaryparented to his chest, then each hand's rotates and translates now state its position relative to the gun, and not the position relative to the forearm.
But the hand's position relative to the forearm is needed to display the wrist's jointblending correctly. And that must be found by running from the forearm back up the arm and around the tree of parts and thus at last to the gun and the hand, by 3dimensional trigonometry, which to find the handtoforearm rotate angles needs inversetrig functions (arcsin, arctan, etc), and inversetrig functions generate multiple solutions, and the user must chose which solution is sensible.
(I have often done similar calculations at work in simulating behaviour of polymer molecules.)
Sometimes, if I move the arm or the gun, the calculated forearmtohand angles suddenly jump as the subroutine chooses another solution to these inverse trig functions, and the wrist now looks twisted and broken and mangled.
I get the same nuisance with scuba breathing tubes and suchlike, as the tube's end is IKparented to the diver's head.
To help the subroutine in choosing the best solutions to these calculations, I here point out that, if a part M has a child N, and the rotate angles at the MN joint are P Q R, all about axes at 90deg to each other, and the rotations are by angles P then Q then R in that time order, then, if I replace P by P+180deg, Q by 180degQ, R by R+180deg, then N ends up in the same position compared to M; but the joint blending between M and N is changed.
Proof:
x0 = original x y0 = original y z0 = original z
:: First rotate by X around the xaxis: x1 = x0; y1 = y0cos(X)z0sin(X); z1 = y0sin(X)+z0cos(X)
:: Then rotate by Y around the yaxis: x2 = z1sin(Y)+x1cos(Y); y2 = y1; z2 = z1cos(Y)x1sin(Y)
:: Then rotate by Z around the zaxis: x3 = x2cos(Z)y2sin(Z); y3 = x2sin(Z)+y2cos(Z); z3 = z2
:: Substitute the Xrotation in the Yrotation:
x2 = (y0sin(X) + z0cos(X)) sin(Y) + x0cos(Y)
y2 = y1
z2 = (y0sin(X) + z0cos(X)) cos(Y)  x0sin(Y)x2 = y0sin(X)sin(Y) + z0cos(X)sin(Y) + x0cos(Y)
y2 = y0cos(X)  z0sin(X)
z2 = y0sin(X)cos(Y) + z0cos(X)cos(Y)  x0sin(Y):: Substitute this resulting XandYrotation in the Zrotation:
x3 = x2cos(Z)y2sin(Z)
y3 = x2sin(Z)+y2cos(Z)
z3 = z2:: becomes
x3 = (y0sin(X)sin(Y) + z0cos(X)sin(Y) + x0cos(Y)) cos(Z)  (y0cos(X)  z0sin(X)) sin(Z)
y3 = (y0sin(X)sin(Y) + z0cos(X)sin(Y) + x0cos(Y)) sin(Z) + (y0cos(X)  z0*sin(X)) cos(Z)
z3 = y0sin(X)cos(Y) + z0cos(X)cos(Y)  x0sin(Y)x3 = y0*sin(X)*sin(Y)cos(Z) + z0cos(X)*sin(Y)cos(Z) + x0cos(Y)cos(Z)  y0cos(X)sin(Z)  z0sin(X)sin(Z)
y3 = y0sin(X)*sin(Y)sin(Z) + z0cos(X)*sin(Y)sin(Z) + x0cos(Y)sin(Z) + y0cos(X)cos(Z)  z0sin(X)cos(Z)
z3 = y0sin(X)cos(Y) + z0cos(X)cos(Y)  x0sin(Y)::Now replace X by X+180deg, Y by 180degY, Z by Z+180deg
x3' = y0*sin(X)sin(Y)cos(Z) + z0*cos(X)sin(Y)cos(Z) + x0*cos(Y)cos(Z)  y0cos(X)sin(Z)  z0sin(X)sin(Z)
y3' = y0sin(X)sin(Y)sin(Z) + z0*cos(X)sin(Y)sin(Z) + x0*cos(Y)sin(Z) + y0cos(X)cos(Z)  z0sin(X)cos(Z)
z3' = y0sin(X)cos(Y) + z0cos(X)cos(Y)  x0sin(Y):: which simplifies to
x3' = y0*sin(X)*sin(Y)cos(Z) + z0cos(X)*sin(Y)cos(Z) + x0cos(Y)cos(Z)  y0cos(X)sin(Z)  z0sin(X)sin(Z)
y3' = y0sin(X)*sin(Y)sin(Z) + z0cos(X)*sin(Y)sin(Z) + x0cos(Y)sin(Z) + y0cos(X)cos(Z)  z0sin(X)cos(Z)
z3' = y0sin(X)cos(Y) + z0cos(X)cos(Y)  x0sin(Y):: i.e. replacing X by X+180deg, Y by 180degY, Z by Z+180deg does not change the result.
(Also, the effect of changing any of the rotation angles by a multiple of 360deg.)
That will give you more choices for the best of the sets of angles found by working round the chain as described above.

I would parent the gun to the trigger hand and parent the hand holding the barrel to the gun. Would that solve your problem?

The bug would still happen elsewhere. It also happens with a breathing set's breathing tube, whose goal end is IKparented to its wearer's head. I make many images of scuba diving. The matter is, when calculation as described above shows the rotation angles between the goal and its normalparent when the chain is set to IKon, to get a more sensible set of angles, try: Add 180 degrees to all 3 angles. Then change the sign of the angle which is second in order of what order to rotate about the angles: X for ZXY or YXZ, Y for XYZ or ZYX, Z for XZY or YZX.

(As well as adding or subtracting 360 degrees to/from each angle to get it as near to 0 as can be managed.)

in trying to reproduce this issue I post M3 with a shotgun prop. I can parent the gun to one hand but not sure how to set up hand IK to lock onto anything. I don't really use IK at all.

if I remember correctly, IK Loops are not supported in poser.. and thats what your trying to do... (arm to gun, arm to gun, forms a loop)

If there are 2 figures, named say John and Mary, and neither is parented to the other, and John's right arm is set to IKon, and John's right hand is IKparented to some part of Mary, that would seem to avoid having an IKloop. But all characters are parented to the UNIVERSE (if to nothing else), and a loop still exists: from John's hand down to his hip, and his BODY, and the UNIVERSE, and back up Mary to the part of her that John's hand is IKparented to.
Likewise, in the default initial case of John's legs being IKon and his feet are IKparented to his BODY, an IK loop still exists: from a foot down the IKparentage link to his BODY, and back through his hip and thigh and shin back to the foot.
(P.S. In this thread's title, "p3rsistent" is a mistype, not deliberate "leet". Sorry.)

no, universe and floor don't count as IK objects. only those with bones in the IK chain. if you put both hands onto a prop, that would form a loop. if you parent hands together, thats a loop. the legs are not a loop unless you try and join the feet together, as I said with the hands.

Intended or not, the ability to make IKloops has worked since at least Poser 4 times and has been extremely useful in scuba gear (a breathing set's breathing tube which is an IKchain whose end is IKparented to his head), and 2handed tools and weapons, and backpack spraypacks, etc. I feel that this ability should be kept and maintained.
The matter is, when calculation as described above shows the rotation angles between an IKgoal and its normalparent when the chain is set to IKon, whether or not the IKloop runs through a part that does not have geometry or a bone, after calculating the angles between the IKgoal and its normalparent by running round the loop, when looking for a more sensible set of angles, try: Add 180 degrees to all three angles. Then change the sign of the angle which is second in order of what order to rotate about the angles: X for ZXY or YXZ, Y for XYZ or ZYX, Z for XZY or YZX. (As an alternative to merely adding +360deg or 360 deg to one or more angles.)
There are another features that have been very useful in ways not intended:

The curve feature in a chain of parts, intended to get animals' tails right, is also useful to get hoses and flexible tubes of various sorts right.

The joint blend feature, intended to get human and animal articulations right, is also useful to get artificiallymade hoses and tubes to bend right.

Ability to parent one character to another: someone once told me that it is unintended, but it is very useful, and an officiallywritten Poser 3 or 4 manual mentioned the Poser casual woman (Posette) riding the Poser horse, by parenting her to the horse's chest.
Thank you for letting me take up your time with this matter.


I did take a look at the issue and found a possible workaround for you. I believe it IS a bug and needs to be brought to the attention of SM and the Poser team.
What I did was parent the gun to M3's right hand and then parented his left hand to the gun. As soon as the left hand was parented it got all twisted, but.... If you parent that hand, then move the right hand the way you need it and then turn off the left hand's parenting then it comes back into shape AND it is still posed where it needs to be holding the barrel end of the gun. Take a look at the pictures.

Anthony:
I realized that I could not see his wrist with the shirt on so here is a shot of his wrist with the shirt off and it look fine.

"it got all twisted" :: I have had that happen, hundreds of times. With the IK still set on, sometimes I change the hand's visible angles (= the handtogun angles) by adding + or  360 deg, or other experimentations, and it sometimes repairs the "smashed wrist" effect.
A nuisance that I have had with breathing sets is that the 2 breathing hoses (inhalent and exhalent) are IKparented to a mouthpiece or fullface mask, and the last joint in the loop (from the IKparent (the connection at the end of the hose) to the last hose segment before) is OK, but if I move the man's head a bit, the internal calculation round the loop flips to displaying another solution of the 3D trigonometry involved, and the hose joint crumples. Trigonometry involving inverse trig functions (arcsin, arccos, arctan, etc) are notorious for having many solutions.
Another complication with these IKloops is that often the angles (and translates, if any) at each member of the loop, does not bring the IKgoal to the desired relationship to its IKparent. Then Poser changes some of the ring's angles to make the ends of the loop meet. (For a similar process in handling rings in molecules, see https://en.wikipedia.org/wiki/Ring_strain.)
Here A is the angles as stated in each segment of the ring 's parameter dials, and B is the angles as changed to make the ends of the loop meet. The screen image is displayed using angles B. When that loop's IK is switched off, the angles B are written into the loop's members' parameter dials instead of angles A.
Sometimes when the IKgoal is so far from its IKparent that the loop's ends cannot be made to meet, a "ghost" outline of the hand is displayed at the correct relationship to the gun.

These problems with angles arise when the joint between the IKparent and its normalparent is a soft substance (flesh, or rubber hose, or etc.) and thus has joint blending.