16 different spherical coordinate systems

[John Creighto]

You may be surprised here - I certainly was. A few new renders by a very slightly modifed version of the formula (higher powers) produces extremely interesting results. Although it's not the 'holy grail', it's much closer than before. We're seeing tiny buds 'growing' on buds growing on bigger buds, with less of the 'taffy' look you speak of.

This one is of the whole thing:
http://www.bugman123.com/Hypercomplex/Mandelbrot-White8-large.jpg

This is a zoomed in version (*22 magnification, but the 'voxel' resolution is fairly low), lighting is plain here:
http://www.fractalforums.com/gallery/0/141_03_09_09_9_25_55.png

This shows more of the potential, despite the plain diffuse lighting again. magnification= *1284. Notice the romanesco broccoli type effect!
http://www.fractalforums.com/gallery/0/141_04_09_09_12_01_24.png

Maybe Phrak was right after all with his 98% guess. More renders from the fractalforum guys are forthcoming over the next days (can't wait :) ). This is a first afaik.

Those are beautiful!

 

[Twinbee]

To be clear that we're on the same page, for the 2D mandelbrot angle are reference to the X-axis with the positive direction toward the positive Y-axis. For a vector making an angle from the Z-axis into the XY-plane there is no information to tell us if it's a positive or negative angle--there's no distinction between 30 degrees and -30 degrees, for instance. Because you're handing the atan2 a positive radius each time, it will only return values for the angle in two out of 4 quadrants.

I think I see what you mean. You're saying that the 2D version doesn't suffer from this prob, but that the 3D version does because of the atan2/sqr bit in step (3) of your earlier post. Correct me if I'm wrong, but I'm guessing this problem is related with how a point on a sphere (using the standard spherical coord system), can be represented with two or more coord sets - creating ambiguity for when it comes to 'doubling the angle'.

But there may be a way around this. The orbits for your 3D mandelbrot trace a pattern on the surface of a sphere (I think), and the sphere will be shrinking or expanding, as you've pointed out. From previous points of the orbit, you may be able to obtain 'angular momentum' information that will tell you in which octant on the sphere the next iteration should appear.

That seems interesting, but when each orbit starts out for their first time, there won't be any previous info to go by, and therefore some points' rotation may be ambiguous still. If I understand you correctly.

Is that one of your algorithms, Twinbee? I'd like to see the algorithm if it's available.

Yep it's exactly the same formula as before, except with a higher power instead of power 2. For similar results, you can experiment multiplying the yang/zang variables from that code by say 5+ and put the radius (.r) to powers of 5+ too. Mathematically, I should be able to get identical results with the former direct exponentiation approach, but I can't unify them yet for some reason.

See the pictures showing powers 3-8 from Paul/bugman's site. It also gives the formula directly.
http://www.bugman123.com/Hypercomplex/index.html

Also see David's ace new animation that morphs between the powers 3-10:
http://makinmagic.deviantart.com/art/The-Broccoli-Virus-136033852

Finally, here's a taster of what's to come (with some added shading, but still no where near properly shadowed / globally illuminated / raytraced). Magnification=1284:

http://www.skytopia.com/stuff/broc.png

 

[Phrak]

After looking at some orbits of the Mandelbrot set using Fractint 20.0, I don't see the nicely behaved orbits I expected. Secondly, I don't think there is any meaningful way to decide which way an orbit should be moving on the next step, or even it's initial direction as you've said.

So giving-up on that momentarily, I re-examined the coordinate relationship y:x::y:z and came up with this code.

r2 = x*x + y*y + z*z

theta = 2.0 * atan2(y,x)
phi = 2.0 * atan2(z,y)

x = r2 * cos(theta) + a

p = r2 * sin(theta)

y = p * cos(phi) + b
z = p * sin(phi) + c

This corresponds to one of your coordinate systems. Either B or G.
I haven't tried to see if the Fractint will accept this sort of algorith.

 

[Twinbee]

Hi Phrak, I tested, and the coord system you made is a rotation of the standard 'I' system. I rendered the function anyway. Here's the result:

http://www.skytopia.com/project/fractal/new/3dmand-phrak.jpg

Interesting about the cranky orbit - I might've guessed. The more I think about it, the more I like your idea to keep trace of the previous/first rotation to see how the next will act. Like you, I hope your fears about it still being ambiguous turn out to be mistaken.

Have a look at this shot - it's even more exciting, despite the plain light sourcing:
http://www.fractalforums.com/3d-fractal-generation/true-3d-mandlebrot-type-fractal/msg7910/#msg7910

 

[Phrak]

I shouldn't be too suprised that the result is disappointing. Thanks for posting the results, though. I've learned subsequent to my previous post that Fractint doesn't support 3D fractals in the way we require, so I can't generate any of these myself.

In looking over the code I posted, if the variable c doesn't range, but is set to zero, the mandelbrot set is recovered in 2D. That is, if c is always zero, then z will always be zero. I don't see that in your image. It may be there, but we're looking at it edge-on. I can't tell what view angle you're using, so I don't know if the observer is in the XY-plane.

In other-words, as a last resort, I'm hoping you made an error in translating my pseudo-code and there's still a chance the 3D factal we're looking for lives in it somewhere.

 

[Twinbee]

Sorry, there was a mistake. I generally use my own version of sin, cos, atan2 etc. which divide or multiply by pi for convenience, and I changed the sin and cos functions, but forgot to change the atan2 function to my own as well, causing a mismatch.

Here's what we should have seen first time. 3 views this time, with lighter areas at the front. The mandelbrot is sort of there (though not completely?) in the first view:

http://www.skytopia.com/stuff/3dmand-phrak.png


Here's the code for you to check (I tried normal sin/cos/atan2 with exactly the same results). Also I tried squarerooting the r2 variable, but a fuzzy blob came up.

triplex trmultiplyPHRAK(triplex *a) {
    triplex n;

    double r2 = a->x*a->x + a->y*a->y + a->z*a->z;
    double theta = 2.0 * matan2(a->y,a->x);
    double phi = 2.0 * matan2(a->z,a->y);

    n.x = r2 * mcos(theta);

    double p = r2 * msin(theta);
    n.y = p * mcos(phi);
    n.z = p * msin(phi);
    return n;
}

Triplex addition is done outside the above multiply function:

newa = tradd( &(trmultiplyPHRAK(&a)) , &point);

 

[Phrak]

I take it that the first frame is looking along z into the xy-plane. The mandelbrot could be burried behind some overhanging structure. If so, it's esthetically not very interesting overall, but there may be more intersting stuff at higher zooms.

Have you considered how difficult it would be to zoom-in on a 3D location? In 2D you can locate a coordinate on the screen. In 3D you don't know where you are without some additional programming-work to move the mouse in 3D and perhaps highlight things it gets close to.

Getting back to your original code where the atan2 function is feed a radius, by a great coincidence, I've been working a problem in differential topology where it is very important that a radial coordinate have an unambiguous positive or negative value. So perhaps if my problem in topology is solvable, it's may be possible to tweek your algorithm to have signed radial coordinates too.

 

[Twinbee]

I take it that the first frame is looking along z into the xy-plane.

Yep.

The mandelbrot could be burried behind some overhanging structure.

I guessed that too. To make sure, I rendered the cross section at precisely z=0. I'll leave you to judge the results, the math may be going slightly screwy somewhere:

http://www.skytopia.com/stuff/mbrot-phrak-crosssection.png

If so, it's esthetically not very interesting overall, but there may be more intersting stuff at higher zooms.

I give it a non-zero percent chance, though I doubt it. I've seen too many of these pictures where one axis is 'dragged along' to create a sheared look.

Have you considered how difficult it would be to zoom-in on a 3D location? In 2D you can locate a coordinate on the screen. In 3D you don't know where you are without some additional programming-work to move the mouse in 3D and perhaps highlight things it gets close to.

Funny you mentioned that - I recently posted about what would be needed at FF. Rather than a camera type zoom (just standard magnification), it would be nice if the camera would instead move in nearer and nearer to the point of interest. As it gets closer to this point, it would need to move slower and slower too. A high angle/field of view would also help create an 'immense parallax/perspective' feel, without the plain orthographic look.

Getting back to your original code where the atan2 function is feed a radius, by a great coincidence, I've been working a problem in differential topology where it is very important that a radial coordinate have an unambiguous positive or negative value.

Good stuff! If I believed in fate (which I don't), I'd say it was meant to be (which I won't) :). Let us know how you get on.

I seem to have found that if it wasn't for the final triplex addition step, the rotation/mulitplication part would be fairly easy to set up to rotate around the sphere in a consistent way. Unfortunately, the addition messes everything up, and ambiguity rears its head.

 

[Phrak]

I guessed that too. To make sure, I rendered the cross section at precisely z=0. I'll leave you to judge the results, the math may be going slightly screwy somewhere:

http://www.skytopia.com/stuff/mbrot-phrak-crosssection.png

I give it a non-zero percent chance, though I doubt it. I've seen too many of these pictures where one axis is 'dragged along' to create a sheared look.

I swear, I've seen this sort of thing before, somewhere. I think it's due to roundoff error in the mantissa's least significant bits. You might try data type long double to see what happens. Also enlightening would be to fix the value of c at some very small value that's equal to the roundoff error of type double. I think it's the 3 least significant bits.

By the way, there should also be a 2D mandelbrot in the ZY-plane when x is set equal to zero.

[/qoute] "Funny you mentioned that - I recently posted about what would be needed at FF. Rather than a camera type zoom (just standard magnification), it would be nice if the camera would instead move in nearer and nearer to the point of interest. As it gets closer to this point, it would need to move slower and slower too. A high angle/field of view would also help create an 'immense parallax/perspective' feel, without the plain orthographic look.[/quote]

Yeah. And the software could calculate with a distance measure for the center of field of both near and far surfaces. In this way you could eventually come up with a cubical volume for the next round of iterations.

Good stuff! If I believed in fate (which I don't), I'd say it was meant to be (which I won't) :). Let us know how you get on.

I seem to have found that if it wasn't for the final triplex addition step, the rotation/mulitplication part would be fairly easy to set up to rotate around the sphere in a consistent way. Unfortunately, the addition messes everything up, and ambiguity rears its head.

I'll see what I can do, but be warned, this is going to take some time I'm attempting to focus directly on the diff topology problem, then applying it, if applicable and viable.

I've been lurking around your Fractal Forum thread. I've discovered that a few ideas I'd had in mind have been worked out already, so instead, I'll be checking the math. That's quite a team you-all have going--and two years persistant, at that. Very impressive.

 

[Phrak]

I just read Wikipedia's long double page.
http://en.wikipedia.org/wiki/Long_double"

On the x86 architecture, most compilers implement long double as the 80-bit extended precision type supported by that hardware (sometimes stored as 12 or 16 bytes to maintain data structure alignment). An exception is Microsoft Visual C++ for x86, which makes long double a synonym for double.[1] (The Intel C++ compiler on Microsoft Windows supports extended precision, but requires the /Qlong‑double switch to access the hardware's extended precision format.[2])

I don't know what compiler you're using; long double is the same as double in Microsoft Visual C++.

 

[Twinbee]

I was using the mingw compiler (through Dev C++). It seems to allow around 17-18 significant digits places compared to float (about 8 or 9). Similar results, are achieved through Visual C by the looks of it, though I haven't tried running it through that yet. Maybe mingw is faulty?

For anyone who's interested, I'm a bit excited at the moment (slight understatement, which itself is a slight understatement). Using the original spherical coords formula, but with a higher power, we're producing results like this:

http://www.skytopia.com/stuff/3dmand.png

Yes, this does seem to be a 'world first'. It's very strange the power 2 version doesn't produce this detail, when higher powers do.

 

[ice109]

what am i looking at here?

 

[Twinbee]

Some of the best visuals ever?

Okay let's try again...

A tasty gateau, and some romanesco broccoli?

Okay, that's not too useful either, let's try once more...

A couple of approx *10 scale zooms into a 'true' 3D version of the original 2D mandelbrot, which uses the same principle as the 2D version, but in 3D space. It's not quaternion, as that seems to only produce "whipped cream" style fractals. In summary, it's still not the holy grail I'm searching for, but let's just say I could've been fooled ;)

 

[Ben Niehoff]

I would be curious to experiment with some of this sometime. I can code calculations in C easily enough. But what are you using to make the 3D pictures themselves?

 

[Twinbee]

Hi Ben, I had to create my own raytracer for it. I'm fairly lazy (and don't like to reinvent the wheel all the time), so at first I tried looking around at the various 3D software, and asking on various forums, but none of them support rendering of arbitrary 3D functions, at least not functions that can contain while loops and local variables.

The closest I got was maybe Sunflow, Blender or POVray, but in these cases, I'm guessing the speed would suffer drastically (one would need to create a giant voxel array or similar, and it may not support say, shadowing in a practical way again because of speed issues). Your mileage may vary however.