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