This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
So far the math has been straightforward. But implementing just the tension and torsion forces alone will lead to cloth meshes that are very unstable. The two main problems are folding and oscillation. Folding occurs when the outside faces of the cloth mesh bend inwards on each other, and it can be solved reactively by doing a self-collision check within the mesh. Today, this is still prohibitively computationally expensive. Another solution is to proactively prevent folding by adding non-local connections with a moderate torsion constant. For example, the ooze has connections between its center point and all other points, which keeps the center from folding over the edge as it starts to move, and assists in turning the outside edges as the center turns.
Another approach is to introduce forces that reduce oscillation and prevent explosive oscillation. Damping is a mathematical application of a friction force, which prevents jittering and allows the cloth to eventually reach a rest state. Acceleration damping is an arbitrary, non-physical addition which prevents points in the mesh from rapidly changing direction. Rapid changes in velocity are usually a sign of a growing oscillation which will explode the mesh. Finally, rotation damping is another non-physical addition which acts a bit like the physical force of viscosity. Rotation damping is used to prevent torsion oscillations around the center of the mesh.
All this computation is a lot of work. To be clear, the calculation of forces and normals is conceptually simple - it's just the torsion and tension forces that were presented earlier. There is some significant math complexity involved and that is what the CPU labors over. But, since modern CPUs are now more capable, there are ways to prevent this computational effort from demolishing the frame rate of a game using even the most complex cloth simulations.
A multi-core CPU can do several calculations at once, by deploying multiple threads. Presuming that the main thread of a game has other work to do, the time-consuming calculation of forces and normals can be deferred for later computation by another thread. At the end of a frame, all the positions of the mesh points are available, and the forces for the next frame can be calculated immediately, based upon the time elapsed this frame. This works well assuming that the frame rate remains fairly steady. Since at the end of each update, the calculation of forces is deferred, the results must be "waited for" at the start of each frame. This "wait" can be defined such that if the forces are available, there is no delay, and if they are not, then the main thread will help compute the remaining parts.
In addition to deferring the calculation to another thread, the work can be broken into smaller pieces that can be processed by even more threads. This is useful on a four-core machine, for example. The Pet Me demo accomplishes this with a system built on top of the Intel® Threading Building Blocks. Intel® TBB is a cross-platform (Microsoft Windows*, Apple Mac OS X*, Linux*, and Microsoft Xbox 360*) Open Source library which implements a very efficient and scalable thread pool, and provides a useful API for dividing up computation between threads.
Figure 9: Code that demonstrates Intel® Threading Building Blocks usage to simulate cloth
Figure 9 shows code for a class that structures the forces calculation using Intel TBB. The calculation happens within the ConnectionForcesContext function operator(). The calculation object is passed indices of an array through this function, and then performs the desired calculation based upon what is found in that array. The array is the list of all the connections in the mesh, and the calculation object stores the forces that are applied to each point in the mesh, based upon the interaction of the connections.
The bottom half of the code in Figure 9 shows a snippet that invokes Intel TBB to perform the calculation. The parallel_reduce function is passed in a range object that specifies the size of the array, and is also passed in the calculation object that was defined earlier. Intel TBB will divide the range into pieces based upon a preferred number of elements in each chunk (the uGrainSize, above). Each time the range is divided, the copy constructor of the calculation object is invoked to maintain calculation state.
There is more information on Intel TBB at www.threadingbuildingblocks.org.