Hello,

I'm working with Processing and GLGraphics to produce various cellular 
automata simulations. I've just found something worth sharing, and was 
wondering if somebody might help me test it out. It requires Java and a 
newish graphics card (GLSL, Pixel Shader 2.0+).

http://www.caltel.com/~abenge/index.html

You can draw bubble-producing explosions with the mouse. Tap inside a 
medium-sized cell to "pop" it. The space bar clears the screen.

It will probably run blindingly fast on newer cards, slower if your card 
is old, not at all if it's ancient. I get 30FPS on my GeForce 7600GS . 
It would be faster, but I'm using 16-bit surfaces.

The simulation itself is based on an edge-finding technique combined 
with diffusion and a method (developed with POV-Ray) for 
pinching/expanding densities. As the field stabilizes, the result 
resembles a minimal surface.

I was hoping to use something similar to make a suds effect for MilkDrop :)

Sam

Post a reply to this message

stbenge wrote:
> http://www.caltel.com/~abenge/index.html

I get a note at the bottom saying "class not found: RDMinim"

(When you describe it, you might want to mention it's an applet and not a 
stand-alone java program.)

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message

> I'm working with Processing and GLGraphics to produce various cellular
> automata simulations. I've just found something worth sharing, and was
> wondering if somebody might help me test it out. It requires Java and a
> newish graphics card (GLSL, Pixel Shader 2.0+).
>
> http://www.caltel.com/~abenge/index.html

I just get a very small black square and nothing much happening (oh and 
Java crashes when I try to close the webpage).

Sounds exciting though, can you post some screen shots?

Post a reply to this message

On 31/01/2011 4:19 AM, Darren New wrote:
> I get a note at the bottom saying "class not found: RDMinim"

Me too :-(

-- 
Regards
     Stephen

Post a reply to this message

Works flawlessly for me (with Firefox, on a not so new computer).

It's mesmerizing !


Thibaut


Le 31/01/2011 02:19, stbenge a écrit :
> Hello,
>
> I'm working with Processing and GLGraphics to produce various cellular
> automata simulations. I've just found something worth sharing, and was
> wondering if somebody might help me test it out. It requires Java and a
> newish graphics card (GLSL, Pixel Shader 2.0+).
>
> http://www.caltel.com/~abenge/index.html
>
> You can draw bubble-producing explosions with the mouse. Tap inside a
> medium-sized cell to "pop" it. The space bar clears the screen.
>
> It will probably run blindingly fast on newer cards, slower if your card
> is old, not at all if it's ancient. I get 30FPS on my GeForce 7600GS .
> It would be faster, but I'm using 16-bit surfaces.
>
> The simulation itself is based on an edge-finding technique combined
> with diffusion and a method (developed with POV-Ray) for
> pinching/expanding densities. As the field stabilizes, the result
> resembles a minimal surface.
>
> I was hoping to use something similar to make a suds effect for MilkDrop :)
>
> Sam
>

Post a reply to this message

stbenge escreveu:
> Hello,
> 
> I'm working with Processing and GLGraphics to produce various cellular 
> automata simulations. I've just found something worth sharing, and was 
> wondering if somebody might help me test it out. It requires Java and a 
> newish graphics card (GLSL, Pixel Shader 2.0+).
> 
> http://www.caltel.com/~abenge/index.html
> 
> You can draw bubble-producing explosions with the mouse. Tap inside a 
> medium-sized cell to "pop" it. The space bar clears the screen.
> 
> It will probably run blindingly fast on newer cards, slower if your card 
> is old, not at all if it's ancient. I get 30FPS on my GeForce 7600GS . 
> It would be faster, but I'm using 16-bit surfaces.
> 
> The simulation itself is based on an edge-finding technique combined 
> with diffusion and a method (developed with POV-Ray) for 
> pinching/expanding densities. As the field stabilizes, the result 
> resembles a minimal surface.
> 
> I was hoping to use something similar to make a suds effect for MilkDrop :)
> 
> Sam

404: not found

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

On 1/31/2011 9:46 AM, nemesis wrote:
>
> 404: not found

I just uploaded it to a new directory:

http://www.caltel.com/~abenge/applet/index.html

