8

enter image description here

A simple cloth simulation can be done using the following algorithm:

def tick(dt):
    for p1 in particles:
        for bound in p.bounds:
            p2 = bound.particle
            p2.vel += p1.pos + bound.stable_pos - p2.pos
        p1.pos += p1.vel * dt

As a test, I've tried implementing it in JavaScript. Unfortunately, this scales poorly. The performance drops very fast with the number of particles and the limit is very low. Is there a way to parallelize this algorithm? Could you describe it as a simple pseudocode?

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
MaiaVictor
  • 51,090
  • 44
  • 144
  • 286
  • 3
    Rather cool implementation. Well done. :) – techfoobar Mar 28 '13 at 12:30
  • @techfoobar Thanks, but it slows down after as few as 40 rows. I'd need at least 400 for a project! Ah, does it run softly there? – MaiaVictor Mar 28 '13 at 12:33
  • 1
    It ran smoothly for me. – techfoobar Mar 28 '13 at 12:34
  • 2
    It's not really an answer because I've never used them, but maybe web workers are what you're after? https://developer.mozilla.org/en-US/docs/DOM/Using_web_workers –  Mar 28 '13 at 12:42
  • @Llepwryd it's certainly part of the answer! But I do not know how to make the algorithm itself run in parallel :( I'm sketching some ideas but I'd like to see what's already done on this matter. – MaiaVictor Mar 28 '13 at 12:44
  • It's kind of an old article, but there is a raytracing example in it that may be similar. http://ejohn.org/blog/web-workers/ –  Mar 28 '13 at 12:52
  • I've seen some good cloth simulations with three.js, not sure if that library helps you or not. – VoronoiPotato Mar 28 '13 at 12:59
  • @Llepwryd Yay, great link, I'm reading it, thanks! – MaiaVictor Mar 28 '13 at 13:05
  • @VoronoiPotato not quite, it does not have a built in cloth simulation afaik, but I'd like to see some of those implementations, – MaiaVictor Mar 28 '13 at 13:06
  • @Dokkat Your simulation breaks down in Safari(Mac). – Antony Mar 28 '13 at 13:20
  • @Antony details? Work fine here on Safari 6.0.1 – MaiaVictor Mar 28 '13 at 13:31
  • @Dokkat I used Safari Version 6.0.2 (8536.26.17) on a Retina MBP. The simulation goes crazy: the lines stretches further and further until they fill the whole screen with a black stripe. See [screenshot](http://i.imgur.com/5XegOpz.jpg?1). – Antony Mar 28 '13 at 13:34
  • @Antony That's particularly weird as I'm on Retina MBP. It just goes crazy when you open, before even touching? You managed to use it on other browsers? This is just a simple demo so it's not really important, but I'm curious, strange thing. – MaiaVictor Mar 28 '13 at 13:42
  • Seems like nobody knows the answer, I've read a few papers on this time but not much progress ... – MaiaVictor Mar 28 '13 at 13:43
  • @Dokkat Any touch on that cloth could drive it crazy. It is independent of the magnitude of the touch. Other browsers work just fine. It is interesting how my Safari fails on this one. – Antony Mar 28 '13 at 13:44
  • How does it scale, O(n^2)? If so, then even parallelizing out to 9 cores will only let you go from n to 3n. Is that enough of a speedup to make it worthwhile for you? – mbeckish Mar 28 '13 at 14:05
  • @mbeckish It theorically scales in ~O(n) because each node only interacts with it's surrounding neighbors. I'm clueless about parallelizing, I need some good reads, really. For example, I *could* parallelize this by running n threads and communicating between them. Tada! O(1). But I guess the communication delay between threads (there probably is one?) would make that infeasible. Also, I don't feel like spawning 10000 threads would be any good? And that's to say how clueless I am on the topic. – MaiaVictor Mar 28 '13 at 14:14
  • Oh but there's a detail, while it is O(n), the amount of vectors I actually need grows with the square of the area, or the cube of the volume of whatever I'm simulating. So that's a thing. O(n^2) if you think in terms of n = rows of a plane, for example. – MaiaVictor Mar 28 '13 at 14:28
  • @Dokkat - Parallelizing out to more threads than CPU cores makes sense when the threads are waiting around a lot, usually an I/O bound operation (like waiting for a HTTP request/response to complete). If the threads are busy the whole time (CPU bound operations), then it hurts performance once you add more threads than CPU cores. – mbeckish Mar 28 '13 at 14:32
  • So see if I'm making sense, the big deal here is that at most you could reduce speed N times, where N = number of cores, which would never make it feasible to get, say, O(1) on such system, because you'd never have a millions of cores this would need. BUT you can still speed it up N times, correct? – MaiaVictor Mar 28 '13 at 14:41
  • @Dokkat - That's correct, roughly speaking. Your mileage may vary on the speedup, depending on the costs involved with splitting up the work and putting the results back together. – mbeckish Mar 28 '13 at 15:03
  • I always find it astonishing that people want high performance code, and then use an interpreter-based language (maybe your JavaScript is JIT based) or a dynamically-typed language (for which it is hard to generate efficient machine code). I suggest you switch to C or C++ if you want higher performance. – Ira Baxter Mar 28 '13 at 16:02
  • 1
    I don't know if this helps but there's a related question here http://stackoverflow.com/questions/15661270/html5-canvas-strokestyle that provides a js fiddle with a cloth simulation running smoothly on a much larger grid http://stackoverflow.com/questions/15661270/html5-canvas-strokestyle – Valentin Mar 28 '13 at 21:20
  • you may be interested in this: http://codepen.io/stuffit/pen/KrAwx (cloth with tearing) – mpen Mar 28 '13 at 23:28

1 Answers1

2

Here is a detailed description of a parallel cloth simulation design: http://atarazanas.sci.uma.es/docs/tesisuma/16614860.pdf

joel truher
  • 742
  • 7
  • 18