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:
[media]
[/media]
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!