Bullet spring2 tends to explode at high damping and stiffness #55958

New Issue

Kai Kostack · 2018-07-12T22:36:49+02:00

Kai Kostack commented

2018-07-12 22:36:49 +02:00

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: bug_spring2.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.

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: [bug_spring2.blend](https://archive.blender.org/developer/F3919878/bug_spring2.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.

Kai Kostack commented

2018-07-12 22:36:50 +02:00

Added subscriber: @KaiKostack-3

Alexander Gavrilov commented

2018-07-13 10:33:51 +02:00

Added subscribers: @sreich, @angavrilov

Alexander Gavrilov self-assigned this 2018-07-13 10:33:51 +02:00

Alexander Gavrilov commented

2018-07-13 10:33:51 +02:00

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

Initially I wanted to expose access to both types of springs, but @sreich suggested to try just switching to the new one first, and that went in as [D3125](https://archive.blender.org/developer/D3125). Maybe exposing both is better after all.

blender-admin commented

2018-07-14 16:01:02 +02:00

This issue was referenced by ec640510a8

This issue was referenced by ec640510a8c8ef5de8daea907da2351ef1988915

Sergej Reich commented

2018-07-14 17:18:25 +02:00

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.

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.

Alexander Gavrilov commented

2018-07-14 17:19:27 +02:00

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

Alexander Gavrilov commented

2018-07-14 17:49:09 +02:00

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.

Alexander Gavrilov commented

2018-07-14 19:04:35 +02:00

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

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.
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.

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.

And now after some more testing, observations re new springs: - 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. - 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. # 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 ](https://www.youtube.com/watch?v=bAPwcbngiWQ). 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.

Kai Kostack commented

2018-07-20 18:05:57 +02:00

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.

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 ](https://github.com/KaiKostack/bullet-constraints-builder) 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. ![BCB-spring-array.jpg](https://archive.blender.org/developer/F4000226/BCB-spring-array.jpg) 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.

Alexander Gavrilov commented

2018-07-20 20:20:04 +02:00

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.

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.

Kai Kostack commented

2018-07-20 21:02:13 +02:00

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.

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.

Sergej Reich commented

2018-07-20 22:03:59 +02:00

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.

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.

Alexander Gavrilov commented

2018-07-20 22:31:43 +02:00

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 [ https:*www.youtube.com/watch?v=bAPwcbngiWQ | 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.

@sreich: 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.

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 [[ https:*www.youtube.com/watch?v=bAPwcbngiWQ | previous one ](https:*www.youtube.com/watch?v=9Prf_dP21LY), 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. @sreich: 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.

Sergej Reich commented

2018-07-21 07:26:40 +02:00

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

Alexander Gavrilov commented

2018-07-21 09:03:28 +02:00

@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.

> @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.

Kai Kostack commented

2018-07-21 11:10:21 +02:00

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.

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.

Alexander Gavrilov commented

2018-07-24 09:18:02 +02:00

Changed status from 'Open' to: 'Resolved'

Alexander Gavrilov closed this issue

2018-07-24 09:18:02 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Bullet spring2 tends to explode at high damping and stiffness #55958

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 .