pre-alpha vector field DLA, with point-and-click attractors...

[Chris M. Thomasson]

Fwiw, here is a rendering of a DLA cluster that was grown online:

https://plus.google.com/101799841244447089430/posts/LjJesbaokGd

in the following pre-alpha highly experimental program I created:

http://funwithfractals.atspace.cc/ct_fdla_anime_dynamic_test

The code can be streamlined quite a bit, but it should go ahead and work
for now.

It starts off with a single strong attracting agent in the center of a
parametric square with an equation of:

x = cos(t) * abs(cos(t))
y = sin(t) * abs(sin(t))

Particles are released from this square, and are immediately influenced
by the center point attractor. They will hit the point and start to
build a DLA cluster. This is all animated.

If you let the program run, it will try to fill the square with this
single DLA cluster. However, I added the ability to click on a point,
and create an attractor with a weaker influence than the center. You
should be able to let it run for a little while, then click some points
in the square and watch particles be dynamically attracted to, and hit
them. Each hit creates a new attractor. This is how it grows.

My source code is all there.

Can anybody get it to work? Thanks.

[Julio Di Egidio]

What do you mean? Doesn't it work already?

Julio

[Chris M. Thomasson]

I have not tried it out in all of the browsers yet. Still need to try
SeaMonkey. It works in FireFox, so it should work there. Also, need to
try it in Opera. Afaict, it should work fine.

[Julio Di Egidio]

On Monday, September 25, 2017 at 7:45:00 AM UTC+2, Chris M. Thomasson wrote:
> On 9/24/2017 10:36 PM, Julio Di Egidio wrote:
> > On Monday, September 25, 2017 at 6:56:52 AM UTC+2, Chris M. Thomasson wrote:

<snip>

> >> Can anybody get it to work? Thanks.
> >
> > What do you mean? Doesn't it work already?
>
> I have not tried it out in all of the browsers yet. Still need to try
> SeaMonkey. It works in FireFox, so it should work there. Also, need to
> try it in Opera. Afaict, it should work fine.

Well, it's hard to fix or even improve if you do not give the exact mathematical formula (unless you already have and I am missing it).

Anyway, it's running in my (up to date) Google Chrome, the only weird thing
I have noticed (running it for few minutes only) is that it seems to get
stuck at the points created manually, i.e. it seems to almost stop growing
as soon as I add points: but maybe I should have waited for longer? Again,
I just cannot say what exact outcome is expected.

Julio

[Chris M. Thomasson]

On 9/24/2017 10:54 PM, Julio Di Egidio wrote:
> On Monday, September 25, 2017 at 7:45:00 AM UTC+2, Chris M. Thomasson wrote:
>> On 9/24/2017 10:36 PM, Julio Di Egidio wrote:
>>> On Monday, September 25, 2017 at 6:56:52 AM UTC+2, Chris M. Thomasson wrote:
> <snip>
>>>> Can anybody get it to work? Thanks.
>>>
>>> What do you mean? Doesn't it work already?
>>
>> I have not tried it out in all of the browsers yet. Still need to try
>> SeaMonkey. It works in FireFox, so it should work there. Also, need to
>> try it in Opera. Afaict, it should work fine.
>
> Well, it's hard to fix or even improve if you do not give the exact mathematical formula (unless you already have and I am missing it).

Working on that. I need to convert the following core logic into a
mathematical formula:

http://funwithfractals.atspace.cc/ct_fdla_anime_dynamic_test/ct_field.js

Think I can get it down to one or two iterative Sigma functions.

http://funwithfractals.atspace.cc/ct_fdla_anime_dynamic_test/ct_fdla.js

This one is going to be more difficult to turn into pure mathematical
formula.

> Anyway, it's running in my (up to date) Google Chrome, the only weird thing
> I have noticed (running it for few minutes only) is that it seems to get
> stuck at the points created manually, i.e. it seems to almost stop growing
> as soon as I add points: but maybe I should have waited for longer? Again,
> I just cannot say what exact outcome is expected.

Can you please let it run for around a minute then click a couple of
points in the square, let it run for around 10 more minutes, take a
simple screenshot and post the image? The points you clicked should have
clusters by then. This would really help me out!

Also, if a cluster A is growing and you click around it creating cluster
B, well, B can have a tendency to take up more particles than A.
Basically, it casts shade for A's growth, and ends up slowing its growth
rate. Think of being a little plant, then some other plant casts a large
shade leaf over you.

When you get some time, I would really appreciate being able to see some
screenshots showing the results you are getting.

Thanks for any help here Julio.

One more point, your computer is probably faster than mine, so one
minute of growth might be different. ;^)

[Chris M. Thomasson]

