Jump to content
  • Advertisement
Sign in to follow this  
Numsgil

Spring instabilities

This topic is 4883 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm making my own spring class based only in Forces (I don't want to handle energy unless I have to). The force from a spring is, of course, -kx - bv. (where x is the displacement from thge natural length). I'm modelling each end of a spring, so -kx -bv is applied to each end of the spring (is that right?) When I model my springs, I have some problems: 1. One end appears "fixed" in place when it is not. Later in the simulation it will move (see problem 2) but at first its only the other end that moves. There are no other forces yet in the simulation, so it's not static friction or anything like that. 2. After a while the springs will gain energy (I'm not directly measuring or handling energy in the simulation remember) and begin flying across the screen. Changing k and b just change how long it takes for the instability to occur. Is there a way to keep the energy of the system fixed without actually modelling energy? 3. What exactly is the v in -bv taken from? Is it v2-v1 where v2 is the "absolute" velocity of the other end of the spring minus the current end of the spring's velocity? Thanks.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by Numsgil
I'm making my own spring class based only in Forces (I don't want to handle energy unless I have to).

The force from a spring is, of course, -kx - bv. (where x is the displacement from thge natural length). I'm modelling each end of a spring, so -kx -bv is applied to each end of the spring (is that right?) When I model my springs, I have some problems:

1. One end appears "fixed" in place when it is not. Later in the simulation it will move (see problem 2) but at first its only the other end that moves. There are no other forces yet in the simulation, so it's not static friction or anything like that.

2. After a while the springs will gain energy (I'm not directly measuring or handling energy in the simulation remember) and begin flying across the screen. Changing k and b just change how long it takes for the instability to occur.

Is there a way to keep the energy of the system fixed without actually modelling energy?

3. What exactly is the v in -bv taken from? Is it v2-v1 where v2 is the "absolute" velocity of the other end of the spring minus the current end of the spring's velocity?

Thanks.


1: no clue

2: not really, but atleast you can ensure it always goes down. youre undoubtly using forward euler, which is unconditionally unstable. that or youre applying negative damping or something. google for something like 'explicit integration mass spring' to learn more about integrations schemes and which one suits your needs best. you could also look for implicit integration, but im affraid its over your head.

3: just the one velocity vector minus the other. however its not hard to see that doesnt have the desired effect for a rotating spring, so you should substract the part peridendicular to the spring itself if you dont want any artificial damping of rotations.

Share this post


Link to post
Share on other sites
Quote:

you could also look for implicit integration, but im affraid its over your head.


Actually I studied this last year. I'm a math major. But I can't say I'm comfortable with it yet (or have used it since). I'll see what I can do.

Quote:

3: just the one velocity vector minus the other. however its not hard to see that doesnt have the desired effect for a rotating spring, so you should substract the part peridendicular to the spring itself if you dont want any artificial damping of rotations.


What about ( <u,v> dot (v2-v1) * b) = Force. <Fx,Fy> = <u,v> * Force. Where <u,v> is the normalized position vector of the spring. Does that take everything into account?

Share this post


Link to post
Share on other sites
Forward Euler actually is conditionally stable, meaning it works for some problems. For spring forces only (the kx part), then that doesn't meet the stability condition and so forward Euler is unstable for these problems. But, Numsgil has included damping (the bv part) in his force, and appropriate damping puts forward Euler into the realm of stable methods. Possible issues are:

1) time step too large. For forward Euler, actually for any explicit method, time step cannot be too large. All of these are unstable if time step too large.

2) Damping too small. Might have to increase b to be able to use a reasonable time step. If b is too small, that reduces the size of the time step needed to make it stable.

3) velocity in the wrong direction. The sign of v depends on which object you're looking at. The force is equal but opposite on each object. The idea is that the bv term should act in the opposite direction of the velocity of one object relative to the other. So, if obj 1 is moving towards obj 2, the sign of the bv term should push away from obj 2. Does that clarify the bv term?

Share this post


Link to post
Share on other sites
Quote:
Original post by Numsgil
Quote:

you could also look for implicit integration, but im affraid its over your head.


Actually I studied this last year. I'm a math major. But I can't say I'm comfortable with it yet (or have used it since). I'll see what I can do.

sorry, excuse my quick asumption. if you think implicit integration is something you could do in the time youre planning to put into this, i would most certainly recommend it. explicit integration is always only conditionally stable, so certainly in an interactive customizable game envirnoment its hard to guarantee stability, and it will probably be a process of compromises and conforming to the lowest common denominator.

Quote:

Quote:

3: just the one velocity vector minus the other. however its not hard to see that doesnt have the desired effect for a rotating spring, so you should substract the part peridendicular to the spring itself if you dont want any artificial damping of rotations.


What about ( <u,v> dot (v2-v1) * b) = Force. <Fx,Fy> = <u,v> * Force. Where <u,v> is the normalized position vector of the spring. Does that take everything into account?

yeah that looks correct.

Share this post


Link to post
Share on other sites
Quote:
Original post by grhodes_at_work
Forward Euler actually is conditionally stable


ofcource :)

what i meant to say was undamped forwatd euler is unconditionally unstable, but that makes little sense in the context he already said he implemented damping.

Share this post


Link to post
Share on other sites
I can get the springs to stop oscillating fairly easily. The problem is that the whole spring begins accelerating in a specific direction. It's acquiring kinetic energy from itself somehow.

It probably is a mathematical instability. I'll see if I can use a better method.

Share this post


Link to post
Share on other sites
Quote:
Original post by Numsgil
I can get the springs to stop oscillating fairly easily. The problem is that the whole spring begins accelerating in a specific direction. It's acquiring kinetic energy from itself somehow.

It probably is a mathematical instability. I'll see if I can use a better method.


you can stop it oscilating, for now. just wait untill you try stiffer springs.

but does translating also happen if you disable damping?

it could be numerical problems, but i doubt it with explicit integration.

Share this post


Link to post
Share on other sites
Quote:
but does translating also happen if you disable damping?


Yes it does. It's very confusing.

Share this post


Link to post
Share on other sites
The translational acceleration always happens in the same direction relative to the spring. I can move the nodes around and it will acclelerate in the same direction relative to the spring's orientation (but a new direction in absolute frame of reference).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!