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

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

An online circle intersection fractal...

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

Contents

  An online circle intersection fractal... "Chris M. Thomasson" <no@spam.invalid> - 2013-11-02 13:43 -0700
    Re: An online circle intersection fractal... "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-11-03 17:55 -0800
    Re: An online circle intersection fractal... "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-11-03 18:55 -0800
      Re: An online circle intersection fractal... "Chris M. Thomasson" <no@spam.invalid> - 2013-11-04 14:01 -0800
        Re: An online circle intersection fractal... "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-11-04 18:40 -0800
          Re: An online circle intersection fractal... "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-11-04 18:42 -0800
          Re: An online circle intersection fractal... "Chris M. Thomasson" <no@spam.invalid> - 2013-11-05 13:05 -0800
            Re: An online circle intersection fractal... "Chris M. Thomasson" <no@spam.invalid> - 2013-11-05 14:35 -0800
              Re: An online circle intersection fractal... "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-11-10 23:48 -0800
          Re: An online circle intersection fractal... Dr J R Stockton <reply1300@merlyn.demon.co.uk.invalid> - 2013-11-06 19:41 +0000
            Re: An online circle intersection fractal... "Chris M. Thomasson" <no@spam.invalid> - 2013-11-07 12:46 -0800
      Re: An online circle intersection fractal... "Chris M. Thomasson" <no@spam.invalid> - 2013-11-04 14:03 -0800
    Re: An online circle intersection fractal... "Chris M. Thomasson" <no@spam.invalid> - 2013-11-05 22:19 -0800

#21857 — An online circle intersection fractal...

The fractal is simple. Find circle intersections, draw circles at those 
points,
then find all of the newly generated intersections, and repeat... You can
create some pretty nice fractals that way. Also, it seems as if circle 
inter-
sections can be used for other applications as well...

I was wondering if my code is total crap or not. Please, any advise would be
extremely beneficial. I just hope it does not involve a complete rewrite.
Luckily, this software is in pre-alpha stages:

http://webpages.charter.net/appcore/fractal/ttr

The most important setting is the first input box on the list: Iters = N,
where the default is N = 0. Now, be careful with this. Start small,
say N <= 7, to get a feel for it. If you set N to high, the computer will
crank away, and freeze the fuc%ing browser. Therefore, I need to
integrate the fractal iteration within an animation render loop, and
introduce a play/pause button.


Here are some settings you can enter in that creates, IMVHO , some
fairly interesting fractals:

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

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



Here are some other renderings generated online, unfortunately I did not 
post
the settings for these:

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

https://plus.google.com/101799841244447089430/posts/7dHMHfpH9Cb

https://plus.google.com/101799841244447089430/posts/6bimsLsxqK4

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



BTW, I need to add color, damn it!  ;^/

The circle intersection used in the algorithm can be found here:

webpages.charter.net/appcore/fractal/ttr/circle_isect/circle_isect_draft.pdf



Also, here is an older CSS3 fractal animation I made a while back:

https://groups.google.com/forum/#!topic/alt.html/CKTlED4wTfo

http://webpages.charter.net/appcore/ctfractal.html



Enjoy!

;^) 

[toc] | [next] | [standalone]

#21890

On Saturday, November 2, 2013 3:43:00 PM UTC-5, Chris M. Thomasson wrote:
>
> Also, here is an older CSS3 fractal animation I made a while back:
> 
> https://groups.google.com/forum/#!topic/alt.html/CKTlED4wTfo

Sadly, while Firefox completely dominates other browsers in terms of JavaScript performance on functional/type stable programs, sadly they are still struggling on CSS animation performance for more than one reason. For instance: <https://bug886530.bugzilla.mozilla.org/attachment.cgi?id=766896>

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

#21893

On Saturday, November 2, 2013 3:43:00 PM UTC-5, Chris M. Thomasson wrote:
> The fractal is simple. Find circle intersections, draw circles at those 
> points,
> then find all of the newly generated intersections, and repeat... You can
> create some pretty nice fractals that way. Also, it seems as if circle 
> inter-
> sections can be used for other applications as well...

First off, I'm glad to see some more fractal applications being displayed. Being able to pass in the settings through url arguments would be a nice addition I think.

> I was wondering if my code is total crap or not. Please, any advise would be
> extremely beneficial. I just hope it does not involve a complete rewrite.
> Luckily, this software is in pre-alpha stages:

