I figured out a decent way to capture the attractor basins without having to know a) what type of basin it is (attractive, parabolic, sigel) and b) without having to change/write custom trap code for each of these.
Any chance of letting us know the algorithm ?
Any chance it opens the door to calculating a distance estimate for the inside more efficiently ?
Well yeah as long as nobody makes fun of me for it's simplicity.
First a little background - like most everyone else here my interest was captured way back when all this was new and hard a shit to render even in 2d due to CPU slowness and a lack of sophisticated graphics. When I saw the pics in SoF I became totally entranced with trying to reproduce the color plates that showed the basins of attraction of these. My thinking was okay I understand that the mset and it's julias are basically just crumpled/deformed circles - but what the hell was going on inside them to distort them into these things???
Not being a mathelete or math geek by any means I could never understand how to engineer code that could classify what type(s) of attractors were at work and certainly could not write any of the more exotic orbit traps (parabolic, siegel, herman ring cases, etc.) So I was stuck and kept hacking at it off and on over the years.
At one point I tried to do something different to capture images of Siegel disks based on the description of the orbits and actually rendering the orbits of single points from a julia containing Siegel disks. So i tried just calculating the distance traveled by a given point during it's orbit - and it worked I got an image that looked almost exactly like the ones in BoF/SoF - Success at last!
By mistake I had left this non-trapping orbit trap code in placed, changed the julia to one with a parabolic basin of attraction and well wadda ya know it too rendered up looking extremely similar to (what I've always assumed) were level-set decompositions of the julia set interiors. And as I've said in other postings, this translates and works perfectly well with the 3D mandel bulb and 4D Quanternion/Hyper complex sets as well.
The basic premise is that one iterates all points in the formula to a fixed number of iterations (in the case of my recent 3d work, 50 iterations is fine) unless of course the point escapes - which in that case it's thrown out. During the iteration I keep a running accumulation of the distance between Zn and Z (as a double or float) and that's the number that I use as my "level set" value in the renderings.
That's really about it, there's a couple of variations on a theme that work better for one formula/julia than another, but they all essentially revolve around the idea of capturing the distance traveled during the orbit. I would like to take this further by learning more about the 'real' maths that are supposed to be used and now that I finally found this forum that might just happen!!
Now the caveats are that of course it's not really a level set decomposition, if you're dealing with a formula that can generate multiple types of basins in one image (Volterra-Lotka/Normalized-Q plane come to mind) then it can't tell the difference between them and of course it's not as "pure", but hey screw purity, I want pictures damnit!
And now the moment you've all been waiting for...
dist += Maths.Dist(Z,Zn)Where Maths.Dist is a bog-standard distance between two points calculation.
So here's a 2nd order mandelbulb julia with just it's outermost (noisy) surface stripped off...using the data from the above highly complex piece of code
Sorry about the noise and artifacts in the render I'm limited to 512x512x512 data cubes and the volume renderer is made for rendering CT/MRI data not point clouds of mathematical goodness!
JC