Sam

Post a reply to this message

On 1/30/2011 8:19 PM, Darren New wrote:
> stbenge wrote:
>> http://www.caltel.com/~abenge/index.html
>
> I get a note at the bottom saying "class not found: RDMinim"

This is my first time uploading such a thing... I'll have to look into 
it. It has its own directory now, so maybe it will work:

http://www.caltel.com/~abenge/applet/index.html

> (When you describe it, you might want to mention it's an applet and not
> a stand-alone java program.)

Ah yes, I should have mentioned that :S

Sam

Post a reply to this message

On 1/31/2011 1:03 AM, scott wrote:
>> I'm working with Processing and GLGraphics to produce various cellular
>> automata simulations. I've just found something worth sharing, and was
>> wondering if somebody might help me test it out. It requires Java and a
>> newish graphics card (GLSL, Pixel Shader 2.0+).
>>
>> http://www.caltel.com/~abenge/index.html
>
> I just get a very small black square and nothing much happening

As it turns out, there were two places to change the window size, so it 
should be fixed now.

>(oh and
> Java crashes when I try to close the webpage).

That's not very encouraging :(

> Sounds exciting though, can you post some screen shots?

I will, if the app still refuses to run. A series of PNG files would be 
best, but they take a long time to upload...

Sam

Post a reply to this message

On 1/31/2011 9:58 AM, stbenge wrote:
> As it turns out, there were two places to change the window size, so it
> should be fixed now.

The updated link:

http://www.caltel.com/~abenge/applet/index.html

Post a reply to this message

On 1/31/2011 3:08 AM, Thibaut Jonckheere wrote:
>
> Works flawlessly for me (with Firefox, on a not so new computer).
>
> It's mesmerizing !

Thanks, Thibaut! I wish I could distill the core principles into a tidy 
equation, but I'm not so good at reading/writing mathematical notation :(

Sam

Post a reply to this message

On 31/01/2011 5:53 PM, stbenge wrote:
>
> This is my first time uploading such a thing... I'll have to look into
> it. It has its own directory now, so maybe it will work:
>
> http://www.caltel.com/~abenge/applet/index.html

Still getting "class not found: RDMinim" :-(
I've updated Java, Firefox and IE8

-- 
Regards
     Stephen

Post a reply to this message

On 1/31/2011 10:36 AM, Stephen wrote:
> On 31/01/2011 5:53 PM, stbenge wrote:
>>
>> This is my first time uploading such a thing... I'll have to look into
>> it. It has its own directory now, so maybe it will work:
>>
>> http://www.caltel.com/~abenge/applet/index.html
>
> Still getting "class not found: RDMinim" :-(
> I've updated Java, Firefox and IE8

Ack... so far I've found that if the class in in ASCII format, there 
will be problems. I don't know how to make it binary. My system wants to 
open it with Notepad, and I doubt that changing the preference will 
alter the nature of the file... I don't know why it would work for 
Thibaut and myself and not you...

Sam

Post a reply to this message

On 31/01/2011 7:02 PM, stbenge wrote:
> Ack... so far I've found that if the class in in ASCII format, there
> will be problems. I don't know how to make it binary. My system wants to
> open it with Notepad, and I doubt that changing the preference will
> alter the nature of the file... I don't know why it would work for
> Thibaut and myself and not you...

I must be a bad person. ;-)

Probably not related but I'm having problems today with port forwarding 
and connectivity.

-- 
Regards
     Stephen

Post a reply to this message

stbenge wrote:
> http://www.caltel.com/~abenge/applet/index.html

Still happening, altho it loaded a couple of things first.

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message

On 1/31/2011 11:42 AM, Stephen wrote:
> On 31/01/2011 7:02 PM, stbenge wrote:
>> Ack... so far I've found that if the class in in ASCII format, there
>> will be problems. I don't know how to make it binary. My system wants to
>> open it with Notepad, and I doubt that changing the preference will
>> alter the nature of the file... I don't know why it would work for
>> Thibaut and myself and not you...
>
> I must be a bad person. ;-)
>
> Probably not related but I'm having problems today with port forwarding
> and connectivity.

No, probably not related, but it can't be ruled out entirely.