The fact that you can produce significant results in a timely manner demonstrates that it wouldn't fall under "total crap" imo. One must be wary of letting the best be the enemy of the good.

While I've yet to take much time looking at it yet, my first thought is to whether using polar coordinates instead of Cartesian would make things clearer or not. So thinking out loud here: A circle in cartesian "x^2 + y^2 = 1" becomes "r = 1" in polar. So while the representations are far simpler, the intersection can be a bit more difficult as there are infinite equivalent answers.

A requestAnimationFrame wrapper I prefer to use currently:

window.requestAnimFrame = (function(){
    return  window.requestAnimationFrame   || 
        window.webkitRequestAnimationFrame || 
        window.mozRequestAnimationFrame    || 
        window.oRequestAnimationFrame      || 
        window.msRequestAnimationFrame     || 
        function(run){
            window.setTimeout(run, 16);
        };
})();

Also, I'm quite certain it will be a bit faster to render against the canvas image data instead of using the API. You'll have to roll your own circle drawing routine, but since this is a labor of love, I suspect you might not mind for the performance boost.

clearRect(...) on the entire display can be slow. Do this instead:

myCanvas.width = myCanvas.width

More thoughts to come as time permits

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

#21896

> "Michael Haufe (TNO)"  wrote in message news:935bd61f-b8bd-456a-8813->
> 3b00b2ebddb4@googlegroups.com...

> On Saturday, November 2, 2013 3:43:00 PM UTC-5, Chris M. Thomasson wrote:
> > The fractal is simple. Find circle intersections, draw circles at those
> > points,
> > then find all of the newly generated intersections, and repeat... You 
> > can
> > create some pretty nice fractals that way. Also, it seems as if circle
> > inter-
> > sections can be used for other applications as well...

> First off, I'm glad to see some more fractal applications
> being displayed.

Thank you.


> Being able to pass in the settings
> through url arguments would be a nice addition I think.

100% agreed!  :^)



> > I was wondering if my code is total crap or not. Please, any advise 
> > would be
> > extremely beneficial. I just hope it does not involve a complete 
> > rewrite.
> > Luckily, this software is in pre-alpha stages:

> The fact that you can produce significant results in a
> timely manner demonstrates that it wouldn't fall under
> "total crap" imo. One must be wary of letting the best
> be the enemy of the good.

> While I've yet to take much time looking at it yet, my
> first thought is to whether using polar coordinates instead
> of Cartesian would make things clearer or not. So thinking
> out loud here: A circle in cartesian "x^2 + y^2 = 1" becomes
> "r = 1" in polar. So while the representations are far
> simpler, the intersection can be a bit more difficult as
> there are infinite equivalent answers.

IMVHO, the algorihtm as-is is fairly nice because it solves for the 
intersection(s) of two circles using only a single sqrt operation. So far, 
this is pretty good when compared to most of the other soultions I have seen 
that rely on more than one sqrt and/or trig functions.

Do you happen have something in mind that can find the true intersection(s) 
of two circles that gets around any sqrt wrt polar coordinates? I am all 
ears if you have something to share!   ;^)



> A requestAnimationFrame wrapper I prefer to use currently:

> window.requestAnimFrame = (function(){
>     return  window.requestAnimationFrame   ||
>         window.webkitRequestAnimationFrame ||
>         window.mozRequestAnimationFrame    ||
>         window.oRequestAnimationFrame      ||
>         window.msRequestAnimationFrame     ||
>         function(run){
>             window.setTimeout(run, 16);
>         };
> })();

> Also, I'm quite certain it will be a bit faster to render
> against the canvas image data instead of using the API.
> You'll have to roll your own circle drawing routine, but
> since this is a labor of love, I suspect you might not
> mind for the performance boost.

> clearRect(...) on the entire display can be slow. Do this instead:

> myCanvas.width = myCanvas.width

> More thoughts to come as time permits


Thank you for all of the suggestions Michael. I really do appreaciate the 
fact that you give a damn about fractals!

;^) 

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

#21900

On Monday, November 4, 2013 4:01:19 PM UTC-6, Chris M. Thomasson wrote:
>
> Do you happen have something in mind that can find the true intersection(s)  
> of two circles that gets around any sqrt wrt polar coordinates? I am all 
> ears if you have something to share!   ;^)

I thought about it a little more, and my thought is that because you are creating a fractal consisting of a significant number of circles any form of calculation like the one you are using or the one I was initially thinking is going to be terrible in performance.

