|
![](/i/fill.gif) |
On 31/01/2011 08:24 PM, stbenge wrote:
> Thank you all for your input! I'd still like to hear any comments you
> might have, if you can take the time.
>
> One of my goals is to prepare a full-on cellular automata gallery that
> anyone (with a graphics card) can view.
Neither URL works for me on my work PC. I get a security warning asking
if I want to run the applet, and then a blank page. The new URL works
just fine on my home PC. I have no idea why there would be a difference.
(But I recall that this kind of thing is highly typical of Java. Isn't
that their slogan? Write once, test everywhere?)
I don't know about cellular automaton; it looks more like some sort of
reaction-diffusion system.
http://texturegarden.com/java/rd/
Then again, there are other types of differential equations which
apparently produce similar results. Which is why I find it quite
surprising that you claim this is a *discrete* system, not a continuous
one. It certainly doesn't look very discrete.
I also wonder whether the visible image on-screen actually represents
all the information in the frame, or whether there are details too faint
to see. Certainly the simulation behaves in a wonderfully unpredictable way.
Clicking the mouse is like detonating a high-yield nuclear bomb, and the
fallout usually dies away quickly, but sometimes inexplicably lasts for
a very, very long time.
It is worth noting that, certainly for RD systems, almost all
combinations of parameter settings do absolutely nothing interesting at
all. Only a tiny fraction of possible settings do anything remotely
worth watching. Finding these interesting bits is highly non-trivial.
And yet, you seem to have hit upon something quite interesting here.
It appears that the image boundaries are held at a constant state. You
might try toroidal symmetry (i.e., joining the edges together). Also, it
occurs to me that if you were to run a simulation and stack each
successive frame one on top of the other, you could make some rather
interesting 3D shapes.
(Alternatively, perhaps the algorithm generalises easily to 3D. I'm not
sure how easy to visualise that would be though...)
It still amuses me that way, waaaay back in 1997 or so, I was playing
with Java, trying to copy the output of the ground-breaking Geiss
visualisation for WinAmp. Of course, Geiss used hand-optimised machine
code for all the main loops, and still ran cripplingly slowly. (E.g.,
about 12 frames/second at 800x600, only rising to sane speeds at 320x240.)
Unsurprisingly, Java was orders of magnitude slower. I had it render at
256x256, and draw 4x larger on screen. And still it was absurdly slow.
(I didn't measure exactly how slow.)
And yet, your little Java applet sucks about 5% CPU out of my obsolete
AMD Athlon 2X 4200+ with its 2.2 GHz clock rate. How times have changed!
I'm curious to know how you manage to get it to render at a constant
frame rate, rather than "as fast as you can".
Post a reply to this message
|
![](/i/fill.gif) |