A persistent bug in IK-chains
If a man's hands are IK-parented to something (say a 2-handed gun), and the arms are set to IK-on, and the gun is ordinary-parented 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 joint-blending 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 3-dimensional trigonometry, which to find the hand-to-forearm rotate angles needs inverse-trig functions (arcsin, arctan, etc), and inverse-trig 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 forearm-to-hand 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 IK-parented 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 M-N 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 180deg-Q, 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.
x0 = original x y0 = original y z0 = original z
:: First rotate by X around the x-axis:- x1 = x0; y1 = y0cos(X)-z0sin(X); z1 = y0sin(X)+z0cos(X)
:: Then rotate by Y around the y-axis:- x2 = z1sin(Y)+x1cos(Y); y2 = y1; z2 = z1cos(Y)-x1sin(Y)
:: Then rotate by Z around the z-axis:- x3 = x2cos(Z)-y2sin(Z); y3 = x2sin(Z)+y2cos(Z); z3 = z2
:: Substitute the X-rotation in the Y-rotation:-
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 X-and-Y-rotation in the Z-rotation:-
x3 = x2cos(Z)-y2sin(Z)
y3 = x2sin(Z)+y2cos(Z)
z3 = z2
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 180deg-Y, Z by Z+180deg
x3' = y0*-sin(X)sin(Y)-cos(Z) + z0*-cos(X)sin(Y)-cos(Z) + x0*-cos(Y)-cos(Z) - y0-cos(X)-sin(Z) - z0-sin(X)-sin(Z)
y3' = y0-sin(X)sin(Y)-sin(Z) + z0*-cos(X)sin(Y)-sin(Z) + x0*-cos(Y)-sin(Z) + y0-cos(X)-cos(Z) - z0-sin(X)-cos(Z)
z3' = y0-sin(X)-cos(Y) + z0-cos(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 180deg-Y, 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 IK-parented 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 normal-parent when the chain is set to IK-on, 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 IK-on, and John's right hand is IK-parented to some part of Mary, that would seem to avoid having an IK-loop. 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 IK-parented to.
Likewise, in the default initial case of John's legs being IK-on and his feet are IK-parented to his BODY, an IK- loop still exists: from a foot down the IK-parentage 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 IK-loops 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 IK-chain whose end is IK-parented to his head), and 2-handed tools and weapons, and backpack spray-packs, 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 IK-goal and its normal-parent when the chain is set to IK-on, whether or not the IK-loop runs through a part that does not have geometry or a bone, after calculating the angles between the IK-goal and its normal-parent 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 artificially-made 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 officially-written 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.
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 hand-to-gun 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 IK-parented to a mouthpiece or fullface mask, and the last joint in the loop (from the IK-parent (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 IK-loops is that often the angles (and translates, if any) at each member of the loop, does not bring the IK-goal to the desired relationship to its IK-parent. 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 IK-goal is so far from its IK-parent 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 IK-parent and its normal-parent is a soft substance (flesh, or rubber hose, or etc.) and thus has joint blending.