If you instead follow my idea of directly plotting the circles on the pixel array itself, you could find the intersection points with no calculation at all:

setOfIntersectPoints.concat(plotCircle(x,y,r));

when you draw the circle on the pixel array, you can look at the color of the current pixel before you plot the point. So if the default color of the canvas is white, and circles are black when plotted, the intersection of the current circle and ALL of the relevant circles in the region would be where the pixel is already black.

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

#21901

On Monday, November 4, 2013 8:40:13 PM UTC-6, Michael Haufe (TNO) wrote:

> setOfIntersectPoints.concat(plotCircle(x,y,r));

I forgot to mention that my intent here was that your circle plotting function would return an array/set of intersect points that you can use on the next loop of your fractal plot

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

#21902

> "Michael Haufe (TNO)"  wrote in message news:34ae1ec8-f301-4a46-bdc1-> 
> f2c2be3d7d4a@googlegroups.com...

> On Monday, November 4, 2013 4:01:19 PM UTC-6, Chris M. Thomasson wrote:
> >
> > Do you happen have something in mind that can find the true 
> > intersection(s)
> > of two circles that gets around any sqrt wrt polar coordinates? I am all
> > ears if you have something to share!   ;^)

> I thought about it a little more, and my thought is
> that because you are creating a fractal consisting
> of a significant number of circles any form of
> calculation like the one you are using or the one
> I was initially thinking is going to be terrible in
> performance.

AFAICT, it's almost impossible to disagree with that
statement Michael!

;^o



> If you instead follow my idea of directly plotting
> the circles on the pixel array itself, you could
> find the intersection points with no calculation at
> all:

> setOfIntersectPoints.concat(plotCircle(x,y,r));

> when you draw the circle on the pixel array, you
> can look at the color of the current pixel before
> you plot the point. So if the default color of the
> canvas is white, and circles are black when plotted,
> the intersection of the current circle and ALL of
> the relevant circles in the region would be where
> the pixel is already black.

There has to be a way to do this using the Bresenham
algorithm. I am worried about circles that go through
each other when the pixels go diagonal. Which means
the current circle would not pick up its intersection(s).

Perhaps the currently encoded circle could be a
different color. Therefore it could do a little search
for other circles, and disregard colors that match
itself.

Need to think.


Thanks Michael.

:^) 

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

#21904

> "Chris M. Thomasson"  wrote in message 
> news:l5bmic$g40$1@speranza.aioe.org...
> > "Michael Haufe (TNO)"  wrote in message news:34ae1ec8-f301-4a46-bdc1-> 
> > f2c2be3d7d4a@googlegroups.com...
> > On Monday, November 4, 2013 4:01:19 PM UTC-6, Chris M. Thomasson wrote:
[...]
> > If you instead follow my idea of directly plotting
> > the circles on the pixel array itself, you could
> >  find the intersection points with no calculation at
> > all:

[...]

> Perhaps the currently encoded circle could be a
> different color. Therefore it could do a little search
> for other circles, and disregard colors that match
> itself.

> Need to think.

Each color can be different. Therefore circles can keep a
little database to know what colors to search for.

Actually, This would allow for the fractal to be extended
in and of itself. You could create zones of intersections.
Almost like encoding the coloring of an escape-time
fractal within a database of orbit traps:

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



Btw, here is a link where I first presented my circle
intersection fractal:

https://groups.google.com/forum/#!topic/sci.fractals/CIUBUM51hPM/discussion


Here is where is was named Thomason's Turbulent Rings (TTR) by
Roger Bagula:

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



here is my personal collection of fractals:

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


You can find me on:

http://siggrapharts.ning.com

as well. The first image is mine. And the images 10-14 are mine as well.

I was very pleased to get some of stuff on there. Especially when, 10-14
are from my TTR fractal!

:^)


BTW, I am thinking about integrating TTR into DLA by planting a cluster
of seeds in the centers of the circles:

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

BTW, DLA is extremely similar to using color to detect circle intersections.

:^) 

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

#21959

On Tuesday, November 5, 2013 4:35:30 PM UTC-6, Chris M. Thomasson wrote:
>
> Each color can be different. Therefore circles can keep a
> little database to know what colors to search for.

Since at close proximity errors can occur as mentioned, (tangent and perfect diagonals), I think the next best approach would be to put all of your circles into a QuadTree where the insert operation would perform the intersection lookup inside of its region instead of performing (n - 1) comparisons

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

