In this project I attempted to animate realistic cloth using a particle system. My starting point was where I left off at the end of project 3. From there, I used a 2002 SIGGRAPH paper "Stable but Responsive Cloth" [1] to guide me throughout this project.
The most popular approach to dealing with cloth is to model it as a grid of particles and then to render it based on interactions (forces) among the particles. However, the following are some common artifacts that can occur if the implementation is not carefully done:
These are only some of the issues I came across, and by no means an exhaustive list.
The main issue with cloth is to accurately model its behavior when forces perturb its resting state. In general, cloth easily buckles under compressive forces and its post-buckling state can be difficult to model. The force-based approach outlined by Choi and Ko involve two main types of forces. Type 1 forces model shearing and stretching of cloth. These are spring-type forces between adjacent particles. Thus, every particle in the cloth grid will have 8 (center), 5 (side), or 3 (corner) type 1 forces acting on it. Type 2 forces model compression of cloth. Choi and Ko focused on developing a physical model for this force, and their treatment of this force was a significant portion of their paper.
The following approach was used:
Two points on a cloth segment have a natural resting distance L. When a compressive force is applied, it is assumed that the resulting cloth state becomes an arc of a circle whose length is also L. They also make the simplifying assumption that the chord of the circle between these two points is also L (this does not make phyiscal sense, but it allows them to derive nice and simple formulas for later use). Based on these assumptions, the radius (and thus, curvature) of the circle can be expressed solely as a function of the distance between the two particles. This curvature, along with the "moment equilibrium equation under the pinned ends condition", was used to derive the repulsive force between these two points. This summarizes type 2 forces, which exist between particles that are two points away from each other (as opposed to one for type 1).
At this point, it should be noted that one can generalize this and add forces that are n points apart. Such an approach clearly degrades performance, and it is not clear how much benefit there is to be gained. One can imagine that this may solve the self-intersection problem (discussed below), though there are probably better methods.
I implemented two more types of forces: A damping force exists between pairs of particles that interact with either type 1 or type 2 forces. This works exactly like springs, but particle velocities were used instead of position. Damping forces are usually needed to prevent perpetual oscillations of the cloth particles. Lastly, there is a constant downward gravitational force that starts cloth movement.
The formula for circle radius based on particle distance requires an inverse sinc evaluation. The inverse sinc is not a function, but fortunately, when restricted to the range we are interested in (0 to pi), the inverse mapping is always unique. The paper used a fifth-order polynomial to approximate the inverse sinc. I used a different approach: First, store a table of precomputed values of the sinc function (The pairs in the table were evaluated with uniform spacing). Whenever an inverse sinc evaluation was needed, look up the two pairs closest to it and linearly interpolate between the values. I chose this approach because:
I used a table of 512 values, each with 30 digits of precision.
I do not have evidence showing this method to be either better or worse than the polynomial approximation, but it was something new and gave reasonable results.
Computing particle forces require solving an ODE. For this, I used an adaption of Runge-Kutta 4. RK4 specifies a way of computing the next time step of a first-order differential equation based on the current one. Particle systems actually consist of two coupled first-order differential equations, with the force function being dependent on multiple inputs. Thus, I had to extend the RK4 algorithm specification to fit the particle system framework. This was conceptually simple, but not a trivial process.
I have basic collision detection for 3 types of (static) objects: a plane (the ground), spheres, and tetrahedrons. Since handling of cloth collision was not the focus of this project, I used a simple but crude implementation: Whenever a particle was detected to have passed through an object, its position would revert to the one in its previous time step, and its velocity vector would reverse directions. It was further scaled by a constant factor (0.5) to simulate the fact that cloth collisions are not elastic.
In my opinion, the biggest lesson from this project is the following: the various force constants in the particle simulation are sensitive to the relative distances between particles. The reason for this is simple: the forces do not all have the same rate of growth (in particular, the type 2 force is not linear like the other two non-gravity ones). So, at different magnitudes, these forces will scale differently. Thus, for rendering the same area, constants that work well for a certain number of particles might not do so when more particles are used. This problem is further amplified when one realizes there is no obvious way of deriving the "right" constants as a function of the particle count. In principle, a particle represents some portion of the cloth's mass. Perhaps, as the number of particles increase (and thus, each particle represents less mass), it is possible to use known mass/particle ratios to efficiently extrapolate good constants for larger particle counts. The following table gives some reasonable values I've used for the simulation process:
| particle count | type 1: ks | type 2: kb | damping: kd |
| <10 | 1 | 1 | 1 |
| 10*10 | 10 | 1 | 1 |
| 20*20 | 50 | 1 | 1 |
| 30*30 | 100 | 0.1 | 2 |
The table illustrates two things: First, the spring constant ks needed to increase rapidly in order to compensate for the relatively stronger type 2 force. A video below illustrates what happens when no such provisions are made. Second, the constants need to change at different rates, even for the arguably similar ks and kd constants.
There are many cloth behaviors, some desirable, which were not captured in this model. First, air resistance and friction were not taken into account. Second, rendering the cloth near areas of collision was an issue: since the cloth was simply rendered as a quad-mesh of points, it is possible to have situations where it intersects with other scene objects. I used the following effective hack (due to Peter), to deal with this issue: The scene objects were drawn smaller (80%) than their actual internal representation. One class of intersections that this does not deal with are those with sharp corners. Third, my simulator is oblivious to cloth self-intersection.
A video below illustrates these shortcomings.
The simulation always starts with a grid of uniformly spaced particles. They are not orthogonal to any axis. The top row of particles are fixed to their starting position.
This first video uses a 10*10 array of particles. The individual quad-meshes can be easily seen.
This video uses the exact scenario as before, except the number of particles are increased to 30*30. Notice the initial explosion, perpetual oscillations, and general un-clothlike behavior.
Same as above, except only the particles are being rendered.
30*30 particles, with sane values for the constants. This is where I decided to stop tweaking for higher particle counts.
This illustrates some model shortcomings. Notice the cloth/tetrahedron intersection, cloth self-intersection, and exaggerated corner flair (lack of air resistance). In the previous video, one can see the cloth glide smoothly along the ground (lack of friction).
And again, with just the particles. It is hard to tell, but one of the particles gets stuck on the tetrahedron's surface (no friction modelling).
Lastly, something that I was hoping to do, but did not have time for, was model cutting or tearing of cloth. A cutting effect should simple to achieve: one can simply delete forces that are no longer desired, and the corresponding cloth particles will no longer interact. However, the following issues still need to addressed:
For anyone who would like to do a similar project in the future that models cuts and/or tears, these issues will eventually need to be addressed.
Thanks to Peter Djeu for the conversations and suggestions. Thanks to Mike Gerbush, my project 3 partner, for handling the other parts of project 3 so I was completely focused on particle systems and became well-prepared for this project.