Meta-Mandelbrot [Mandeljulia?]

[Softology]

Here is a sample Meta-Mandelbrot movie at 4K resolution.  First part is 1000 frames changing the real part of C from 0 to -0.2.  Then 3 zooms (-01,0.0) (-0.14,0.0) and (-0.2,0.0).  Uses CPM smooth shading.

<a href="https://www.youtube.com/v/8Hci_vNr6sI&rel=1&fs=1&hd=1" target="_blank">https://www.youtube.com/v/8Hci_vNr6sI&rel=1&fs=1&hd=1</a>

Here is the full shader code if anyone wants to take a look.

Code:

#version 400

uniform vec2 resolution;
uniform vec3 palette[256];
uniform double xmin;
uniform double xmax;
uniform double ymin;
uniform double ymax;
uniform double bailout;
uniform int maxiters;
uniform int samplepixels;

double sqrsamplepixels=double(samplepixels*samplepixels);
double bailout_squared=double(bailout*bailout);
double magnitude,r1,r2,g1,g2,b1,b2,tweenval,x,y;
double realiters;
vec4 finalcol,col;
int superx,supery;
double stepx=(xmax-xmin)/resolution.x/double(samplepixels);
double stepy=(ymax-ymin)/resolution.y/double(samplepixels);
int colval,colval2;
dvec2 z,c,lastz,lastz2,s1,s2,n,d,a,d2,temp,temp2,temp3;

dvec2 cmul( dvec2 a, dvec2 b )  { return dvec2( a.x*b.x - a.y*b.y, a.x*b.y + a.y*b.x ); }
dvec2 csqr( dvec2 a ) { return dvec2(a.x*a.x-a.y*a.y, 2.0*a.x*a.y ); }

void main(void)
{
	finalcol=vec4(0,0,0,0);

	//C is constant
	c.x = -0.1;
	c.y = 0.0;

	for (supery=0;supery<samplepixels;supery++)
	{
		for (superx=0;superx<samplepixels;superx++)
		{
			//z from current pixel
			z.x = xmin+gl_FragCoord.x/resolution.x*(xmax-xmin)+(stepx*double(superx));
			z.y = ymin+gl_FragCoord.y/resolution.y*(ymax-ymin)+(stepy*double(supery));
			int i;

			for(i=0; i<maxiters; i++) 
			{
				// http://www.fractalforums.com/images-showcase-(rate-my-fractal)/meta-mandelbrot-(mandeljulia)/?PHPSESSID=b5fd43c3acfd4c3472a92524915f0100
				dvec2 ztmp=cmul((cmul((csqr((csqr(z)+c))+(csqr(c)+z)),(csqr((csqr(z)+c))+(csqr(c)+z)))+(csqr((csqr(c)+z))+(csqr(z)+c))),(cmul((csqr((csqr(z)+c))+(csqr(c)+z)),(csqr((csqr(z)+c))+(csqr(c)+z)))+(csqr((csqr(c)+z))+(csqr(z)+c))))+(cmul((csqr((csqr(c)+z))+(csqr(z)+c)),(csqr((csqr(c)+z))+(csqr(z)+c)))+(csqr((csqr(z)+c))+(csqr(c)+z)));

				magnitude=(ztmp.x*ztmp.x+ztmp.y*ztmp.y);
				if (magnitude>bailout_squared) break;
				z=ztmp;
			}

			if (i==maxiters) {
				col=vec4(0.0,0.0,0.0,1.0);
			} else {
				//CPM smooth colors
				//note that double precision does not support log so it needs to be cast as float
				realiters=float(i+1-((log(log(sqrt(float(magnitude))))/log(16)))); //normally log is the power factor, needs to be raised here to smooth colors
				colval=int(mod(realiters,255));
				colval2=int(mod(colval+1,255));
				tweenval=realiters-int(realiters);
				r1=palette[colval].r;
				g1=palette[colval].g;
				b1=palette[colval].b;
				r2=palette[colval2].r;
				g2=palette[colval2].g;
				b2=palette[colval2].b;
				col=vec4(r1+((r2-r1)*tweenval),g1+((g2-g1)*tweenval),b1+((b2-b1)*tweenval),1.0);
			}

			finalcol+=col;
		}
	}
	gl_FragColor = vec4(finalcol/double(sqrsamplepixels));
}
	