On 9/24/2017 10:54 PM, Julio Di Egidio wrote:
> On Monday, September 25, 2017 at 7:45:00 AM UTC+2, Chris M. Thomasson wrote:
>> On 9/24/2017 10:36 PM, Julio Di Egidio wrote:
>>> On Monday, September 25, 2017 at 6:56:52 AM UTC+2, Chris M. Thomasson wrote:
> <snip>
>>>> Can anybody get it to work? Thanks.
>>>
>>> What do you mean? Doesn't it work already?
>>
>> I have not tried it out in all of the browsers yet. Still need to try
>> SeaMonkey. It works in FireFox, so it should work there. Also, need to
>> try it in Opera. Afaict, it should work fine.
>
> Well, it's hard to fix or even improve if you do not give the exact mathematical formula (unless you already have and I am missing it).
>
> Anyway, it's running in my (up to date) Google Chrome, the only weird thing
> I have noticed (running it for few minutes only) is that it seems to get
> stuck at the points created manually,

Now, when you say stuck, does it actually stop casting the animated
particles out? So far, I have not been able to re-create a condition
like this. You should always be able to see the animated particles
flowing from the edge of the square into the DLA.

[Evertjan.]

"Chris M. Thomasson" <invalid_chr...@invalid.invalid> wrote on 25
Sep 2017 in comp.lang.javascript:

> Fwiw, here is a rendering of a DLA cluster that was grown online:
>
> https://plus.google.com/101799841244447089430/posts/LjJesbaokGd
>
> in the following pre-alpha highly experimental program I created:
>
> http://funwithfractals.atspace.cc/ct_fdla_anime_dynamic_test
>
> The code can be streamlined quite a bit, but it should go ahead and work
> for now.

Nice!

What about a 3-dimensional one?

<https://youtu.be/eAB5ZyG4KWE>

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Chris M. Thomasson]

On 9/25/2017 1:00 PM, Evertjan. wrote:
> "Chris M. Thomasson" <invalid_chr...@invalid.invalid> wrote on 25
> Sep 2017 in comp.lang.javascript:
>
>> Fwiw, here is a rendering of a DLA cluster that was grown online:
>>
>> https://plus.google.com/101799841244447089430/posts/LjJesbaokGd
>>
>> in the following pre-alpha highly experimental program I created:
>>
>> http://funwithfractals.atspace.cc/ct_fdla_anime_dynamic_test
>>
>> The code can be streamlined quite a bit, but it should go ahead and work
>> for now.
>
> Nice!

Thank you for giving it a go Evertjan. :^)

> What about a 3-dimensional one?
>
> <https://youtu.be/eAB5ZyG4KWE>

Ahhh! Very nice indeed. I can do it, just need a little more time.
Adding the z vector to my program is actually not all that hard at all.
WebGL can be used to rendering everything. I already have some crude 3d
vector field work in WebGL online:

http://funwithfractals.atspace.cc/ct_gfield_test/ct_3dgfield_anime_test

http://funwithfractals.atspace.cc/ct_gfield_test

Fwiw, check this out:

https://plus.google.com/101799841244447089430/posts/PU1rRsaEUzK

Equipotential lines in 3d. ;^o

[Evertjan.]

Wow, you have been buzy for a long time.

[Une Bévue]

Le 25/09/2017 à 06:56, Chris M. Thomasson a écrit :
>
> in the following pre-alpha highly experimental program I created:
>
> http://funwithfractals.atspace.cc/ct_fdla_anime_dynamic_test
>
> The code can be streamlined quite a bit, but it should go ahead and work
> for now.

it runs on Safari Developer Preview

[Julio Di Egidio]

On Monday, September 25, 2017 at 9:31:33 PM UTC+2, Chris M. Thomasson wrote:
> On 9/24/2017 10:54 PM, Julio Di Egidio wrote:
> > On Monday, September 25, 2017 at 7:45:00 AM UTC+2, Chris M. Thomasson wrote:
> >> On 9/24/2017 10:36 PM, Julio Di Egidio wrote:
> >>> On Monday, September 25, 2017 at 6:56:52 AM UTC+2, Chris M. Thomasson wrote:
> > <snip>
> >>>> Can anybody get it to work? Thanks.
> >>>
> >>> What do you mean? Doesn't it work already?
> >>
> >> I have not tried it out in all of the browsers yet. Still need to try
> >> SeaMonkey. It works in FireFox, so it should work there. Also, need to
> >> try it in Opera. Afaict, it should work fine.
> >
> > Well, it's hard to fix or even improve if you do not give the exact
> > mathematical formula (unless you already have and I am missing it).
>
> Working on that. I need to convert the following core logic into a
> mathematical formula:
>
> http://funwithfractals.atspace.cc/ct_fdla_anime_dynamic_test/ct_field.js
>
> Think I can get it down to one or two iterative Sigma functions.
>
> http://funwithfractals.atspace.cc/ct_fdla_anime_dynamic_test/ct_fdla.js
>
> This one is going to be more difficult to turn into pure mathematical
> formula.

