On 2/2/2011 1:44 AM, Invisible wrote:
>> 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.
>
> Hmm, OK.

It's the edge technique described in Milkdrop's preset authoring page. 
When used carefully, you can produce reaction/diffusion and "skin dot" 
effects.

>> 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 see... I think.

 From Wikipedia's stub on Continuous automaton:

"A continuous automaton can be described as a cellular automaton 
extended so the valid states a cell can take are not just discrete (for 
example, the states consist of integers between 0 and 3), but 
continuous, for example, the real number range [0,1]."

You can enforce discrete rules into continuous CA, hence my argument 
that there can be some crossover between the two. This is *probably* 
something you would have to do to make a continuous version of Conway's GOL.

Last night I began producing a "hard" version of continuous CA in which 
ships are born or killed based on area evaluation. It's looking to be a 
promising method. Already, it has managed to produce three main types of 
"ships," all relatively huge. In fact, it's nothing /but/ ships :S

>> 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 :)
>
> Fun and frustrating at the same time, usually. ;-)

I don't find it frustrating at all <G>

>>> 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.
>
> Wait - it's written in *Java* and yet it can access the *graphics card*??
>
> How is that even possible?

Robust code, of course.

Evidently there are some security issues involved with allowing an 
applet to access graphics hardware, which is likely the reason the new 
version of JRE is so intolerant.

> I wish to God I could figure out how half of Milkdrop works. There are
> some amazing 3D effects which cannot be done in realtime, and yet it
> does them in realtime, even though that's clearly impossible.

It's really not that difficult to learn (mastering it OTOH...). It draws 
graphics (shapes, dots) to a texture residing on a screen-wide, flat 
quad mesh (the detail of which can be changed through settings) and then 
recycles the drawn graphics for the next frame. The quad mesh can be 
warped to "push" the graphics around. Many 3D effects are created by 
slightly altering the mesh. Then there are two pixel shaders allowing 
you filter all the graphics. The first pixel shader can let you to 
produce CA, reaction/diffusion, etc., since it "recycles." The other 
shader is the final composite function that lets you apply a pixel 
filter without affecting the next frame.

Some of the 3D effects which look too detailed, and seem to exist on a 
per-pixel level, are probably effects created by a 2D shader.


Oh yeah, the common link between the reaction/diffusion link you posted 
and the drainage pattern link I posted is this: http://www.cell-auto.com/

There are many interesting things to be found there :)

Sam

Post a reply to this message