Welcome to Fract, my fractal generator. This blog will be about these little furry mathematical monsters called fractals. There will be also a tutorial, there already is a quick-start-guide and other stuff.
So, let’s start. Fract is written in Kotlin and Java, highly modularized, it uses Renderscript to speed up calculation and it contains a Virtual Machine that runs some byte code that is compiled from a programming language very similar to Kotlin. I call it – for obvious reasons – “fractlang”.
What are the advantages of doing this? Isn’t it much easier to simply hard code a fractal?
Well, Fract should be able to render all kinds of renderable images that as sole input use the current pixel coordinates: Mandelbrot Sets, Mandelbrot Sets with Orbit Traps, Newton Sets with Exponential Smoothing, Pendulum Simulations, Lyapunov Fractals… It should be able to allow you to enter custom functions, custom orbit traps, custom transfer functions. And I like parsing and compilers, so this is also a kind of a hobby.
And some of you might have seen a quite similar app, Fractview. This one was also written by me and I put all the experiences I had with Fractview into this new app.
So, what are the core differences between Fract and Fractview? Is Fract better?
- It’s complicated.
- Fractview has the disadvantage that the VM must also calculate the colors of the final image, or for 3D-effects it must calculate three values for one pixel.
- Fract simply focusses on calculating a (2-dimensional) value for the color and a height value. The 3D-effect afterwards and colorization is done in Renderscript.
- On the other hand, Fractview allows transparent orbit traps, which is pretty cool…
Okay, but is Fract better than Fractview?
I guess yes, because it is
- faster than Fractview
- color palette changes and 3d-effect changes are done instantly (which will allow color cycling and 3d animations)
- programs are much simpler
What about infinite zooming?
This is one of the most frequent questions. Fract is limited to double-precision or float-precision due to the underlying Renderscript framework. If you want to see a Mandelbrot Set with a 1e-40000-zoom, there are other apps. Implementing infinite zoom in Fract is “possible” but very time consuming, it would multiply start-up time, and I guess it simply is not worth the effort. I personally prefer changing transfer functions, orbit traps and functions. I plan some optimizations though so that some functions (exp, log, sqrt) use a higher precision.
If I rendered a nice picture, can I sell it and make millions?
I personally see Fract as an image processing tool. So, images that you render, they are yours. Share them, print them on pillows, use them to decorate your walls, put them on your album covers. I am very happy though if you mention the app and tell me about your success.
What about feature XY?
Suggestions are always welcome. I have a long list, some of them are implemented, some of them might not be possible, but I read every suggestion and I collect them.
I found a typo on this blog or in the app.
Only one :D? Please tell me. I will correct them. I am kind of lazy with proof-reading, so the better if you take over this job.
Shut up and take my money.
No. Fract is, like Fractview, open source and ad-free. Actually, it is hosted on Github. So, it is free as in free speech and free beer. But if you want to tip your waiter even after a free beer, you can make a small donation on Ko-Fi.
So long, thanks for your interest
— Karl
Fract 