A few replies:
-Colours, obviously! Assign different colours according to the number of iterations it takes until a point escapes (I'll shorten this to NIPE for now
For a start you could copy the functionality of BuddhabrotCL (If you need help/input, I'll happily provide, just write me a pm or ask specific questions.
Even better Colours? If possible don't only use 3 colours but make use of palettes, spreaded over all NIPE? (though I don't know if this actually will look good.)
-To get some really outstanding pictures we need the possibility to only display certain areas of NIPE. I got the most astounding images filtering out the low values and for example just show NIPE 250.000 to 500.000.
In my understanding, you have to calculate all the NIPEs below anyway, so why not add a "lower limit"-fader, that allows to filter out the low iteration points in real-time, while not throwing them away.
I will soon upload an update, which has simple color support, assigning different Zs to different RGB channels depending on current iteration.
I could try to use a palette based on orbit length, however you will probably be able to see banding or get a loss of dynamic range, since I encode colors as integers (see:
https://en.wikipedia.org/wiki/Colour_banding)
Also I could add a "low limit" setting, however it will have to clear the image and restart the rendering, since there is no way of remembering which pixel were drawn at which iteration.
(Also you are talking about very high orbit lengths here, at least for realtime rendering. The current version uses a maximum of 5.000 iterations.)
-of course: image export! and in unlimited resolution of course
At least 15360*8640
-Long term: store all data that has been calculated once, so when zooming to a place you've been before your calculation will only add up. over time this will lead to the most detailed buddhaset-picture ever. next level: upload and combine the data of all users to make this a community project. I'd definitely host that on my server!
Well, first of all a single image of that resolution would take up more than 2 GiB of memory and the rendering would still take hours, probably even longer if you were to render in tiles.
This is also not my first priority for this project, since it is meant as a realtime zoomer, not an offline renderer. (Buddhabrot Max is meant for stuff like that, though I admit it currently does not perform well when rendering a zoomed part of the Buddhabrot).
Also storing all orbits would cost multiple GiB in a few seconds, so that won't ever be possible. (Unless we get really big and fast SSDs).
-->combine mag and max! why keeping these seperate? (probably some programming issues I have never heard of.., excuse my ignorance
)
I started Mag as a new project because I did not know if it would actually work, and because it is often easier to work on a small project than on a big one.
Also, I might merge some of their functionality and settings (like all the extra formulas and settings that are available in Max), but they will remain separate projects a one of the is focused on high resolution rendering and the other on realtime zooming and therefore they work differently internally.
-I would love to explore how a full view of the buddhaset would look like if you take only the starting values of a deeply zoomed section of the mset, like a julia-set deep in the seahorse value.
so the possibility to limit the input-starting-point values to a small section of the mset. (if possibleby using copy-paste coordinates from kalles fraktaler)
I've attached an image how it would look if you zoomed in to {-0.8, -0.19} x {-0.67, -0.12}, but zoomed out. (It looks the same, except some parts are brighter than usual.)
ps, yes I know it's called buddhabrot. but that name sounds so stupid in german, translates to buttered bread...
- heyyour name from the contact.txt sounds like you know this already.. fellow german?
Yes, I am German.
how the hell are you doing this?!?
deep zooms like this should technically be impossible!
How did you solve that?!!
The current implementation works like this:
I've got a list of the "best" orbits. On program start this list is filled with random numbers. (The length of this list can be chosen when starting the program, so the default setting "9" would be 2^9 = 512).
Every orbit in that list is "mutated" 64 times, all these orbits are drawn and assigned a score depending on how much they affect the current image.
So now we've got a list that is 64*512 = 32.768 values long.
Then the orbits with the lowest scores are discarded, so the list only contains the "best" orbits again and it's length is back to 512.
This process is repeated infinitely.
edit: i notice it becomes pixely/lines when going deeper than e05. stil this is a thousand times deeper than I've been before with buddhabrotcl (that uses gpu as well)... unbelievable!
As quaz0r points out, this is indeed the limit of single floats. However, I will update to support double precision (which is slower by a factor of 32x on many GPUs, sadly).