Page MenuHome

Bullet spring2 tends to explode at high damping and stiffness
Closed, ResolvedPublic

Description

I did some tests with the new "spring2" constraints in Blender 2.79 master in order to make them work for our BCB add-on development and I noticed a serious instability issue with them. In larger structures with high stiffness and damping they cause strong jittering and explosion effects. And when stiffness and damping is reduced enough so that they don't explode, they are already too weak to keep something in place. This wasn't the case with the former springs.

Blend:

This .blend file contains a structure with springs, which will show a slow deformation behavior in the latest official Blender 2.79 release. The same file simulated in 2.79 master branch, however, will make everything explode instead. You can reduce the stiffness to something like 10,000, then it only jitters but at the same time it looks like nothing is connected anymore.

I couldn't find an actual advantage over the old springs, which at least were stable at all times. In case this is not considered a bug, I'd ask to make the spring type optional at least to offer the user a way around this limitation.

Event Timeline

Initially I wanted to expose access to both types of springs, but @Sergej Reich (sergof) suggested to try just switching to the new one first, and that went in as D3125. Maybe exposing both is better after all.

Alexander Gavrilov (angavrilov) lowered the priority of this task from Needs Triage by Developer to Normal.Jul 14 2018, 3:02 PM

The advantage of the new springs is that you can actually create stiff springs.
This is a bug in bullet, so it should also be reported there.
As for how to handle it in blender. I'd really like to avoid having 2 generic spring constraints.
So if the new one doesn't work well and can't be fixed, just revert the change and continue to use the old one.

I'm absolutely against reverting, because damping in the old constraint is junk.

Btw, looking at this file more, it actually relies on this junk damping behavior to work. With the old constraint setting damping all the way to 0 (1 in blender UI) completely kills a velocity term in the computation, which I expect is totally nonphysical, and yet this test file relies on it to achieve the observed behavior. If you set damping values to 0.999999, it actually stops collapsing and becomes all jiggly-bouncy but stable. Set it to 0.99999 or smaller, and the bounce self-amplifies and eventually explodes even with the old constraints.

And now after some more testing, observations re new springs:

  1. Judging from the code, new springs are supposed to have safeguards that automatically reduce stiffness & damping to prevent them from exploding. However, it seems that it only works properly for linear stiffness, while any other parameters easily make it explode if too big.
  2. With the original settings it actually explodes from angular stiffness - if you try with somewhat reduced values and step frame by frame, you can sometimes see some individual objects start rotating weirdly a frame or two before it all explodes.
  3. With 2000 steps per second, spring linear stiffness 1e+14 (likely auto-clamped), angular stiffness 1e+7, linear damping 7000, angular damping 10 the structure doesn't explode and stands there bouncing.

Regarding old springs, I have a feeling that with damping 1 it may actually be in effect simulating plastic transformation with resistance, rather than a spring.

At first:

  • I can confirm that the instability is happening also with the old springs as soon as the damping value is close to but smaller than 1.
  • Also I found out that explosions are only happening for angular springs, linear springs seem to be stable even with spring2. (Maybe a general angular spring bug/limitation?)
  • After some further tests suggested by Alexander, I agree that the new springs are actually showing better damping behavior for linear springs.

I'm in difficult position now, because we (the BCB team) indeed use highly damped springs to replicate plastic deformation within the BCB structural simulation software we developed over the past 3 years. We developed formulas to define a stiffness from the observed behavior when damping = 1 in order to make it work in a somewhat physical way for us. So even when this is not physical per se for a spring, this "flaw" in spring1 helped us to achieve the desired behavior of a deformable connection either way.

Now with the new springs it becomes obvious that we would lose this option for the BCB in the next official Blender release. In an earlier stage of development (before we had angular springs in Blender) we used an array of linear springs to connect two elements in order to replicate plastic deformation, since back then this was the only way to damp rotation for springs at all. It looks like that this method would still work, however, the disadvantage is that you have to use three or four times of the number of spring constraints to achieve the same result, hence my reluctance to go back.

All I can say is that I'm extremely interested to keep the option to have stable damping for the angular component for such structures without having to maintain an own Blender build. I'm just not sure about the best way to solve that. I can see following options:

  • Ideally the angular springs should become more stable in general if possible, of course. Perhaps something isn't working right there that still can be fixed?
  • Or the spring type could be optional, even if only for these kinds of special cases.
  • Or maybe there could be a convention to replicate damping = 1 behavior (eliminating velocity) for spring2 when a specific value is set, like -1. I dislike that kind of hacks, though.

So basically what we have here isn't that new springs are broken or something, but primarily that the old ones have a weird implementation of damping, which has a quirk that with the value exactly 1 the spring turns from a spring into something more like plastic deformation, or a spring combined with a ratchet that only extends depending on force and doesn't actually spring back (to get it to move back you actually need to apply opposing external force higher than the one that caused extension).

Thus you could say that effectively the old springs have an undocumented built-in semi-plastic deformation constraint feature. The new ones on the other hand have a feature of damping actually working like real physical damping. This could be viewed as an argument in favor of having both at least until there is an official plastic deformation constraint.

It's not exactly the case that we just used something not intended to be used in this way, because when I was testing the idea of plastic deformation for the first time, I actually assumed it would work even for smaller values of damping in a similar fashion. I actually expected that it would swing back and forth a little and I would have accepted that even. But since we wanted to minimize the swinging motion it was a logical step for me to set the damping to the maximum, which worked as expected.

That angular springs now react that chaotic is basically the core problem here. Because if it would work with *some* damping it would already be great, but it almost doesn't work with any (noticeable) angular damping in this case. For this particular reason I would see the damping = 1 trick more or less as a workaround for the actual problem.

Having said that, however, it leads me to the same conclusion that we should make it basically optional which spring type one want to use, with spring2 the default maybe.

I find the generic spring constraint to be the most useless of all the constraints, having 2 of them is just silly.
I wouldn't mind too much if the spring constraint had a type field that would be set to the old spring behaviour for old files and default to the new behaviour for new constraints.

Regarding angular springs not being stable, it's not that they are more unstable than linear ones. As I mentioned, it is just the case that unlike linear springs they don't effectively clamp stiffness to prevent exploding. This video was computed with exact same settings as the previous one, except for using 3000 instead of 2000 steps per seconds; yet the oscillation frequency changes. This is because linear stiffness is clamped and increasing step count increases the actual effective stiffness.

@Sergej Reich (sergof): if you don't want two spring constraints, how about just a 'legacy mode' checkbox in the blender spring constraint?

Edit: for some reason I didn't get email notifications and thus didn't read the two previous comments before posting this one.

@Alexander Gavrilov (angavrilov) Having a drop down menu to select the spring type, like I mentioned above, should be fine.

@Alexander Gavrilov (angavrilov) Having a drop down menu to select the spring type, like I mentioned above, should be fine.

Given that the original constraint names are "spring" and "spring 2", naming is something of a problem though.

Thank you.

Not everything is useless that you don't use. ;)

Seems like it would be worth considering to make clamping itself optional, too. I guess this would communicate the very fact that clamping is happening even better to the user. Just a thought, though.