On 2/1/2011 1:45 AM, Invisible wrote:
> 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.
>
> 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?)

Part of the problem is that I'm using OpenGL libraries, and the security 
restrictions imposed by the new version of JRE is keeping the thing from 
loading completely. In a few days (after the download is complete) I can 
start signing my applets, which should help.

> I don't know about cellular automaton; it looks more like some sort of
> reaction-diffusion system.

It /is/ partly a reaction-diffusion system. I've never made a "pure" RD 
system, though the edge-finding portion of mine is considered a type of RD.

> http://texturegarden.com/java/rd/

Oh yeah, I was there yesterday :) There's also another link at the same 
site concerning fractal drainage patterns:

http://fd.alife.co.uk/model/plugin/index.html

When trying to model minimal surfaces, I inadvertently stumbled upon a 
way to model such drainage patterns. What you see in my demo is the 
result of the drainage ridges becoming stabilized. I think it might even 
lead to a way for eroding height_field data.

> 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.

No, it's definitely *not* discreet. After reading up on the definitions, 
I'd have to say that it's most likely continuous. I guess I have lumped 
all sorts of systems into the generalized term, "CA." There's a lot of 
crossover. I'm pretty sure there is a continuous version of the Game of 
Life (maybe still waiting to be found).

> 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.

The video surfaces are not scaled down, but they /do/ use linear 
interpolation, so there is inter-pixel testing going on. I didn't use 
noise for the field, but when you click the mouse, it sprays 
randomly-valued pixels locally. That's the only randomization present.

> 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.

Well, it was a theory that actually worked! Usually when I hit upon 
something, the next phase is the small adjustment of values, to express 
what's truly going on. It's hard to tell exactly /what/ needs to be 
changed beforehand, since each subsequent generation becomes more and 
more difficult to predict. But that's what makes these systems so much 
fun :)

> It appears that the image boundaries are held at a constant state. You
> might try toroidal symmetry (i.e., joining the edges together).

Yeah, the library I'm using for the GLSL doesn't allow me to tell OpenGL 
to wrap a texture. Which means I need to make a function, which means 
things will slow down somewhat, though not appreciably.

> 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.

I should try that. I don't see why it couldn't be done (unless I run out 
of RAM).

> (Alternatively, perhaps the algorithm generalises easily to 3D. I'm not
> sure how easy to visualise that would be though...)

I'm sure a 3D version would work just fine, but would be hecka slow. 
I've thought about stacking 2D surfaces and testing between them. The 
current setup (768x768) amounts to 589,824 pixels. A 64x64x64 stacked 
planes setup would be 262,144 pixels total. But such a setup would 
require more pixel samples to be taken, and some sort of way to test the 
nearest surfaces. To visualize it, I could use alpha transparency and a 
simple bump-mapping technique. But there are other problems with doing 
all of that that I haven't resolved.

> 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.)

Whoa, that's pretty fast! I've gotten no better with SDL and C++...

> 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.)

Yeah. Java, as a rule, just isn't that fast.

> 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!

Most of the work is being done on your graphics card. That's why GLSL 
appeals to me so much: I can quickly type out an idea and see it play 
out in real-time. I didn't even realize the potential until I saw some 
of Milkdrop's presets... At one point I was like, "Wait a minute! That's 
the Game of Life, running at 60FPS! Fullscreen!!!" I didn't get much 
sleep that night.

> 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".

It /is/ running all-out, but it's possible that either Processing or the 
graphics hardware is capping the frame rate.

Sam

Post a reply to this message