#21913

In comp.lang.javascript message <34ae1ec8-f301-4a46-bdc1-f2c2be3d7d4a@go
oglegroups.com>, Mon, 4 Nov 2013 18:40:13, "Michael Haufe (TNO)"
<tno@thenewobjective.com> posted:

>On Monday, November 4, 2013 4:01:19 PM UTC-6, Chris M. Thomasson wrote:
>>
>> Do you happen have something in mind that can find the true intersection(s)
>> of two circles that gets around any sqrt wrt polar coordinates? I am all
>> ears if you have something to share!   ;^)
>
>I thought about it a little more, and my thought is that because you
>are creating a fractal consisting of a significant number of circles
>any form of calculation like the one you are using or the one I was
>initially thinking is going to be terrible in performance.
>
>If you instead follow my idea of directly plotting the circles on the
>pixel array itself, you could find the intersection points with no
>calculation at all:
>
>setOfIntersectPoints.concat(plotCircle(x,y,r));
>
>when you draw the circle on the pixel array, you can look at the color
>of the current pixel before you plot the point. So if the default color
>of the canvas is white, and circles are black when plotted, the
>intersection of the current circle and ALL of the relevant circles in
>the region would be where the pixel is already black.


As I understand it, the desire is to show a fractal based on exact
circles positioned in the exact intersections of exact circles, which
would require infinite-length arithmetic.

The OP's code would replace exact arithmetic with IEEE Doubles
arithmetic, resolution about 1 in 7E15, which is likely to be good
enough.

Your idea rounds the points of intersection to be integers in pixel
units; and that may not be good enough.  Additionally, one must consider
the possible cases of tangency and of almost-parallel intersection,
where many pixels may "lie on" both lines.

I recall the esteemed Fred, Head of Workshop, consulting me about a cam-
shape calculation which was going astray.  He prudently had tested it
using a graph-plotter before using the nice new numerically-controlled
milling-machine, and I was able to perceive that his code had
substantially that problem, easily enough avoided once realised.

-- 
 (c) John Stockton, nr London, UK.   E-mail, see Home Page.    Turnpike v6.05.
 Website  <http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
 PAS EXE etc. : <http://www.merlyn.demon.co.uk/programs/> - see in 00index.htm
 Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.

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

#21921

> "Dr J R Stockton"  wrote in message news:>
> +SUJPfoYtpeSFw0C@invalid.uk.co.demon.merlyn.invalid...

> In comp.lang.javascript message <34ae1ec8-f301-4a46-bdc1-f2c2be3d7d4a@go
> oglegroups.com>, Mon, 4 Nov 2013 18:40:13, "Michael Haufe (TNO)"
> <tno@thenewobjective.com> posted:

> >On Monday, November 4, 2013 4:01:19 PM UTC-6, Chris M. Thomasson wrote:
> >>
> >> Do you happen have something in mind that can find the true 
> >> intersection(s)
> >> of two circles that gets around any sqrt wrt polar coordinates? I am 
> >> all
> >> ears if you have something to share!   ;^)

[...]

> >when you draw the circle on the pixel array, you can look at the color
> >of the current pixel before you plot the point. So if the default color
> >of the canvas is white, and circles are black when plotted, the
> >intersection of the current circle and ALL of the relevant circles in
> >the region would be where the pixel is already black.

> As I understand it, the desire is to show a fractal based on exact
> circles positioned in the exact intersections of exact circles, which
> would require infinite-length arithmetic.

> The OP's code would replace exact arithmetic with IEEE Doubles
> arithmetic, resolution about 1 in 7E15, which is likely to be good
> enough.

Yes, it is definitely good enough for the application at hand.

:^)



> Your idea rounds the points of intersection to be integers in pixel
> units; and that may not be good enough.

Its an interesting idea about finding intersections. I was thinking about
encoding the circles with unique colors and extending the fractal
based of of that information. The problem is, the "seed circles" might
be off the viewport plane when I zoom. I need to calculate that
information in order to get to the part that is within the viewport.

So, there comes a point where using pixel information to determine
intersections is more expensive than simply calculating them. In
other words, when you do not have to draw, calculate the intersections.

Humm...



> Additionally, one must consider
> the possible cases of tangency and of almost-parallel intersection,
> where many pixels may "lie on" both lines.

