Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #34027 > unrolled thread

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

Back to article view | Back to comp.lang.javascript

Contents

  pre-alpha vector field DLA, with point-and-click attractors... "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2017-09-24 21:56 -0700
    Re: pre-alpha vector field DLA, with point-and-click attractors... Julio Di Egidio <julio@diegidio.name> - 2017-09-24 22:36 -0700
      Re: pre-alpha vector field DLA, with point-and-click attractors... "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2017-09-24 22:44 -0700
        Re: pre-alpha vector field DLA, with point-and-click attractors... Julio Di Egidio <julio@diegidio.name> - 2017-09-24 22:54 -0700
          Re: pre-alpha vector field DLA, with point-and-click attractors... "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2017-09-25 12:31 -0700
            Re: pre-alpha vector field DLA, with point-and-click attractors... Julio Di Egidio <julio@diegidio.name> - 2017-09-26 09:05 -0700
              Re: pre-alpha vector field DLA, with point-and-click attractors... "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2017-09-28 21:24 -0700
                Re: pre-alpha vector field DLA, with point-and-click attractors... Julio Di Egidio <julio@diegidio.name> - 2017-09-29 06:47 -0700
          Re: pre-alpha vector field DLA, with point-and-click attractors... "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2017-09-25 12:39 -0700
    Re: pre-alpha vector field DLA, with point-and-click attractors... "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-09-25 22:00 +0200
      Re: pre-alpha vector field DLA, with point-and-click attractors... "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2017-09-25 13:25 -0700
        Re: pre-alpha vector field DLA, with point-and-click attractors... "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-09-25 22:36 +0200
          Re: pre-alpha vector field DLA, with point-and-click attractors... "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2017-09-27 13:38 -0700
    Re: pre-alpha vector field DLA, with point-and-click attractors... Une Bévue <unbewusst.sein@fai.invalid> - 2017-09-26 05:50 +0200
      Re: pre-alpha vector field DLA, with point-and-click attractors... "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2017-09-27 13:19 -0700
        Re: pre-alpha vector field DLA, with point-and-click attractors... "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2017-09-30 08:41 -0700
          Re: pre-alpha vector field DLA, with point-and-click attractors... "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2017-10-04 20:48 -0700
            Re: pre-alpha vector field DLA, with point-and-click attractors... "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2017-10-05 08:25 -0700

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

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.

[toc] | [next] | [standalone]

#34028

On Monday, September 25, 2017 at 6:56:52 AM UTC+2, Chris M. Thomasson wrote:
> 
> 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.

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

Julio

[toc] | [prev] | [next] | [standalone]

#34029

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

[toc] | [prev] | [next] | [standalone]

#34030

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

[toc] | [prev] | [next] | [standalone]

#34031

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

[toc] | [prev] | [next] | [standalone]

#34037

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

[toc] | [prev] | [next] | [standalone]

#34056

On 9/26/2017 9:05 AM, Julio Di Egidio wrote:
> 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.

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

[toc] | [prev] | [next] | [standalone]

#34061

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

[toc] | [prev] | [next] | [standalone]

#34032

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.


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

[toc] | [prev] | [next] | [standalone]

#34033

"Chris M. Thomasson" <invalid_chris_thomasson@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)

[toc] | [prev] | [next] | [standalone]

#34034

On 9/25/2017 1:00 PM, Evertjan. wrote:
> "Chris M. Thomasson" <invalid_chris_thomasson@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

[toc] | [prev] | [next] | [standalone]

#34035

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

> On 9/25/2017 1:00 PM, Evertjan. wrote:
>> "Chris M. Thomasson" <invalid_chris_thomasson@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

Wow, you have been buzy for a long time.


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

[toc] | [prev] | [next] | [standalone]

#34041

On 9/25/2017 1:36 PM, Evertjan. wrote:
> "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> wrote on 25
> Sep 2017 in comp.lang.javascript:
> 
>> On 9/25/2017 1:00 PM, Evertjan. wrote:
>>> "Chris M. Thomasson" <invalid_chris_thomasson@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
> 
> Wow, you have been buzy for a long time.

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

[toc] | [prev] | [next] | [standalone]

#34036

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

[toc] | [prev] | [next] | [standalone]

#34040

On 9/25/2017 8:50 PM, Une Bévue wrote:
> 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
> 

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.

[toc] | [prev] | [next] | [standalone]

#34082

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>

[toc] | [prev] | [next] | [standalone]

#34097

On 9/30/2017 8:41 AM, Michael Haufe (TNO) wrote:
> 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>
> 

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

[toc] | [prev] | [next] | [standalone]

#34098

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web