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