The spring is a deceptively difficult problem.
First thing we have to admit is, this is essentially a physical process, involving collisions, and any rigging is going to be an approximation of the real behavior at best. Second thing we have to say is that the problem is probably not well defined, because since this is a curved spring, we’re not maintaining any easy lengths-- at best, the length of the entire curve of the spring is going to remain constant, but we won’t be able to maintain that length without creating a horrible mess.
Even once we say okay to all of that, we still have a difficult problem, which is that the position of the end of the spring, in a reasonable approximation, is going to be the intersection of a sphere and a line, and there aren’t any easy constraints to give us that.
So, here’s the first draft, demonstrating both the complexity necessary and the issues with the first draft (which are fixable, but you have to understand the base thing before worrying about those):
Root, arm should be pretty understandable; those are the two arms of our scissors.
Spring1 is parented to root, spring2 is parented to spring1. Spring object gets an armature deform, while everything else is just bone parented. Spring2 tracks a marker bone. Here, I’m using a 1-chain IK to track it, but damped track or track to or locked track would be fine instead.
The marker bone is where it gets complicated. Floor is parented to arm, and then shrinkwrap projects to a non-rendering hemisphere. That hemisphere is parented to spring1, at the location of the origin of Spring2, and has a radius equal to the length of spring2. Because Floor is aligned with the mesh that hits the spring, we’re finding the intersection of the line described by the arm and the allowable rotation of Spring2.
But then, we want the spring to stop if the arms open too wide. So rather than tracking floor directly, I’m tracking ikT. ikT is parented to root, then copies the location of floor, and then has a local-space limit location constraint on it (max X 0, max Y 0) that will keep it from moving past a certain point. That’s the bone that spring2 is tracking.
Note that spring1 is not automated. That’s what I meant when I said this isn’t totally defined. You can leave spring1 in its default position relative to its parent (root) and the whole thing works. You can also rotate spring1 a bit and the whole thing still works. In this case, leaving it be makes sense, but if we want it automated, we need to define the desired automated behavior. To match the video, probably the smartest thing to do would be to give spring1 a driver to give it rotation from the rotation of arm, and then tune that driver’s curve to eye, but I didn’t do that in the file below.
As I said, it’s a deceptively complicated problem.
I mentioned there’s a bug here. You can see that the spring is self-intersecting. We can fix that if we want, once you decide that this level of complexity is what you want, and once you understand that complexity. We’ll create some sub-bones for the spring, reweight it to those, and floor those to a midpoint marker. Not hard. However, it will mean that our lengths will become even less fixed than they are here.
start-02.blend (1.0 MB)