Rolling fractals

[Tglad]

Effie, it is infinite... I'm not sure its fractal dimension, but it is certainly greater than 1, so any small section of the curve has infinite length.

Kram, yes its quite similar to this De Rham curve for example:


I'm guessing that De Rham curves are normal fractals and these rolling ones are possibly multifractal... the leaf one does seem to get smoother towards the tip for example.

[mclarekin]

@Tglad etc. Very Interesting post. Lots of possibilities

@Eiffie, Like the 3D video

[kram1032]

At the self-intersection:
I'm pretty confident it should be easy enough to find examples that do definitely self-intersect. (Just start off with parameters that already feature self-intersection in an early iteration while not compensating for the overlap in later iterations)
More interesting would be, for which parameters, e.g. scale-factors, phases and rotation-speed-functions, self-intersection would be avoided.

[tly]

hey guys

im new here, saw the thread some time ago and tried it myself this weekend.
you can get some pretty results by rotating through different roll speeds for every iteration.
for example the patttern (2,4,-5) would multiply the roll speed by 2, next iteration by 4, next iteration by -5 and then again by 2,4,-5 etc.
If you use fractional roll speeds like 3/2 the result can be very noisy and random. I noticed that some parts inside the fractals look like multibrots

heres my imgur album: http://imgur.com/a/FEQhh

and some special ones:
roll speed -2 and radius reduction 0.7 per iteration:



roll speed -3, radius reduction 0.6:



and a random one: roll speed -1.5, radius reduction 0.8



PS: how can i scale theses images ?

I can post the java app i made if you want to try some settings for yourself

[cKleinhuis]

hi there, nice, i am pretty sure we want to look into your little app

regarding image sizes, with "width" and "height" in the img tag you should be able to set desired sizes

[eiffie]

Great find! The images are very interesting and the app would be appreciated.

[tly]

thank you for your kind feedback  

this is the layout of the app:


I did the gui today, so it could be messy and buggy

Usage:

- click in the black part to start/stop the animation
- reset if you have visual bugs (i.e. after changing settings)
- click Render Image to create a good quality image (a window will pop up when its finished)

Settings:

- show circles/origins/radii: visual feedback in the animation where the circles are at the moment (can be distracting )
- skip steps: tells the program how many steps it should go before the next frame, the higher, the faster the animation.
   (lags if too high)
- add rotation: my old program (images above) had a bug, that the nth circles would roll n times as fast as the first one. that looked surprisingly good, so i kept it as an option.
so whats the big difference?
- looks different
- a pattern with an integer roll speed of n has normally a rotational symetry of order |n-1|. by adding the rorationangle every iteration you actually get a rotational symetry of order |n|

- circles: number of circles used
- renderRounds: a lot of patterns do not end up a the origin after one cycle of the 1st circle, so it could be necessary to render more than one cycle. renderRounds determines the number of cycles.
- radiusAmp: the ratio by which the radius is multiplied every iteration.
- precision: the angle in radians that is used every step to rotate the circles. the smaller the better
- roll speed: enter one or more values, for example -1,2,1.5 (values separated by a comma). i really dont know how to explain how it works see this example:

the patttern (2,4,-5) would multiply the roll speed by 2, next iteration by 4, next iteration by -5 and then again by 2,4,-5 etc.

Download link:
http://www56.zippyshare.com/v/66195277/file.html

[cKleinhuis]

sweetly visualised, the reset buttons seems to need another click to the image to get the rolling circles displayed, and the first line seems to be let go for the preview visualisation

[tly]

sweetly visualised, the reset buttons seems to need another click to the image to get the rolling circles displayed, and the first line seems to be let go for the preview visualisation

thanks, ill try to correct that

Edit: done
http://www56.zippyshare.com/v/66195277/file.html

You can now load and save settings, this code

Code:

0;0.00001;30;200;false;true;true;-7,-2,0.5;0.7;2;true;

is this fractal

[Tglad]

That's great, did you confirm that it gives the same results as the first few images on this thread?
I ask because the maths is a bit subtle, making sure the child circle is rolling relative to the parent ball's position _and_ orientation, not just relative to the parent's position.

Very cool snowflakes! I must try downloading the app.   

[tly]

thanks

i think i made the same "mistake" as Matthen

these settings create Matthens picture:

Code:

0;0.0001;30;200;false;true;true;-3;0.3333333;1;false;

But what exactly is the mathematical difference?

Does rolling instead of sliding mean that you have to add up the rotations of the circles?
If it does, the option "add rotation" should do what you want

[eiffie]

I remember making that mistake too because the math is a bit easier. Your app gives nice results all the same. This is frustrating to port to GLSL since finding the rotation that would wind up painting the pixel (x,y) is not straight forward.

[Tglad]

"Does rolling instead of sliding mean that you have to add up the rotations of the circles?"
I think so...
say each child circle is n times smaller than its parent (e.g. 2* smaller), then it rotates locally at angular velocity n times its parent, so first child would spin at n, the grandchild at speed n + n^2, the great grandchild at n + n^2 + n^3, etc.

[tly]

I remember making that mistake too because the math is a bit easier. Your app gives nice results all the same. This is frustrating to port to GLSL since finding the rotation that would wind up painting the pixel (x,y) is not straight forward.

i made a shader with the rolling circles
the problem i have is to draw the line...
http://glsl.heroku.com/e#14650.0

"Does rolling instead of sliding mean that you have to add up the rotations of the circles?"
I think so...
say each child circle is n times smaller than its parent (e.g. 2* smaller), then it rotates locally at angular velocity n times its parent, so first child would spin at n, the grandchild at speed n + n^2, the great grandchild at n + n^2 + n^3, etc.

thanks, ill try that

[eiffie]

Yes drawing the fractal bit is the tough part. You can always draw a series of dots and connect them but it won't be any faster than the Java version and less accurate.  I tried finding the angle which would get you closest to the pixel by narrowing in on it through successive approximation but there are lots of local minima that make the job tricky. The result always had little bits missing.