These formulas and scripts are now included with Visions of Chaos http://softology.com.au/voc.htm.

[gds-entropy]

Here is a sample Meta-Mandelbrot movie at 4K resolution.  First part is 1000 frames changing the real part of C from 0 to -0.2.  Then 3 zooms (-01,0.0) (-0.14,0.0) and (-0.2,0.0).  Uses CPM smooth shading.

I will be including these formulas and scripts with the next released version of Visions of Chaos http://softology.com.au/voc.htm.

Very cool! 

The settings I used in Fractal Explorer to get good internal coloring I are "N-set method" and "Log counting |Z|"; I am not sure what that really translates to in code due to not having the source for FE, but those two settings are what enables the full internal coloring method.

Ian

[gds-entropy]

However I can only assume that that's nothing higher iteration levels couldn't fix. But as is, I'm running out of memory if I try that.

How much memory does it currently use? I have machines with 24, 32 and 64gb of ram, so if you are hitting a wall below those I might be able to lend a hand if you wish.

Ian

[claude]

...
Here is the full shader code if anyone wants to take a look.

Code:

...
dvec2 ztmp=cmul((cmul((csqr((csqr(z)+c))+(csqr(c)+z)),(csqr((csqr(z)+c))+(csqr(c)+z)))+(csqr((csqr(c)+z))+(csqr(z)+c))),(cmul((csqr((csqr(z)+c))+(csqr(c)+z)),(csqr((csqr(z)+c))+(csqr(c)+z)))+(csqr((csqr(c)+z))+(csqr(z)+c))))+(cmul((csqr((csqr(c)+z))+(csqr(z)+c)),(csqr((csqr(c)+z))+(csqr(z)+c)))+(csqr((csqr(z)+c))+(csqr(c)+z)));
...

