A classmate and I iterated on a mass-spring system to eventually build it into an entire cloth simulation with sphere collision capability. We intentially designed the spring force propogation through the cloth to minimize computation time, and we had to integrate the spring forces with a more accurate integration scheme than basic Eulerian to keep the simulation from diverging.
Notable Experiences
Structured the simulation steps for Midpoint Integration.
Designed our data and pipeline to handle tearing as elegantly as possible (including in the GPU).
Utilized OpenMP on the many for-loops for a minor performance increase.
Dealt with many issues regarding "realistic cloth" -- i.e. the weight of the cloth itself influencing its springs and all of the implications for more complex movements than hanging.
We chose to focus primarily on the cloth and spring system, because we felt it was the most interesting and challenging set of options on the list. The spring calculations took a large portion of the time, both implementing and debugging. Initially we used Eulerian integration to simulate position and velocity, but we found this was insufficient and tended to be very unstable. Switching to Midpoint Integration produced a much more computationally complex, but much more stable system. Tearing was slightly easier than predicted, we had already associated faces, points, and springs together, and so deleting them in unison proved to be a relatively simple task.
Many conflicts were had between this sphere and the cloth.
The largest difficulties during the project came from fine-tuning and debugging the physics. It is difficult to debug a system that has so much variation within it, so some of our visual guesses at what was 'right' belied errors lurking underneath in the physics simulation. Even when we were doing the right things, the integration method made it seem like something was wrong, adding to the difficulty of correcting errors. This was compounded by our spring-system; it allowed for variations like fixed springs, which we soon found out propagated a whole lot of fake values through the rest of our cloth!
Looks like an angel? Totally. Accurate physics? Probably not.
The spatial data structure was another portion of the project we attempted to implement. Initially, we had the completely wrong idea and ended up implementing a bounding volume hierarchy that was on the order of log(n) for every update frame! (n equals number of points connected to springs in the cloth)
We were desperate to speed up the simulation at that point, so we investigated better solutions to generating the bounding volumes. We eventually discovered that Release mode in Visual Studio that optimizes the solution, which yielded the speed-up that we desperately wanted. We still attempted to create a better BVH that involved a grid-like solution for determining how to divvy up the particles on the cloth. We achieved a good solution but quickly found out that we still couldn't beat the performance of the optimizer! Even when we used the BVH, the generation time would eat into the time frame more than checking every collision against a single sphere, so we dropped that feature before we finished it.