Here's a very minimal test applet that does not use OpengGL:

http://www.caltel.com/~abenge/test/index.html

If it works, then it's most likely either a conflict with a version of 
JOGL you've installed, or more likely, the newer version of JRE that has 
been giving everyone grief lately.

If it doesn't work, then it is a binary/ASCII problem, possibly in 
addition to other things...

Sam

Post a reply to this message

On 1/31/2011 11:48 AM, Darren New wrote:
> stbenge wrote:
>> http://www.caltel.com/~abenge/applet/index.html
>
> Still happening, altho it loaded a couple of things first.

It's vexing! Does this small test work?

http://www.caltel.com/~abenge/test/index.html

It doesn't use OpenGL. I'm trying to rule out the possibilities :/

Sam

Post a reply to this message

On 31/01/2011 8:02 PM, stbenge wrote:
> Here's a very minimal test applet that does not use OpengGL:
>
> http://www.caltel.com/~abenge/test/index.html

That works for me, Sam.

-- 
Regards
     Stephen

Post a reply to this message

On 1/31/2011 12:12 PM, Stephen wrote:
> On 31/01/2011 8:02 PM, stbenge wrote:
>> Here's a very minimal test applet that does not use OpengGL:
>>
>> http://www.caltel.com/~abenge/test/index.html
>
> That works for me, Sam.

OK, then I'll download the latest JRE release and see if it breaks the 
applet or not. Thanks for you input!

Sam

Post a reply to this message

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.

Sam

Post a reply to this message

On 1/31/2011 12:17 PM, stbenge wrote:
> On 1/31/2011 12:12 PM, Stephen wrote:
>> On 31/01/2011 8:02 PM, stbenge wrote:
>>> Here's a very minimal test applet that does not use OpengGL:
>>>
>>> http://www.caltel.com/~abenge/test/index.html
>>
>> That works for me, Sam.
>
> OK, then I'll download the latest JRE release and see if it breaks the
> applet or not. Thanks for you input!

Got it, and it's broken! I can now proceed accordingly. Thanks again.

Sam

Post a reply to this message

stbenge wrote:
> Ack... so far I've found that if the class in in ASCII format, there 
> will be problems.

Your web server has to deliver .class files as application/octet-stream. Sun 
did this to kludge around the fact that many sysadmins didn't want to fix 
their web server to use an official content type for .class files, so Sun 
decreed that it had to be served with the default "I don't know what this 
is" content type.

If your web server serves it as the default "this is HTML" then you need to 
change that.

> I don't know why it would work for 
> Thibaut and myself and not you...

Likely for the same reason that everyone bitches at IE letting hidden worms 
in: IE will look into the content of the file it gets that's served with the 
wrong content type and fix that, for the same reason that Sun decreed you 
must serve applets with the wrong content type. It gets around misconfigured 
servers.

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message

stbenge wrote:
> Here's a very minimal test applet that does not use OpengGL:
> 
> http://www.caltel.com/~abenge/test/index.html

Works for me!

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message

stbenge wrote:
> It doesn't use OpenGL. I'm trying to rule out the possibilities :/

Don't you love web development? :-)

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message

On 1/31/2011 1:04 PM, Darren New wrote:
> stbenge wrote:
>> Here's a very minimal test applet that does not use OpengGL:
>>
>> http://www.caltel.com/~abenge/test/index.html
>
> Works for me!

Alright, it's narrowed down to one or two possibilities. Thanks!

Sam

Post a reply to this message

On 1/31/2011 1:04 PM, Darren New wrote:
> stbenge wrote:
>> It doesn't use OpenGL. I'm trying to rule out the possibilities :/
>
> Don't you love web development? :-)

When it's not giving me trouble, it's boring the heck out of me (HTML). 
Sometimes it seems like the problems expand outward in a branching 
structure...

I think I can see the end of this limb though :/

Sam

Post a reply to this message

On 31/01/2011 8:53 PM, stbenge wrote:
> Got it, and it's broken! I can now proceed accordingly. Thanks again.

:-D

-- 
Regards
     Stephen

Post a reply to this message

stbenge wrote:
> Sometimes it seems like the problems expand outward in a branching 
> structure...

