Jump to content

View more

Image of the Day

Boxes as reward for our ranking mode. ヾ(☆▽☆)
#indiedev #gamedev #gameart #screenshotsaturday https://t.co/ALF1InmM7K
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

Sign up now

Rope/cloth simulation problems

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 RubyNL   Members   


Posted 23 June 2012 - 02:06 PM

Hello, for a course in 3-dimensional modelling, I have to program a rope simulation, and, extending that code, a cloth simulation.
I'm having some troubles though. First I had a shot at an Eulerian sping mass-model, like described on Hugo Elias' site. It was either way too elastic, or way too 'jumpy' (numerically instable, everything exploded after a few seconds, especially if I attached a node to the mouse so I could test the reaction on mouse movements).
Then I read some more articles about rope simulation, the most important being Advanced Character Physics (html | pdf) by Thomas Jakobsen. He suggested using Verlet Integration. I use a fixed timestep (I use dt = 1 in my code), so the Verlet Integration basically comes down to storing the last position of each node/particle instead of storing it's speed (at least, that's what I think, I could be missing something), so initially this had no effect on the instability.
But then I read about constraint relaxation. Constraint relaxation basically means you 'satisfy' each constraint, one at a time, while not caring about the effect this has on the other constraints. Then you repeat this process a few times, and you end up with an approximation of a system where all constraints would be satisfied.

I have 75 nodes/particles, and I have set the 'sticks' between them to be of a length of 3 pixels (this is the only constaint I'm using, but since I'm doing this for 75 particles, it are in fact 74 constraints which all invalidate each other to some degree). For example, if you have three nodes on a horizontal line with each 100 pixels between them, we have two constraints (the first being that node 1 and node 2 must be 3 pixels apart, and the second that node 2 and node 3 must be 3 pixels apart). Satisfying the first constraint (node 1 and node 2 must be 3 pixels apart) will move node 1 48.5 (=(100-3)/2) to the right and node 2 48.5 pixels to the left. The distance from node 2 to node 3 will then increase to 148.5, but my code uses the old position (which is in memory because I use Verlet Integration) to calculate the distance between two nodes, so the distance between node 2 and node 3 can be regarded as 100 pixels. Then the satisfaction of the second constraint will increase the horizontal position of the second node with 48.5 pixels again, (basically undo-ing the displacement what we did to satisfy the first constraint) and move the third node 48.5 pixels to the left.

In practice, this method should converge to a 'solution', satisfying all the constraints, but I fear it might converge too slow.

Here is what I have so far:

It looks pretty good (especially when you consider that I don't use any 'flexion' springs, which connect nodes that are separated by another node between them), but in this example I have 75 particles, each attached to 1 or 2 'springs'. I run the part of the code where I satisfy each constraint 500 times, and I'm fairly sure this is way too much to be of practical use in a cloth simulation. Further, I still have some 'springyness', even when I use 500 iterations. I'm afraid this springyness will be a much bigger problem in a cloth simulation (because there are many more points, so the mass is much higher). If I use 100 iterations, the rope is much more elastic already.

So, I'm confused about the spring-mass model, I couldn't get it working in a satisfying way. Am I on the right track to go on with cloth simulation or am I doing something structurally wrong?

Also, in the practicum description it states that you should use Hooke's law (F=-kx where x is the displacement from the rest length of the spring, and k is some positive spring constant). I am not using this equation explicitly, but the constraint relaxation has the same behaviour, so I guess that's fine. But the description also states that you should use a maximum length for the distance between the nodes, which really confuses me, because this is exactly what I'm doing with the constraint relaxation, but this results in spring-like behaviour where the rope still is elastic (the distance between ). I don't know how to set a 'hard' maximum for the distance between two nodes.
Suppose I could get an Eulerian system working nicely, I wouldn't know how this implement such a hard border either...

Sorry for the long post, it thought it was kind of hard to explain clearly what I'm doing and what's the problem!

#2 h4tt3n   Members   


Posted 25 June 2012 - 12:05 PM

Hi there,

Seeing that noone has bothered to reply, I'd like to give you a little advise: If a constraint needs 500 iterations to produce good result, I'd ditch it right away. The Jacobsen method works, but it's a bit dated. In stead take a step back and have a second go at the spring method. As far as I can see, the reason it kept blowing up is because the model you used has no damping. The damped Hooke's law of elasticity spring looks like this:

f = -kx - dv

where f = force, k = spring stiffnes coefficient, x = displacement, d = damping coefficient, and v = velocity along distance vector.

v is calculated by taking the dot product of the velocity difference vector (node 2 velocity - node 1 velocity) and the normalized distance vector.

If you apply the damping and tweak the coefficients, you'lle see much calmer movement and no simulation blow up.

Have fun experimenting!


#3 RubyNL   Members   


Posted 26 June 2012 - 05:27 PM

Thanks for your reply!
I've fiddled with the variables a bit and I get a much better performance now (I would upload another video right now if that wouldn't take so long). At first I thought that setting my stiffness above 1 would result in instability per se, but it turns out that it works quite well. I've got a cloth simulation running with the method I've described above, and it works fine. I do about 7-50 iterations where I satisfy the constraints. Works quite well, however the strings are still quite elastic when I use a lower number of iterations.

Then I came across deformation constraints in a mass-spring model to describe rigid cloth behavior. It seems to be what my lecturer aimed at with his descriptions of a mass spring model, with a maximum length for the rope segments between the nodes. I am trying to implement this model right now. Sadly, I'm kind of stuck with Euler's method of integration. I get only way too elastic strings, which fall straight down to the ground, even if I set the stiffness to 1.

Maybe I will have a shot at it in the near future, but since it's for an assignment that I have to hand in in a few days, I will finish the project with the Verlet Integration first.

Edited by RubyNL, 26 June 2012 - 05:36 PM.

#4 RubyNL   Members   


Posted 28 June 2012 - 11:03 AM

Here is the result I got with Verlet Integration (the method I described in my first post):

I'm quite happy with it, since it was all done it a hurry (I got my finals this week, so I made this from the rope thing in literally one day). Gouraud shading, nothing fancy (I had no time to do research in OpenGL lighting methods, I had enough trouble with C++ alone, since this is the first thing I code in that language).

I have to admit, this is the result in optimal circumstances. I don't have any collision detection, so the cloth/flag often sticks through itseld when I move it.

Edited by RubyNL, 28 June 2012 - 11:05 AM.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.