Hacker News Reader

Comment by batty | Hacker News Reader

Agreed, very nice. I've heard the speed issue mentioned as well, although slow compared to what, I wonder? I don't see offhand any fundamental reason why it would be dramatically slower than, say, a standard FLIP-based fluid sim. It amounts to advecting Lagrangian particles combined with solving the elastoplasticity equations on a Cartesian grid, with a snow-specific constitutive model.

View on HN

There min/frame in the included paper chart range from 3.8m/frame to 25.8m/frame, which is pretty slow for 2013 at the simulation sizes they give.

It is too bad they didn't break out the individual steps to show where the time was spent. Could simply be unoptimized code. I notice there is a restriction on the time step to be less than 0.5 x 10^-3 s, not sure if that is the main difference.

0.5 * 10^-3s is 2000hz, so 20 iterations per frame, assuming they render at 100hz, that seems a bit on the high side.. does that mean they don't have a good way of interpolating the physics effects, does that happen a lot in these kinds of simulations?

I work on a real-time multi-player game, and our physics step is actually larger than our framerate, we interpolate the rest, I guess that's quite the opposite of this :)

Film is rendered usually at 24fps or if you see the Hobbit it is HFR at 48 fps.

In the case of the simulation, the question is whether running the simulation at 24Hz or 48Hz would result in inaccuracies that require them to run it at 2000Hz.

Reply on news.ycombinator.com