clipka <ano### [at] anonymousorg> wrote:

> (An optimized C program could probably do the whole smash in a matter of
> seconds - even a naive attempt does it in about a minute - but that's
> not the point :P)

It's likely, but they both slow down quickly since, for an n x n grid, the time
increases at a rate of O(n^3).  I'm running a version right now that's 6th
order in space and time, and it takes about four hours or so for about 10000
frames at 1000x1000 resolution.

> As an interesting side note, although performing bulk mathematical
> simulation, the SDL script doesn't use a single function (except for
> auxiliary purposes), not a single array, no file #write or #read, and
> only a single control statement (an #if, for special treatment of the
> very first frame). Virtually all it does is render frame after frame of
> the animation.

Wait a minute--no #while?  No arrays?  Are you using textures or what?  Sounds
like great material for an obfuscated POV contest, but maybe it's really
straightforward.  Let me guess...  Read the last two frames as a texture.  Move
the last frame up, down, left, and right by one pixel.  Add together and
subtract the last frame to get a laplacian.  Then do a simple explicit
iteration in time to get the next frame as a texture.  Render.  Repeat.  (?)

 - Ricky


Just thinking out loud...  er, silently...

Wave equation:
d^2p/dt^2 = c^2 del^2 p

Discretize the time derivative:
(p_n+1 - 2*p_n + p_n-1)/dt^2 = c^2 del^2 p

Rearrange:
p_n+1 = 2*p_n - p_n-1 + (c*dt)^2 del^2 p

Discretize the laplacian:
p_n+1 = 2*p_n - p_n-1 + (c*dt/dx)^2 (p_i+1,j + p_i-1,j + p_i,j+1 + p_i,j-1 -
4*p_i,j)

So to get the next frame, read the last two as a texture.  Add twice the last
frame minus the second-to-last frame.  Then add (c*dt/dx)^2 multiplied by the
sum of the last frame shifted in every direction by a pixel minus 4 times the
last frame.

Render?

Post a reply to this message