Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
An online circle intersection fractal...
153 views
Skip to first unread message
Chris M. Thomasson
Nov 2, 2013, 4:43:00 PM11/2/13
to
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!
;^)
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!
;^)
Michael Haufe (TNO)
Nov 3, 2013, 8:55:29 PM11/3/13
to
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>
>
> Also, here is an older CSS3 fractal animation I made a while back:
>
> https://groups.google.com/forum/#!topic/alt.html/CKTlED4wTfo
Michael Haufe (TNO)
Nov 3, 2013, 9:55:59 PM11/3/13
to
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.
> 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:
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
Chris M. Thomasson
Nov 4, 2013, 5:01:19 PM11/4/13
to
> "Michael Haufe (TNO)" wrote in message news:935bd61f-b8bd-456a-8813->
> 3b00b2...@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!
;^)
> 3b00b2...@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.
> 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.
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
fact that you give a damn about fractals!
;^)
Chris M. Thomasson
Nov 4, 2013, 5:03:04 PM11/4/13
to
> "Michael Haufe (TNO)" wrote in message news:935bd61f-b8bd-456a-8813->
> 3b00b2...@googlegroups.com...
> 3b00b2...@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.
> > 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.
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
So far, this is pretty good when compared to most of the other
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! ;^)
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
> 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
Michael Haufe (TNO)
Nov 4, 2013, 9:40:13 PM11/4/13
to
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.
>
> 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! ;^)
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.
Michael Haufe (TNO)
Nov 4, 2013, 9:42:46 PM11/4/13
to
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
> 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
Chris M. Thomasson
Nov 5, 2013, 4:05:17 PM11/5/13
to
> "Michael Haufe (TNO)" wrote in message news:34ae1ec8-f301-4a46-bdc1->
> f2c2be...@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.
:^)
> f2c2be...@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.
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.
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.
:^)
Chris M. Thomasson
Nov 5, 2013, 5:35:30 PM11/5/13
to
> "Chris M. Thomasson" wrote in message
> news:l5bmic$g40$1...@speranza.aioe.org...
> 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.
:^)
> news:l5bmic$g40$1...@speranza.aioe.org...
> > "Michael Haufe (TNO)" wrote in message news:34ae1ec8-f301-4a46-bdc1->
> > f2c2be...@googlegroups.com...
> > On Monday, November 4, 2013 4:01:19 PM UTC-6, Chris M. Thomasson wrote:
[...]
> > f2c2be...@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:
[...]
> > 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.
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.
:^)
Chris M. Thomasson
Nov 6, 2013, 1:19:33 AM11/6/13
to
"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
[...]
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!
:^)
Dr J R Stockton
Nov 6, 2013, 2:41:12 PM11/6/13
to
In comp.lang.javascript message <34ae1ec8-f301-4a46-bdc1-f2c2be3d7d4a@go
oglegroups.com>, Mon, 4 Nov 2013 18:40:13, "Michael Haufe (TNO)"
<t...@thenewobjective.com> posted:
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.
oglegroups.com>, Mon, 4 Nov 2013 18:40:13, "Michael Haufe (TNO)"
<t...@thenewobjective.com> posted:
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.
Chris M. Thomasson
Nov 7, 2013, 3:46:02 PM11/7/13
to
> "Dr J R Stockton" wrote in message news:>
> +SUJPfoY...@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)"
> <t...@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.
> +SUJPfoY...@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)"
> <t...@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.
:^)
> Your idea rounds the points of intersection to be integers in pixel
> units; and that may not be good enough.
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.
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.
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.
Michael Haufe (TNO)
Nov 11, 2013, 2:48:26 AM11/11/13
to
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
>
> Each color can be different. Therefore circles can keep a
> little database to know what colors to search for.
0 new messages