That's frightening, and I don't know why there are cmul() in there, as far as I can tell csqr() is all that is needed.  Maybe a use case for the pre-processor (or ideally recursive functions, but GLSL doesn't support that):

Code:

#define LEVEL0(a,b) (a)
#define LEVEL1(a,b) csqr(LEVEL0(a,b))+LEVEL0(b,a)
#define LEVEL2(a,b) csqr(LEVEL1(a,b))+LEVEL1(b,a)
#define LEVEL3(a,b) csqr(LEVEL2(a,b))+LEVEL2(b,a)
#define LEVEL4(a,b) csqr(LEVEL3(a,b))+LEVEL3(b,a)
dvec2 ztmp = LEVEL4(z,c);

[3dickulus]

c.x=-0.2 c.y=0.0

     z = csqr( csqr(z)+c ) + csqr(c)+z;

[claude]

Fragmentarium version with distance estimation colouring via complex dual numbers for automatic differentiation, c = -0.125 + 0.25 i, zoomed in somewhat.  Uses the #define trick from my previous post.

[kram1032]

gds-entropy it really depends on both how deep you go into the tree and what resolution you build your images with. It should also be noted that, when I was trying 4K, I was running Chrome in the background, which is quite a Memory-hog. I think if I shut down everything else I should be able to get to something around 5K, 15 iteration depth.
If you have the time for it, I'd love to see a deeper iteration depth and/or higher resolution.
It's currently not multi-threaded (beyond what ever Python may or may not already do under the hood which, I think, is nothing?) so multiple cores won't help. But as is, on the laptop I ran it on, it takes about 80s to update the image once at iteration depth 15, and times should roughly double with the depth (so if you tried iteration depth 20 it'll probably take like 45min to even just update the image once), and you'll need quite a lot of updates to get a nicely filled-in pic.
Things could probably rearranged to take advantage of threading - both to sample multiple points at the same time and to, perhaps, save an image independently in an extra thread. But I have never done any multithreading and find the provided packages a bit confusing.

I have since somewhat updated the code (it has basic navigation features: you can, in principle, zoom into an arbitrary point and specify non-square dimensions, but there is no runtime control over what area to sample - it'd be easy enough to change by hand in the script though, since it's pretty short right now) So you can try that if you want.

I think it might also be possible to use heuristics to terminate a particular sample early if it doesn't appear to add much to the area of interest, but I'm not quite sure yet what those heuristics would have to be. If I (or somebody else) found good ones for this, I expect it to be much faster. Something like "if none of the points up to iteration depth 5 (or something almost-instant like that) land in a specified area (say the bounding box of the actual Mbrot-ish-shaped region in the center or, in a zoom, the zoom boundaries), don't evaluate any further".

[gds-entropy]

gds-entropy it really depends on both how deep you go into the tree and what resolution you build your images with. It should also be noted that, when I was trying 4K, I was running Chrome in the background, which is quite a Memory-hog. I think if I shut down everything else I should be able to get to something around 5K, 15 iteration depth.
If you have the time for it, I'd love to see a deeper iteration depth and/or higher resolution.
It's currently not multi-threaded (beyond what ever Python may or may not already do under the hood which, I think, is nothing?) so multiple cores won't help. But as is, on the laptop I ran it on, it takes about 80s to update the image once at iteration depth 15, and times should roughly double with the depth (so if you tried iteration depth 20 it'll probably take like 45min to even just update the image once), and you'll need quite a lot of updates to get a nicely filled-in pic.
Things could probably rearranged to take advantage of threading - both to sample multiple points at the same time and to, perhaps, save an image independently in an extra thread. But I have never done any multithreading and find the provided packages a bit confusing.

I have since somewhat updated the code (it has basic navigation features: you can, in principle, zoom into an arbitrary point and specify non-square dimensions, but there is no runtime control over what area to sample - it'd be easy enough to change by hand in the script though, since it's pretty short right now) So you can try that if you want.

I think it might also be possible to use heuristics to terminate a particular sample early if it doesn't appear to add much to the area of interest, but I'm not quite sure yet what those heuristics would have to be. If I (or somebody else) found good ones for this, I expect it to be much faster. Something like "if none of the points up to iteration depth 5 (or something almost-instant like that) land in a specified area (say the bounding box of the actual Mbrot-ish-shaped region in the center or, in a zoom, the zoom boundaries), don't evaluate any further".

I presently have a 65536 iteration 8192x8192 image rendering for R -0.141 I 0.0 in Fractal Explorer, hosted in Virtual PC and XP Mode on a win7 box, so we will see what that gives us for now.

In a different set, I also tried modifying the base formula as such, where all base instances are replaced with:
(z^P1) + ((z^P3) + c)
and
(c^P2) + ((c^P4) + z)

giving:

Code:

(((((z^P1)+(z^P3+c))*((z^P1)+(z^P3+c))+((c^P2)+(c^P4+z)))*(((z^P1)+(z^P3+c))*((z^P1)+(z^P3+c))+((c^P2)+(c^P4+z)))+(((c^P2)+(c^P4+z))*((c^P2)+(c^P4+z))+((z^P1)+(z^P3+c))))*((((z^P1)+(z^P3+c))*((z^P1)+(z^P3+c))+((c^P2)+(c^P4+z)))*(((z^P1)+(z^P3+c))*((z^P1)+(z^P3+c))+((c^P2)+(c^P4+z)))+(((c^P2)+(c^P4+z))*((c^P2)+(c^P4+z))+((z^P1)+(z^P3+c))))+((((c^P2)+(c^P4+z))*((c^P2)+(c^P4+z))+((z^P1)+(z^P3+c)))*(((c^P2)+(c^P4+z))*((c^P2)+(c^P4+z))+((z^P1)+(z^P3+c)))+(((z^P1)+(z^P3+c))*((z^P1)+(z^P3+c))+((c^P2)+(c^P4+z))))) 

This successfully merges the behavior with another fractal I have on Flickr, and produces interesting behavior for 50, 2, 50, 2, and other values, such as making one of the 50s negative. This modification also displays an interesting bilongitudinal asymmetry of coloration, while retaining the symmetry of shape with only minor distortion due to the negative real I use with this formula. Once I render those in a larger version I'll post them as well, with the *.frs files and formulae for them.

One interesting effect is that the center shape becomes surrounded with a perfect circle of smaller, differently shaped sets which are oriented in curious ways.

I will reply to this and attach the initial experiment images, which will be rendered much larger later...I'm having some issues getting the forum software to accept them presently.

EDIT:

Here are the Fractal Explorer *.frs files for the second formula I mentioned, which is different than the original Level 3 version in 7z format.
Regrettably the board does not allow file size sufficient to include the preview images, nor, oddly, does it allow files in 7z format, so I had to rename it to be *.rar.

The file is not rar, it is 7z.

I did not see rar as a compression option in 7z and didn't feel like looking for it, but 7z can extract this without being renamed, but if you are using another archive manager this may not be the case.

Ian

[gds-entropy]

Images referenced above..

[kram1032]

65536 iteration

of my Python-code? - At that kind of iteration-depth I doubt it'll work out... Or did you modify something?
I mean my laptop isn't the fastest or anything, but I doubt your CPU will be so many times faster that that kind of iteration-count becomes feasible, even remotely. It'll just never produce any image. We're talking about 2⁶⁵⁵³⁷-1 points to evaluate here. For a single update.

The iteration-depth is more time-limited (although there also is a memory-component to it). The bigger memory-hog probably is the image-resolution. - It keeps three entire res²-images in memory at all times (basically constant memory usage at that point), and then briefly peaks as it calculates the equalized image and saves it as png. That's where most of the memory limitation happens.
As said, on my laptop, 15 iterations take 80s per update. 16 iterations should take about 160s. If you went to 65536, I'm pretty sure we're talking about longer-than-the-heat-death-of-the-universe

[gds-entropy]

of my Python-code? - At that kind of iteration-depth I doubt it'll work out... Or did you modify something?
I mean my laptop isn't the fastest or anything, but I doubt your CPU will be so many times faster that that kind of iteration-count becomes feasible, even remotely. It'll just never produce any image. We're talking about 2⁶⁵⁵³⁷-1 points to evaluate here. For a single update.

The iteration-depth is more time-limited (although there also is a memory-component to it). The bigger memory-hog probably is the image-resolution. - It keeps three entire res²-images in memory at all times (basically constant memory usage at that point), and then briefly peaks as it calculates the equalized image and saves it as png. That's where most of the memory limitation happens.
As said, on my laptop, 15 iterations take 80s per update. 16 iterations should take about 160s. If you went to 65536, I'm pretty sure we're talking about longer-than-the-heat-death-of-the-universe

My apologies for not being clear; the 65536 iteration image I am rendering at the moment is of the base level 3 formula, which looks like it may take the better part of a week. I'm pretty patient, and will wait months for calculations to complete if needed, which has happened with some very deep PDE simulations. I suppose this patience comes from running raytracers on double digit MHz processors in the early 90's, though I still seem to produce scenes that render at 1 pixel per minute sometimes.  I think that the time to render any random scene is nearly constant regardless of technological improvements, due to new, more power hungry features being added to the engine...but I digress...

I intend to examine the python code for possible translation to a different language, where I can handle parallelism more comfortably, as python isn't really my bag; I'm a C#/Java/C++ guy. If that proves too unwieldy, I will simply run the code outright on a machine which I will allocate entirely to the task, and then just let it render for a few weeks. I have a xeon hexacore which would be perfect for it if parallelism proves trivial in a different language, otherwise I'll just run it on a box with large RAM capacity.

I will probably make a rudimentary first pass translation to C#, then run the profiling tools in VS2015 Enterprise on it to see where I can best leverage parallelism. I'm also working on building an adaptive CUDA laplacian/kernel based sampling library at the moment too, so as I become more comfortable with CUDA I might find I can leverage that too; we will see, as I just started learning CUDA a few days ago, but I am a quick study. So far, of the GPU languages, CUDA is the least offensive to me, and I have a pretty good box with a few SLI connected cards obtained specifically for running CUDA accelerated simulation code...so we will see where this leads me.

Do not expect a rapid turn-around though, as I have a fair number of personal projects going on right now on top of a full-time software architecture/etc.. job, which obviously takes priority, but I will put a good amount of effort into this, likely when I am suffering from insomnia at its worst, which is when I tend to get most interesting things accomplished.

I was blessed/cursed with one of those jerk brains that takes stuff I'm into, processes it in the background, then refuses to let me sleep until I have implemented whatever thing it comes up with, which of course it just loves bringing to my attention right smack in the middle of the blasted night. It is a pretty good troll. The jerk. 

Ian

[3dickulus]

@gds-entropy http://www.fractalforums.com/programming/omp-vs-par4all/msg77348/#msg77348 

[kram1032]

gds-entropy ok that makes more sense 

[gds-entropy]

@gds-entropy http://www.fractalforums.com/programming/omp-vs-par4all/msg77348/#msg77348 

Ok I will check that p4all out as well. OpenACC was another which someone on the NVIDIA forums mentioned to me as being fairly user friendly, with Thrust being lower level and with greater optimization potential.

Right now my design goal is a minimum of fuss, with greatest performance boost through offload to GPU, and not micro optimization or those requiring substantial algorithmic alterations; best bang for the buck one might say.

The primary use case is production of a foss c++ library for interop as extern with C#, either through use of ManagedCuda or direct use of the 8.0 tooling sans MC, but NVIDIA lies about vs2015 support I have discovered, as while the IDE is supported, the vs160 cpp compiler toolset is NOT and thus compatibility with .net 4.6+ fails, and setting the CUDA project to use the 2013 compiler ALSO does not seem to work. Im not very happy about ANY of that. It looks like I have to install 2013 ultimate on another box, as that is the most recent cpp toolset they support.

Their website is intentionally deceptive about this though, and you only find this out when the <<>> for globals fails and you hit SO and dive into the nvidia analogue of MSDN, which the MS version of itself has decayed in quality of late.

I am only including this information for others who may encounter this issue with regards to the Meta effort, and if folks need the info I will add links to StackOverflow and the relevant setup and config pages for the tooling stack I mentioned, otherwise I will not mention CUDA and related items further here, to prevent deviation from the overarching topic.

Ian

[gds-entropy]

UPDATE: I was informed my server was not properly serving 7z files, and I have modified the web.comfig to add that mimetype, so it will work for you now if you browse the directly.

The archive is in 7z format, not rar; I had to do this to permit the posting of the archive.

You may or may not need to alter the file extension, archive manager dependent.

Here are the *.frs files for the original Meta, levels 2 and 3, with some palette variations, inverse and obverse variants for level 3 are likewise included.

Here is a version of the archive with preview images:
http://gds-entropy.com/filedrop/fractals/01-13-2017%20Meta%20Levels%202%20and%203.7z

Below are links to the output of some of them, for reference.

Folder location: Level 32017-01-13_0 Obverse JuliaAlternates:
https://www.flickr.com/photos/gds-entropy/31769659574/in/dateposted-public/ File: 2017-01-19_r[-0_1]i[0]_1Dot
https://www.flickr.com/photos/gds-entropy/31665738024/in/dateposted-public/ File: 2017-01-19_r[-0_1]i[0]_0
https://www.flickr.com/photos/gds-entropy/32336993282/in/dateposted-public/ File: 2017-01-19_r[-0_1]i[0]_1
https://www.flickr.com/photos/gds-entropy/32309431531/in/dateposted-public/ File: 2017-01-19_r[-0_3]i[0]_0
https://www.flickr.com/photos/gds-entropy/32052371270/in/dateposted-public/ File: 2017-01-19_r[-0_2]i[0]_0
https://www.flickr.com/photos/gds-entropy/32430271875/in/dateposted-public/ File: 2017-01-19_r[0_2]i[0]_0
https://www.flickr.com/photos/gds-entropy/32309428241/in/dateposted-public/ File: 2017-01-19_r[0_1]i[0]_0

Folder location: Level 2:
https://www.flickr.com/photos/gds-entropy/31674508593/in/dateposted-public/ File: 2017-01-13_5
https://www.flickr.com/photos/gds-entropy/32279143522/in/dateposted-public/ File: 2017-01-13_4
https://www.flickr.com/photos/gds-entropy/31601052373/in/dateposted-public/ File: 2017-01-13_3
https://www.flickr.com/photos/gds-entropy/32401167115/in/dateposted-public/ File: 2017-01-13_1
https://www.flickr.com/photos/gds-entropy/32243302432/in/dateposted-public/ File: 2017-01-13_6

Ian