Sorry, I was a bit quick, but I actually meant that we need a specification
to work with. That is not usually as simple as just a mathematical formula,
anyway I didn't meant to make the conversation too heavy, either.

That said, I will look into the code when I find some time: might be
already correct mathematically, but it is very heavy on the CPU.

> > Anyway, it's running in my (up to date) Google Chrome, the only weird thing
> > I have noticed (running it for few minutes only) is that it seems to get
> > stuck at the points created manually, i.e. it seems to almost stop growing
> > as soon as I add points: but maybe I should have waited for longer? Again,
> > I just cannot say what exact outcome is expected.
>
> Can you please let it run for around a minute then click a couple of
> points in the square, let it run for around 10 more minutes, take a
> simple screenshot and post the image? The points you clicked should have
> clusters by then. This would really help me out!

Sorry again, it seems to work fine, actually. Here is the screenshot of a
run, where I have let it run for 1 minute, then I have added 4 points and
let it run for 5 more minutes (then stopped as my CPU was over-heating:-):
<https://drive.google.com/file/d/0BxPmJcnnbWOTZVdKYlJ5NEh0em8/view>

> One more point, your computer is probably faster than mine, so one
> minute of growth might be different. ;^)

I am on a high-end laptop with an AMD Radeon on board, nothing more than
that. The browser is not taking advantage of the AMD GPU anyway, but
right away I wouldn't know how to improve on that (or maybe force the
canvas to use the GPU?). To be investigated...

Julio

[Chris M. Thomasson]

Thank you for giving it a go Une! I can make it better wrt a different
way of programming. This tends to overwhelm the cpu with computation and
the use of the garbage collector. Wrt GC, the JavaScript engines tend to
create new object for every array passed to a function. For instance, I
can pass two 3d points and a radius like this wrt the style of my
current code:

foo([-1, 0, 0], [1, 0, 0], 1);

Each array index is mapped to (a[0] = x), (a[1] = y) and (a[2] = z).

This will create two damn arrays for each call! And those go into the
GC. Read here for some further information:

https://groups.google.com/d/topic/comp.lang.javascript/dgakiMzhgv0/discussion

Also, it can burn CPU because DLA points never die off! I need to allow
them to die off and leave the per-field-line segment vector field
summation. The more points, the slower it goes. I wonder if changing the
color of the field lines to grey, or some color that designates turning
"brown/yellow", or the interpolation of the death cycle wrt specific
colors. The act of death would take pressure off the core field logic
wrt reducing iterations.

[Chris M. Thomasson]

;^) Actually, if you look at my code in here:

http://funwithfractals.atspace.cc/ct_fdla_anime_dynamic_test/ct_field.js

Well, I forgot that its already using a 3d vector. Notice how the dif
variable is calculated in:
____________________
var dif = [e[0] - p[0], e[1] - p[1], e[2] - p[2]];
____________________
dif, e and p have three parts. Therefore, its 3d. Cannot believe I did
not notice this. Wrt the 2d canvas, this z-axis is not needed at all!
Damn it.

Performing the iterative summation to get a normalized vector for use on
a per-line-segment basis:
____________________
if (mass > ESP && ! isNaN(mass) && isFinite(mass))
{
g[0] = g[0] + e[3] * dif[0] / mass;
g[1] = g[1] + e[3] * dif[1] / mass;
g[2] = g[2] + e[3] * dif[2] / mass;
}
____________________
g has three parts! I accidentally put my 3d vector field into a 2d
scenario. It still works, but its using unnecessary calculations that
have no bearing on the actual 2d plotting logic.

Sorry about that.

[Chris M. Thomasson]

Still thinking about how to word the specification. It comes in two
layers, the vector field and the logic for the interactions between
particles and attractors in said field. The logic layer shows how a
particle gets cast from a point and computes its vector field line,
segment by segment, until it hits an attractor or runs out of
iterations. If it hits, the segment from attractor to previous point in
the field line is drawn, and the previous point becomes a new attracting
agent. Well, this can get very computationally intensive! It will burn CPU.

I need to code it a different way wrt:

https://groups.google.com/d/topic/comp.lang.javascript/dgakiMzhgv0/discussion

The garbage collector is going crazy here.

