@Miquel yeah it’s all in C++, it’s not a lot of lines. It just took me a while to figure out the logic issue. It’s a simple fix in hindsight. I kept recompiling the plugin until I figured out what was the issue.
1 Like
Hey @Miquel I finished fixing up the bug and created a pull request. Here is the the stretch working with and without the softness. 
The only change that has to be made in shifter is to change the Max Stretch attribute from Min 1 Max 99 to Min 0 to Max 1. It should work perfectly after that. Previously built rigs will just need to adjust it in Edit Attributes in maya. Should not break anything.
I’ve never used GitHub before so I hope I did this correctly. If not i can attach the source code here directly.
2 Likes
Awesome! @dew Thanks for the PR! 
I will check it ASAP, but I may take a little to integrate it. I want to test it carefully with a few production rigs to ensure no surprises 
NOTE: The PR arrived perfectly 
Ty! @Miquel it should work the same the only caveat is there would need to just be the change in shifter and in current rigs the Min Max of Max Stretch would need to be set to 0 and 1 respectively. Thank you for allowing me to fix this. I feel really good about it and no worries, take all the time you need to integrate it I want to make sure it works for everyone.
2 Likes
Great work! I haven’t compiled to test, but I watched you working through this on Discord, and it looks like it will behave a lot better!
My only concern is that I think you’ve change the meaning of “Max Stretch” from clamp to multiply.
Max Stretch is a way to limit/clamp how far the arm stretches. If you had it set to 2.0, the arm would double in length before reaching the end and then no longer stretch. 1.0 meant it would reach the length of the arm and then stop stretching. (Equivalent to not stretching, but not the same thing as multiplying it off.)
If you’ve set it to 0-1, does that mean it is basically a percentage blender from OFF to ON? Meaning if you have it set to 0.9, the arm will 90% reach the length of the goal.
I personally never used Max Stretch as a clamp. The animators always wanted it cranked to 99 so the arm would just stretch indefinitely. But this does change the meaning, so it is worth double-checking that that was the intention.
It might be better to ADD an attribute “stretch”, or “stretchOffOn” that would turn the stretch on and off from 0 to 1 like you’ve done. And then maintain Max Stretch as a clamping/limit on top of that. This might help prevent any unintended changes to the rig behaviour.
Hey Chris. Yeah that’s exactly what I did since it required the least amount of large changes to the node itself and seemed to be the most non destructive.
Adding a node attribute would require a few changes in everyone’s rig. As an animator I don’t understand the purpose of clamping the stretching distance in that way. Normally I only ever have the stretch on or off or a multiplier making it go from off to fully on. This made the most sense to me mathematically and logistically. However that does change the purpose of max stretch to just stretch. Which is what I think the majority of stretchy arm rigs use is just an on/off function.
If absolutely necessary I can go back in and tinker with adding another attribute to turn the stretch feature off and on and a multiplier. I feel this may borderline on redundancy but I’m pretty utilitarian with my rigging. My first impression with max stretch function was confusion as 1 meant no stretch and up to 99 was infinite stretching.
Just let me know what you think. I’m not sure how to ask the general community what they would like me to do to make this as least destructive as possible and the most accommodating.
I think you are right. And personally, I think clamping the result is pretty useless too. But do keep in mind that these components don’t need to be used for just organic biped characters. You can’t imagine all the ways people could use them.
Adding an attribute wouldn’t change any existing animation. Since stretch is on by default, have “stretch” set to 1.0 would mean the result was the same.
Changing the meaning of the math could potentially change existing animation, especially if you’re baking it into the solver, where it could even potentially change the animated results of a rig that wasn’t rebuilt. (As far as I can imagine.)
That said, maybe the solver would also need to ignore the new “stretch” attribute if it didn’t exist, on a rig that hadn’t been rebuilt. Otherwise old rigs might break. (Sorry for complicating this! I hope some other people chime in, or there is an easy answer I’m not thinking of.)
Yeah I would def want to get some feedback and input from folks so I can gather a general idea of what people want me to do. The bug itself is fixed so it would just mostly be me adding a new attribute, which is a lot of new lines of code to do. And I would need to make a few adjustments to each shifter component to make sure it properly hooks everything up. The distance clamp would need to be a separate function. To return a max value, just guessing off the top of my head rather then using that as a ratio for the stretch itself, which is how it functioned before.
Would I need to make a new topic? What would be the best way to ask and notify everyone of this suggestion. I’m willing to do it since I now have a very good understanding of how the solver itself works and the math involved.
That does sound like a lot of work. 
Maybe there is a way to tweak the formula, so it doesn’t ultimately care what the Max Stretch is?
The distance could just be relative to the restLength of the bones. Then no matter what your formula is, the softness range is just relative to the restLength. If it extends to 99, then after the extra softness distance, (say 1.1x for example) it just stays straight. 1.1 to 99.0 would just be straight. The softness only needs to operate on that small range, ever.
So I’m proposing (if this is possible) to put Max Stretch back to how it was (1 to 99). Change the formula so it doesn’t care about Max Stretch. And then avoid adding any new attributes.
I do understand that some stretch needs to be there, in order for the softness to reach a straight result. But if Max Stretch was set to 1.0, then it just wouldn’t be possible to reach completely straight. But that’s fine. That’s just a limitation of the softness extension formula.
(I’ll try to stop replying now, and leave room for other opinions! 
)
I do understand that some stretch needs to be there, in order for the softness to reach a straight result. But if Max Stretch was set to 1.0, then it just wouldn’t be possible to reach completely straight. But that’s fine. That’s just a limitation of the softness extension formula
This is actually a misnomer, no stretch needs to be there for soft IK to function. The way soft IK works is by lagging the distance behind the controller, there is actually no stretch involved whatsoever. This was why there was a bug in the first place since the logic dictated the stretch was dependent on the softness, which is not true.
I can make the max stretch behave like a clamp but I think for most animation purposes a traditional stretch being on and off from 0 to 1 needs to be there. It’s confusing for an animator to see 1 as no stretch and 99 as infinite and in a rig it’s always good to ask if what we’re doing is redundant. I can make them both work but it does beg the question if the max stretch is 1 no stretch will happen, and if the stretch is 0 no stretch will happen, so an animator has to know to have the max stretch above 1 and the stretch value itself at 1 for the function to take full effect. The only other logic would be to have a Boolean instead for the stretch to say on or off so it’s more logistical to function in tandem with the max stretch.
Again this is why I wanted to see if I could ask the community what would best suit them or make the most sense.