24. Rubbery Cloth and Numerical Instability

Kaveh Kardan
4 min readMay 17, 2022

--

Whereas hair animation involved dynamic simulation of one-dimensional strands, cloth consisted of a 2D surface deforming in 3D. Furthermore cloth had internal structure which affected how it moved and draped. Furthermore furthermore, we are very used to the behavior and movement of clothing so any deviations from physical reality were readily apparent to viewers.

I encountered a number of challenges with simulating clothing. These included numerical integration and instability, the scale of folds and other artifacts, plus collision detection and response.

My first tests of fabric resembled sheets of rubber more than cloth. Cloth bends very easily but hardly stretches in everyday scenarios. This meant the edge-springs had to be stiff, which in turn required small simulation time steps to prevent numerical instability, which increased the simulation time.

The resolution of the cloth mesh determined the size of folds which could be simulated. Silk and cotton required much higher resolutions than leather. Over time, I discovered the use of cross-bracing springs to prevent shearing, and how to control cloth bending using second-neighbor springs between vertices.

But the biggest software development challenge for clothing simulation had to be collisions. How to detect and respond to collisions between clothing and a character’s moving body, handling mesh vertex-polygon and edge-edge collisions.

It was neat to see updates take place in the graphics viewport, on the multiple processors of the refrigerator-size SGI box (and yes, it was still only a fraction as powerful as a modern smartphone). Blocks of vertices in a mesh updating and refreshing in the viewer via shared memory as my simulation code ran in its own processes.

In retrospect, I was not very aware of machine architecture issues, about keeping data in cache and so forth. I had, probably due to my Lisp background, lots of interconnected structures rather than large arrays of floats which would have been more efficient (due to more coherent memory access) for the hardware to handle.

Then the building burned down.

Design & Code

“All great work — artistic, poetic, intellectual, or spiritual — is produced at those moments when its creators are lost completely in their actions, when they forget themselves altogether, and are free from self-consciousness.” — Christmas Humphreys (1901–1983)

It’s been a week since my last post. I didn’t even turn my development computer on for a couple of days, after the power outages. Kept wondering how much work I had lost in unsaved Emacs buffers. As usual, the fear was worse than the reality: not much, if any.

While having a think (as they say in New Zealand) about the direction of my development, I have been doing some reading. Quite a bit, actually. Jumping between five books: “Pictures at a Revolution” by Mark Harris, “The Silk Roads” by Peter Frankopan, “Bit by Bit” by Andrew Ervin, “The Dream Machine” by M. Mitchell Waldrop, and “Let Over Lambda” by Doug Hoyte.

Reading “Bit by Bit”, I came across the quote above, by a renowned British barrister and Buddhist, and thought it nicely reflected the state I feel when engaged in a good programming session. Common Lisp (along with Emacs and Slime) helps me get in that state of mind, even if my current development is far from being a “great work”. Today, I guess we tend to refer to this state of mind as “flow”.

I am still wavering about the direction my development should take. Whether I should bite the bullet and start using some of the CL packages out there rather than home-brewing everything. Which UI package should I use? Why is there no obvious candidate? Are there any insights I can gain into the relationship between code and geometry? Maybe something having to do with representing shapes as S-expressions? Do I worry too much?

In the end I decided to spend a few days writing a simple polyhedron class and an obj file reader, just so I could import and display external geometry. An example is the famous Utah Teapot shown above. Don’t think I had written a reader for obj format files since my Neo-Visuals days. I was also pretty rusty about CL file I/O, and had to look up some references. That’s one thing the internet is good for.

Next Episode

--

--

Kaveh Kardan
Kaveh Kardan

Written by Kaveh Kardan

MIT mathematics degree • wrote animation software used in “Jurassic Park” • software R&D lead on “Final Fantasy” movie • software dev on “The Hobbit” films

No responses yet