I have coined the term Zeno's Debugger for that.

Every time you try to figure out what's causing the error, you have to first 
debug the tool you're using to figure out what's causing that error, 
recursively.

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message

On 1/31/2011 1:38 PM, Darren New wrote:
> stbenge wrote:
>> Sometimes it seems like the problems expand outward in a branching
>> structure...
>
> I have coined the term Zeno's Debugger for that.
>
> Every time you try to figure out what's causing the error, you have to
> first debug the tool you're using to figure out what's causing that
> error, recursively.

But what do you call it when the only thing stopping your software's 
deployment is one tiny exe that happens to be bundled into one humongous 
development kit?

I may to jump (or glide slowly) through some hoops to resolve it, but 
I'm 95% sure I know what the problem is: an applet, running under the 
new version of JRE, needs to be /signed/ when using 3rd party libs! D:`

Sam

Post a reply to this message

On 31/01/2011 10:09 PM, stbenge wrote:
> But what do you call it when the only thing stopping your software's
> deployment is one tiny exe that happens to be bundled into one humongous
> development kit?

A b*st*rd? o_O

-- 
Regards
     Stephen

Post a reply to this message

Le 31/01/2011 21:24, stbenge a écrit :
> Thank you all for your input! I'd still like to hear any comments you
> might have, if you can take the time.
>

I spent more time with it, and it is really fascinating ! It looks a lot 
like some sort of physical/biological process. If you can give some 
qualitative information on the way the algorithm works, I'll be very 
interested.  A few things I like particularly:

- the different 'timescales'  : after a click with the mouse, there is 
the rapid process destroying the cell, but the system takes a long time 
to reach a steady state as a whole

- I enjoy a lot when 'thin white lines' enter a big cell, and propagate 
slowly with successive branching, changing in the end a big part of the 
entire geometry.


Thibaut


> One of my goals is to prepare a full-on cellular automata gallery that
> anyone (with a graphics card) can view.
>
> Sam

Post a reply to this message

stbenge wrote:
> On 1/31/2011 1:38 PM, Darren New wrote:
>> stbenge wrote:
>>> Sometimes it seems like the problems expand outward in a branching
>>> structure...
>>
>> I have coined the term Zeno's Debugger for that.
>>
>> Every time you try to figure out what's causing the error, you have to
>> first debug the tool you're using to figure out what's causing that
>> error, recursively.
> 
> But what do you call it when the only thing stopping your software's 
> deployment is one tiny exe that happens to be bundled into one humongous 
> development kit?

So you go to download the kit and you need to make up an account to download 
it. But the make-up-the-account doesn't work through the corporate firewall, 
so you go home. But your home computer has firefox and the download doesn't 
work with that. So you install Chrome and manage to sign up, but they don't 
take gmail addresses for logins. So you go to log in over the VPN, but the 
VPN software has been upgraded, so you need to take your VPN box back to 
work anyway to get reflashed. So you go back to work to download the file 
but it doesn't come through the proxy. So you bypass the proxy but there 
isn't enough temp space to download the package. So you go to back up some 
useful files but the USB drive has gone missing. So you ask around to see 
who has the USB drive .....

When, really, all you wanted was to write a f'ing piece of code.

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message

On 1/31/2011 2:19 PM, Stephen wrote:
> On 31/01/2011 10:09 PM, stbenge wrote:
>> But what do you call it when the only thing stopping your software's
>> deployment is one tiny exe that happens to be bundled into one humongous
>> development kit?
>
> A b*st*rd? o_O

My inclination _is_ to to start using profane expletives, but the Zen 
method of realizing the path I must take fills me with peace. At least I 
know I /can/ resume a long, drawn-out broken download with this 
particular development kit. Fortunately, Sun hasn't taken Microsoft's 
route of providing a "user friendly" download installer that resumes the 
downloads only at 20MB intervals X_x

Sam

Post a reply to this message

On 1/31/2011 3:13 PM, Darren New wrote:
> stbenge wrote:
>> But what do you call it when the only thing stopping your software's
>> deployment is one tiny exe that happens to be bundled into one
>> humongous development kit?
>
> So you go to download the kit and you need to make up an account to
> download it. But the make-up-the-account doesn't work through the
> corporate firewall, so you go home. But your home computer has firefox
> and the download doesn't work with that. So you install Chrome and
> manage to sign up, but they don't take gmail addresses for logins. So
> you go to log in over the VPN, but the VPN software has been upgraded,
> so you need to take your VPN box back to work anyway to get reflashed.
> So you go back to work to download the file but it doesn't come through
> the proxy. So you bypass the proxy but there isn't enough temp space to
> download the package. So you go to back up some useful files but the USB
> drive has gone missing. So you ask around to see who has the USB drive
> .....

Is that talking from personal experience, or extrapolating from a 
possibility? I can see that happening. If only half of what you said has 
actually happened to you, I no longer feel so bad.

> When, really, all you wanted was to write a f'ing piece of code.

I know the thing must be less than 200K, but after reading the 
license/user agreement, I know that that one tiny file can't be 
distributed singularly (without legal repercussions). At least after I 
download the monolith-of-an-development-kit, I can start learning actual 
Java and go beyond the scope of Processing.

Sam

Post a reply to this message

On 1/31/2011 2:49 PM, Thibaut Jonckheere wrote:
> Le 31/01/2011 21:24, stbenge a écrit :
>> Thank you all for your input! I'd still like to hear any comments you
>> might have, if you can take the time.
>
> A few things I like particularly:
>
> - the different 'timescales' : after a click with the mouse, there is
> the rapid process destroying the cell, but the system takes a long time
> to reach a steady state as a whole

Well... cellular automaton simulations are an entirely natural process, 
so these things happen as a matter of consequence. As to just 
/what/exactly/ is being modeled is determined by the purity of the 
calculations. I know that some of my calculations have resulted in an 
approximation of a minimal surface, but others were added to increase 
growth. So maybe we have a biological organism with a lot of mucus...

> - I enjoy a lot when 'thin white lines' enter a big cell, and propagate
> slowly with successive branching, changing in the end a big part of the
> entire geometry.

That's one of the things that puts this sim into its own category. What 
you are seeing is related to reaction/diffusion and minimal surface 
systems, but I really don't think that its behavior is indicative of a 
"pure" minimal surface.

> I spent more time with it, and it is really fascinating ! It looks a lot
> like some sort of physical/biological process. If you can give some
> qualitative information on the way the algorithm works, I'll be very
> interested.

I can't really explain what I did. I know *what* I did, and *why* it 
does it, but ask me to put it into scientific or mathematical terms, and 
you won't get a satisfactory answer.

But here's the GLSL code. I'll attempt to provide useful descriptions:

// these uniform variables are piped in from the governing program:
uniform sampler2D bufA; // a 768x768 16-bit surface
uniform vec2 offset;    // offset.s = 1/768, offset.t = 1/768
uniform int DoPaint;    // is the mouse clicked? (a boolean would be better)
uniform float MX, MY, RX, RY; // mouse X/Y, random values X/Y

// variables for the red, green & blue components
float R, G, B;

// CA      = blur sample
// C0 - C8 = point samples
vec4 CA, C0, C1, C2, C3, C4, C5, C6, C7, C8;

// a noise function (not mine, used for adding noise to Area_Add[below])
float rand(vec2 UV){
  return

  fract(
   sin(
    dot(
     vec2(
      UV.x+RX,
      UV.y+RY
     ),
     vec2(12.9898,78.233)
    )
   )*43758.5453
  );
}

void main(void){

   float dx = offset.s; // 1/768
   float dy = offset.t; // 1/768

   // UV.x = 0.0 to 1.0, UV.y = 0.0 to 1.0
   vec2  UV = gl_TexCoord[0].st;

   // expansion vector (realized with POV)
   // uses the green channel
   vec2 Expansion =
    .0625*vec2(
      texture2D( bufA, UV + .5*vec2(-dx, 0.0) ).g
     -texture2D( bufA, UV + .5*vec2(dx, 0.0) ).g,
      texture2D( bufA, UV + .5*vec2(0.0, -dy) ).g
     -texture2D( bufA, UV + .5*vec2(0.0, dy) ).g
    );

   // applying the expansion to "UV"
   UV += 1.0*Expansion*(texture2D( bufA, UV).g);

   // center sample
   C0 = texture2D( bufA, UV);

   // samples clockwise from upper-left
   // total (with C0): 1 + 2 + .92 = 3.92 (values are also thanks to POV)
   C1 = texture2D( bufA, UV + vec2(-dx, -dy) )*0.23;
   C2 = texture2D( bufA, UV + vec2(0.0, -dy) )*0.5;
   C3 = texture2D( bufA, UV + vec2(+dx, -dy) )*0.23;
   C4 = texture2D( bufA, UV + vec2(+dx, 0.0) )*0.5;
   C5 = texture2D( bufA, UV + vec2(+dx, +dy) )*0.23;
   C6 = texture2D( bufA, UV + vec2(0.0, +dy) )*0.5;
   C7 = texture2D( bufA, UV + vec2(-dx, +dy) )*0.23;
   C8 = texture2D( bufA, UV + vec2(-dx, 0.0) )*0.5;

   // blur sample
   CA = (C0+C1+C2+C3+C4+C5+C6+C7+C8)/3.92;

   if(DoPaint==1){ // paint circular area

    // adds a noisy, circular density when the mouse is clicked
    float Area_Add =
     rand(UV)*clamp(
      1.0-16.0*sqrt( pow(UV.x-MX, 2.0) + pow(UV.y-MY, 2.0) ),
      0.0,
      1.0
     );

    // adds a noisy, circular density when the mouse is clicked
    R = clamp(CA.r + .05*Area_Add, 0.0, 1.0);

    // green is given a blurred version of the red channel
    G = CA.r;

    // blue is given a blurred version of its own channel
    B = CA.b;

   }else{          // return the usual values

    R = CA.r;
    G = CA.r;
    B = CA.b;

   }

   // edge-finding
   B = C0.r+(C0.r-CA.r)*760.0;

   // mix old values with squared edge values
   // ("mix" is the same as a linear interpolation["lerp"])
   B = mix(CA.b, B*B, .025);

   // add blurred edges to primary evaluation channel
   // and decrease all red values over time
   R = R + .045*CA.b - .0203065;

   // subtract blurred edge values from the green channel
   G = G - .107*CA.b;

   // prevent values from going below 0.0 (black) or above 1.0 (white)
   R = clamp(R, 0.0, 1.0);
   G = clamp(G, 0.0, 1.0);
   B = clamp(B, 0.0, 1.0);

   // carry values over to next iteration
   gl_FragColor = vec4(R, G, B, 1.0);

}

Post a reply to this message

stbenge wrote:
> Is that talking from personal experience, or extrapolating from a 
> possibility? I can see that happening.

That was a description of the *kind* of thing that happened to me on a 
regular basis at my previous job, yes. Between the code and the people 
providing the code, it was the most distasteful job I've ever had, really. 
And that counts customer service at the deli.

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message

On 01/02/2011 12:00 AM, stbenge wrote:
> My inclination _is_ to to start using profane expletives, but the Zen
> method of realizing the path I must take fills me with peace.

Ah! My son. You will realise, after years of study and training that the 
circle can be completed and the mind’s control of the body is as nothing 
to letting rip when the hammer of fate connects with the thumb of life.
So take yourself into the desert and kick the coyote until He gives you 
the gift of fire.


-- 
Regards
     Stephen

Post a reply to this message

On 1/31/2011 5:30 PM, Stephen wrote:
> On 01/02/2011 12:00 AM, stbenge wrote:
>> My inclination _is_ to to start using profane expletives, but the Zen
>> method of realizing the path I must take fills me with peace.
>
> Ah! My son.

You aren't my father! No! No! (getting carried away with Star Wars 
geekiabilia there)

> You will realise, after years of study and training that the
> circle can be completed and the mind’s control of the body is as nothing
> to letting rip when the hammer of fate connects with the thumb of life.
> So take yourself into the desert and kick the coyote until He gives you
> the gift of fire.

I've done that, but it really doesn't work. Expressing emotional turmoil 
to desert creatures (or other socially arid inhabitants) doesn't really 
accomplish much, although you /do/ get some exercise.

Sam

Post a reply to this message

stbenge wrote:
> My inclination _is_ to to start using profane expletives, 

Profanity is my number one debugging tool.

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message

> As it turns out, there were two places to change the window size, so it
> should be fixed now.

OK it's working now, very smooth.

Post a reply to this message

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

On 01/02/2011 2:15 AM, stbenge wrote:
> On 1/31/2011 5:30 PM, Stephen wrote:
>> On 01/02/2011 12:00 AM, stbenge wrote:
>>> My inclination _is_ to to start using profane expletives, but the Zen
>>> method of realizing the path I must take fills me with peace.
>>
>> Ah! My son.
>
> You aren't my father! No! No! (getting carried away with Star Wars
> geekiabilia there)
>

It is so easy. :-)

>> You will realise, after years of study and training that the
>> circle can be completed and the mind’s control of the body is as nothing
>> to letting rip when the hammer of fate connects with the thumb of life.
>> So take yourself into the desert and kick the coyote until He gives you
>> the gift of fire.
>
> I've done that, but it really doesn't work. Expressing emotional turmoil
> to desert creatures (or other socially arid inhabitants) doesn't really
> accomplish much, although you /do/ get some exercise.
>

Just slap your computer, then.


-- 
Regards
     Stephen

Post a reply to this message

On 1/31/2011 6:54 PM, Darren New wrote:
> stbenge wrote:
>> My inclination _is_ to to start using profane expletives,
>
> Profanity is my number one debugging tool.

lol!

Post a reply to this message

On 2/1/2011 4:04 AM, Stephen wrote:
> On 01/02/2011 2:15 AM, stbenge wrote:
>> On 1/31/2011 5:30 PM, Stephen wrote:
>>> On 01/02/2011 12:00 AM, stbenge wrote:
>>>> My inclination _is_ to to start using profane expletives, but the Zen
>>>> method of realizing the path I must take fills me with peace.
>>>
>>> Ah! My son.
>>
>> You aren't my father! No! No! (getting carried away with Star Wars
>> geekiabilia there)
>
> It is so easy. :-)

Just when you think you have it under control, someone cuts off your 
hand and starts making outrageous parental claims :(

> Just slap your computer, then.

OK... . whoa, that's a lot of dust!

Post a reply to this message

On 2/1/2011 12:39 AM, scott wrote:
>> As it turns out, there were two places to change the window size, so it
>> should be fixed now.
>
> OK it's working now, very smooth.

Cool.

Post a reply to this message

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

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

Security restrictions block OpenGL? Man, whatever next...

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

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

>> It is worth noting that, certainly for RD systems, almost all
>> combinations of parameter settings do absolutely nothing interesting at
>> all.
>
> 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. ;-)

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

Well, a tiny inner loop custom-coded in assembly... Go check out Project 
Euler. Apparently people really do still write assembly by hand. Go figure!

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

No kidding. It certainly wasn't back in 1997.

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

Oh, well, no wonder its fast then. The graphics card is purposely 
engineered to eat calculations like this for breakfast.

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

Yeah, Milkdrop basically 0wnz. Created by the same guy as the old Geiss 
plugin too... That is one talented guy!

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.

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

Right. I assumed it way rate-limited because it wasn't using all 
available CPU power.

Post a reply to this message

On 01/02/2011 6:18 PM, stbenge wrote:
>>> You aren't my father! No! No! (getting carried away with Star Wars
>>> geekiabilia there)
>>
>> It is so easy. :-)
>
> Just when you think you have it under control, someone cuts off your
> hand and starts making outrageous parental claims :(
>

There, there, there. :-)

>> Just slap your computer, then.
>
> OK... . whoa, that's a lot of dust!

Hot dust?

-- 
Regards
     Stephen

Post a reply to this message

Invisible wrote:
> Wait - it's written in *Java* and yet it can access the *graphics card*??
> How is that even possible?

It's not. It's using a library interface between Java and OpenGL probably 
written in C or C++. Hence the security restrictions people were talking about.

The CA is written in Java, but the graphics code is still in C-ish and 
shader language and such.

> does them in realtime, even though that's clearly impossible.

Back to that again? ;-)

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message

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