Exactly right. I was worried about two circles passing right through
each other when the pixels are diagonal. I was thinking about
encoding a unique color for each circle. Then this diagonal issue
can be solved by doing a little search around the 8 pixels
surrounding the current pixel.



> I recall the esteemed Fred, Head of Workshop, consulting me about a cam-
> shape calculation which was going astray.  He prudently had tested it
> using a graph-plotter before using the nice new numerically-controlled
> milling-machine, and I was able to perceive that his code had
> substantially that problem, easily enough avoided once realised.

There will be errors in the pixel probing solution proportionate to
rounding errors.

AFAICT, the error should actually be visually represented in the fractal
itself. Interesting to compare a rendering generated by the pixel
probe vs. one generated by the actual circle intersection calculation...

Fractals are _very_ sensitive to any errors...


;^)



Thanks. 

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

#21897

> "Michael Haufe (TNO)"  wrote in message news:935bd61f-b8bd-456a-8813->
> 3b00b2ebddb4@googlegroups.com...

> On Saturday, November 2, 2013 3:43:00 PM UTC-5, Chris M. Thomasson wrote:
> > The fractal is simple. Find circle intersections, draw circles at those
> > points,
> > then find all of the newly generated intersections, and repeat... You 
> > can
> > create some pretty nice fractals that way. Also, it seems as if circle
> > inter-
> > sections can be used for other applications as well...

> First off, I'm glad to see some more fractal applications
> being displayed.

Thank you.


> Being able to pass in the settings
> through url arguments would be a nice addition I think.

100% agreed!  :^)



> > I was wondering if my code is total crap or not. Please, any advise 
> > would be
> > extremely beneficial. I just hope it does not involve a complete 
> > rewrite.
> > Luckily, this software is in pre-alpha stages:

> The fact that you can produce significant results in a
> timely manner demonstrates that it wouldn't fall under
> "total crap" imo. One must be wary of letting the best
> be the enemy of the good.

> While I've yet to take much time looking at it yet, my
> first thought is to whether using polar coordinates instead
> of Cartesian would make things clearer or not. So thinking
> out loud here: A circle in cartesian "x^2 + y^2 = 1" becomes
> "r = 1" in polar. So while the representations are far
> simpler, the intersection can be a bit more difficult as
> there are infinite equivalent answers.

IMVHO, the algorithm as-is is fairly nice because it solves for the
intersection(s) of two circles using only a single sqrt operation.
So far, this is pretty good when compared to most of the other
solutions I have seen that rely on more than one sqrt and/or
trig functions.

Do you happen have something in mind that can find the true
intersection(s) of two circles that gets around any sqrt wrt polar
coordinates? I am all ears if you have something to share!   ;^)



> A requestAnimationFrame wrapper I prefer to use currently:

> window.requestAnimFrame = (function(){
>     return  window.requestAnimationFrame   ||
>         window.webkitRequestAnimationFrame ||
>         window.mozRequestAnimationFrame    ||
>         window.oRequestAnimationFrame      ||
>         window.msRequestAnimationFrame     ||
>         function(run){
>             window.setTimeout(run, 16);
>         };
> })();

> Also, I'm quite certain it will be a bit faster to render
> against the canvas image data instead of using the API.
> You'll have to roll your own circle drawing routine, but
> since this is a labor of love, I suspect you might not
> mind for the performance boost.

> clearRect(...) on the entire display can be slow. Do this instead:

> myCanvas.width = myCanvas.width

> More thoughts to come as time permits


Thank you for all of the suggestions Michael. I really do appreciate
the fact that you give a damn about fractals!

;^) 

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

#21909

"Chris M. Thomasson"  wrote in message 
news:l53o4o$5r5$1@speranza.aioe.org...

> The fractal is simple. Find circle intersections, draw circles at those 
> points,
> then find all of the newly generated intersections, and repeat... You can
> create some pretty nice fractals that way. Also, it seems as if circle 
> inter-sections can be used for other applications as well...

[...]

Here is a very crude animation of an aspect of the overall fractal
growth pattern:

http://webpages.charter.net/appcore/fractal/flash

Remember to close the damn page before the fractal grows to big
and freezes the damn thing. Luckily, it grows fairly slowly!

BTW, it uses Flash!!!

;^o Yikes!



Need to update this to HTML5 with a JavaScript backbone indeed!

:^) 

[toc] | [prev] | [standalone]

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

csiph-web