>>> Anyway, it's running in my (up to date) Google Chrome, the only weird thing
>>> I have noticed (running it for few minutes only) is that it seems to get
>>> stuck at the points created manually, i.e. it seems to almost stop growing
>>> as soon as I add points: but maybe I should have waited for longer? Again,
>>> I just cannot say what exact outcome is expected.
>>
>> Can you please let it run for around a minute then click a couple of
>> points in the square, let it run for around 10 more minutes, take a
>> simple screenshot and post the image? The points you clicked should have
>> clusters by then. This would really help me out!
>
> Sorry again, it seems to work fine, actually. Here is the screenshot of a
> run, where I have let it run for 1 minute, then I have added 4 points and
> let it run for 5 more minutes (then stopped as my CPU was over-heating:-):
> <https://drive.google.com/file/d/0BxPmJcnnbWOTZVdKYlJ5NEh0em8/view>

Very nice: Your screenshot is excellent information for me. Thank you so
much for giving it more time. I really do appreciate it Julio.

>> One more point, your computer is probably faster than mine, so one
>> minute of growth might be different. ;^)
>
> I am on a high-end laptop with an AMD Radeon on board, nothing more than
> that. The browser is not taking advantage of the AMD GPU anyway, but
> right away I wouldn't know how to improve on that (or maybe force the
> canvas to use the GPU?). To be investigated...

Well, unfortunately, if I do not add some method to allow attractors to
"die off" during the simulation, it will eventually overwhelm a GPU
and/or CPU.

Wrt, implementing on GPU, I was thinking of a limited form using/abusing
Uniform variables where the GPU can perform the critical vector field
summation function. Need to think about how to implement the DLA hit
logic in GPU. I am not sure its going to like it...

[Julio Di Egidio]

On Friday, September 29, 2017 at 6:24:25 AM UTC+2, Chris M. Thomasson wrote:

> I need to code it a different way wrt:
> <https://groups.google.com/d/topic/comp.lang.javascript/dgakiMzhgv0/discussion>
>
> The garbage collector is going crazy here.

Still haven't found the time to actually look at your code, but I have had
a look at that discussion. Isn't what you call "non-intrusive" equivalent
to "purely functional"? Anyway, I think the key point there is that JS
arrays are nothing like the low-level C arrays you may still be thinking of:
they are full-fledged objects just whose property names are non-negative
integers, in fact e.g. JS arrays are sparse. You can find more (and more
precisely put) details in the docs, anyway I think that explains why you
should indeed expect using arrays to be slightly slower than using plain
objects in JS. OTOH, I'd expect the difference to be at most minuscule in
any sane implementation, so I'd more object to that style (to begin with)
because of readability: c.re is arguably more expressive than c[0].

Julio

[Michael Haufe (TNO)]

Chris M. Thomasson wrote:
>
> Thank you for giving it a go Une! I can make it better wrt a different
> way of programming. This tends to overwhelm the cpu with computation and
> the use of the garbage collector. Wrt GC, the JavaScript engines tend to
> create new object for every array passed to a function. For instance, I
> can pass two 3d points and a radius like this wrt the style of my
> current code:
>
> foo([-1, 0, 0], [1, 0, 0], 1);
>
> Each array index is mapped to (a[0] = x), (a[1] = y) and (a[2] = z).
>
> This will create two damn arrays for each call! And those go into the
> GC. Read here for some further information:
>
> https://groups.google.com/d/topic/comp.lang.javascript/dgakiMzhgv0/discussion
>
> Also, it can burn CPU because DLA points never die off! I need to allow
> them to die off and leave the per-field-line segment vector field
> summation. The more points, the slower it goes. I wonder if changing the
> color of the field lines to grey, or some color that designates turning
> "brown/yellow", or the interpolation of the death cycle wrt specific
> colors. The act of death would take pressure off the core field logic
> wrt reducing iterations.

I threw a quick codepen together of your code and did a very high level translation to ES6+ with minimal impact:

<https://codepen.io/mlhaufe/project/editor/XNGeEv#0>

I'm hoping this could aid in the discussion and evolution.

I didn't see why you needed the requestAnimation polyfill. I think there is sufficient support for it now:

<http://caniuse.com/#feat=requestanimationframe>

[Chris M. Thomasson]

Your codepen works like a charm Michael! Thank you so much for your time
and energy wrt helping my code be more modern. Seriously, I am a little
stuck in the past wrt JavaScript, the polyfill for anime loop. Ack.

Well, I did go a step further and implemented my experimental vector
field in a GLSL shader:

https://www.shadertoy.com/view/XljcRR

Does this work for you?

Thanks again man. :^)

[Michael Haufe (TNO)]

Chris M. Thomasson wrote:

> Well, I did go a step further and implemented my experimental vector
> field in a GLSL shader:
>
> https://www.shadertoy.com/view/XljcRR
>
> Does this work for you?

Of course, and the FPS is ~60 across a number of browsers. Keep in mind that this new implementation becomes off-topic for CLJS though