Welcome to Fractal Forums

As far as I can tell, the main three coordinate system used in 3D are:
-Triplex (Spherical) Numbers
-Cartesian Coordinates
-Quaternions. Work like Cartesian, but can be manipulate like complex numbers. One dimension is kept at 0.

I've been thinking about other possible systems. Of course, there are ones on Wikipedia, such as:
-Cylindrical coordinates, which involve a height, radius, and angle.
-Parabolic coordinates. Specified by an angle, and coefficients for two parabolas with their foci fixed at their origin.
-Parabolic cylindrical coordinates. Like parabolic coordinates, but instead of using an angle, once specifies a height.
-A whole host of other systems defines by the intersections of the second order curves, planes, and/or tori. See wikipedia for them all.

I've thought of a couple other possibilities:

-One defines a sphere with two poles, not opposite one another, and then one measures the "latitude" from each [plus a radius]. Perhaps this would be interesting as one brings the two poles closer to one another; this may go the limit of the spherical coordinates. Note this would require an extra boolean value to define which half of the sphere it lies on.

-One defines a sphere with two poles, not opposite one another, and then one measures the "longitude" from each [plus a radius]. Perhaps this would be interesting as one brings the two poles closer to one another; this may also go the limit of the spherical coordinates. This is a multivalued function when converting to cartesian coordinates if the point lies on the great circle defined by the two points, but this can be resolved (with an extra boolean) if the point from which the distance measured for the third coordinate is slightly off the center of the sphere.

-Similar to the two above, but one pole uses latitude, the other longitude. Probably all this conflicting symmetry would not apply well to fractals.

-Distance from any three predefined noncollinear points. These three points could be at (1,0,0), (0,1,0), and (0,0,1) in Cartesian coordinates, or (1,0,0), (0,1,0), and (-1,0,0), or even (0,0,0), (1,0,0), and (0,1,0). Or they could form the vertices of an equilateral triangle in the XY plane around the origin.

-It's angles from the origin, that is, the theta and phi in triplex numbers, combined with the angle from some other point; for instance, the angle from the x-axis to the point from the perspective of (1,0,0).

I don't know how well these would lend themselves to aesthetics (or even simple algebraic operations), and I'm sure twinbee has tried several of these, but perhaps some can be well defined, and may produce some interesting results. Thoughts?

I suggest that you start by defining the Mandelbrot set in any of these coordinate systems; for example, in quaternions you have it as (c has only i and j components since it's 2D).  This could give ideas about generalizing it to 3D.

I'm new here, but don't be alarmed. Just dropping by to point you to a kind of spherical coordinates that apparently have not yet been used to try and define some kind of triplex algebra. While it isn't possible to properly cover a sphere with coordinates that have no poles, it is possible to cover it with coordinates that have only a single pole. Here is a sketch to illustrate the general idea:

http://www.vectorizer.org/sphereFan.mpg

The red and green lines are "parallel" grid lines of "latitude" and "longitude" (the yellow great circles are just "diagonals" and an "equator"). I think this is just a reinvention of the Riemann Sphere, or some equivalent. I arrived there starting from bipolar coordinates

http://en.wikipedia.org/wiki/Bipolar_coordinates

and moved the two poles closer and closer together until they met. It wasn't until a few hours later that I realized the relation to the Riemann Sphere mapping.

http://en.wikipedia.org/wiki/Riemann_sphere

The resulting coordinate system has a few unusual properties:

- only a single pole
- "latitude" and "longitude" are symmetrical and exchangeable

and a few usual ones

- "latitude" and "longitude" grid lines intersect at a 90 degree angle
- lengths and areas are not preserved

All in all, these seem to be unusually symmetrical coordinates. I don't know if this is particularly good or bad with respect to fractals. I currently do not have any closed formulas for mapping to cartesian coordinates, but geometrically, there should exist a well-defined correspondence.

I see two outstanding choices for the (0,0) coordinate point: either the pole, or the point directly opposed to it. In either case, the two great circles (one for "latitude" and "longitude" each) could be parameterized with arc length (for purposes of adding "angles"), as has been done in the animated example illustration. I think this would make it possible to embed a 2D Mandelbrot set in a potential 3D fractal.

However, I believe a different parameterization (that spaced the smaller circles close and closer together near the pole) could be better at preserving angles, i.e. it would make the grid cells close to the pole more closely resemble squares. But then the pole would turn into some sort of singularity, with the grid cells becoming infinitesimally small as you approach the pole.

Huh, hobold, that's a very cool coordinate system. It seems it can be interpreted a couple different ways, such as (a) a Riemann sphere projection of the bipolar coordinates, or (b) the way it actually functions in 3D, where each angle specifies the angle a plane takes with the surface of the sphere at the pole, with the restriction that the plane contains one of two perpendicular lines tangent to the pole. In order to make it slightly more square, and this probably isn't the best idea by far, one could take the cube of the angle in the 2D infinite plane (in a way...I don't know how to describe it) which would separate out the lines close to the pole a bit more.

Paolo, good point. Maybe this weekend.

The "monopolar" coordinates are indeed made from two fans of circles originating in the pole. Here is the PoV-Ray scene file used to create the illustration, maybe someone wants to play with it:


#global_settings {
  assumed_gamma 1.0
}

camera {
  location  <0, 0, -4.5>
  direction <0, 0, 2>
  up        <0, 1, 0>
  right     <1, 0, 0>
  sky       <0,1,0>
  look_at   <0, 0, 0>
}

union {

// the base sphere
sphere {<0, 0, 0>, 1.0
  texture{
    pigment { color rgb <0.1, 0.1, 0.9> }
    finish{
      ambient 0.1
      diffuse 0.9
      specular 0.3
      roughness 0.001
    }
  }
}


#declare parts = 40;  // number of grid lines
#declare Count = 1;

#declare px = 0;
#declare py = 0;
#declare diam = 0;
#declare px2 = 0;
#declare py2 = 0;
#declare nod = 0;

#while (Count < parts)
  #declare px = sin(2*pi * Count/parts);  // travel along arc
  #declare py = cos(2*pi * Count/parts);

  #declare Count = Count + 1;

  #declare px2 = px*px;
  #declare py2 = (py - 1)*(py - 1);
  #declare diam = sqrt(px2 + py2);   // distance from pole
  #declare nod = atan2(py - 1, px);  // angle to pole tangent plane

  torus {0.5*diam, 0.005  // a "thick circle" ...
    translate 0.5*diam*x  // ... touching the pole ...
    rotate nod*180/pi*z   // ... and the current point
    translate 1*y

    texture{
      pigment { color rgb <0.1, 0.9, 0.1> }
      finish{
        ambient 0.1
        diffuse 0.9
        specular 0.3
        roughness 0.001
      }
    }
  }
#end

#declare Count = 1;
#while (Count < parts)
  #declare px = sin(2*pi * Count/parts);
  #declare py = cos(2*pi * Count/parts);

  #declare Count = Count + 1;

  #declare px2 = px*px;
  #declare py2 = (py - 1)*(py - 1);
  #declare diam = sqrt(px2 + py2);
  #declare nod = atan2(py - 1, px);

  torus {0.5*diam, 0.005
    translate 0.5*diam*x
    rotate nod*180/pi*z
    translate y
    rotate 90*y   // orthogonal to the first fan of circles

    texture{
      pigment { color rgb <0.9, 0.1, 0.1> }
      finish{
        ambient 0.1
        diffuse 0.9
        specular 0.3
        roughness 0.001
      }
    }
  }
#end

union {
  torus {1.0, 0.005}  // an "equator"
  torus {1.0, 0.005   // a "diagonal"
    rotate 90*z
    rotate 45*y
  }
  torus {1.0, 0.005   // another "diagonal"
    rotate 90*z
    rotate -45*y
  }

  texture{
    pigment { color rgb <0.8, 0.8, 0.2> }
    finish{
      ambient 0.1
      diffuse 0.9
      specular 0.3
      roughness 0.001
    }
  }
}

rotate -60*x
rotate 30*z
rotate -20*x

rotate clock*360*y

}

light_source { 1*<18, 30, 20> color rgb 0.7*<1.0, 1.0, 1.0>}
light_source { <-2, -1, -20> color rgb 0.8*<1, 1, 1>}

background { color rgb <0.5,0.6,0.8> }

For comparison, here is a Riemann Sphere with a checkerboard mapped to it:

http://vectorizer.org/riemann.png    (seen from slightly above the pole)

The tiles get vanishingly small towards the pole, but the grid lines are indeed
circles fanned from the pole.

I think I can safely assume that I re-invented the Riemann 3D-wheel. :-)

I keep tinkering with the "monopolar" coordinates, and I think I should be able to provide formulas. The math is a bit awkward, and will probably be slow and imprecise in the computer, but so far it has been tractable.

With the pole at (0, 1, 0), and the spherical coordinate origin located at the pole, you can get two arc lengths for a point (Px, Py, Pz) on the unit sphere like this:

if (Py == 1) {  // check for pole
  Ax = 0;
  Az = 0;
} else {
  Rx = Px/(Py - 1);                    // Riemann projection
  Ax = atan2(2*Rx, Rx*Rx - 1);   // arc length
  Rz = Pz/(Py - 1);
  Az = atan2(2*Rz, Rz*Rz - 1);
}

As you can see, the numerics will become unstable near the pole (Py = 1), and you need slow trigonometric functions.

Furthermore, the perfect rotational symmetry of the Riemann sphere might cause the resulting 3D-Fractal to be a boring shape with rotational symmetry. Still, we don't know until we tested, so I won't give up yet. :-)


BTW, the monopolar coordinates could potentially be extended from a spherical surface to cover a three dimensional space. The three coordinates would be the two arc lengths above, and a signed(!) distance from the pole. Like having a negative sphere touching the original Riemann sphere at the shared pole. Not sure if those particular 3D coordinates would be good for any fractal purposes.

hobold - your idea is worth a shot.

The symmetry looks a little like one might expect for the 3-d Mandelbrot. The pole could be analogous to the positive x-axis cusp region of the 2-D M-set.

Can you figure out the inverse equation from Ax, Az to Px,Py,Pz? I started on it, but it looks a bit involved. Maybe it simplifies at the end?

-mike

So for any length that would be:

if (Px == 0 && Pz == 0) {
  Ax = 0;
  Az = 0;
} else {
  Length = sqrt(Px*Px+Py*Py+Pz*Pz);
  Rx = Px/(Py - Length);
  Ax = atan2(2*Rx, Rx*Rx - 1);   // arc length
  Rz = Pz/(Py - Length);
  Az = atan2(2*Rz, Rz*Rz - 1);   // arc length
}

Yes (almost). First of all, of course the solution is (0,1,0) is Ax=Az=0, else you have

Rz^2 - 2 / tan Az * Rz - 1 = 0
Rz^2 - 2 * cot Az * Rz - 1 = 0

which gives

Rz = cot Az +- sqrt (cot^2 Az + 1) = cot Az +- csc Az
Rx = cot Ax +- csc Ax

I still haven't figured out how to pick the right solution but only one will give the right Ax/Az when fed back into atan2.  anyway, once you have these you can replace

Px=Rx*(Py-1)
Pz=Rz*(Py-1)

into Px^2+Py^2+Pz^2 = 1 giving

Py^2 (Rx^2+Rz^2+1) - 2 Py (Rx^2 + Rz^2) + (Rx^2 + Rz^2-1) = 0

which has only one valid solution (the other is Py=1 which is invalid):

Px = -2*Rx/(Rx^2+Rz^2+1)
Py = (Rx^2+Rz^2-1)/(Rx^2+Rz^2+1)
Pz = -2*Rz/(Rx^2+Rz^2+1)

That's the next thing I am going to try. I think I already know how I want to construct a solution geometrically:

1. An arc length indirectly specifies a plane, namely the plane of the circle of all points who have that same coordinate value.

2. The two planes of both arc length coordinates intersect in a line (except if both arc lengths are zero, but that case is easy)

3. the line intersects the unit sphere in two points, one of which is the pole

4. the line can be expressed as a ray: <starting point> + <free parameter> * <direction>
I hope to be able to express the line with the pole as starting point, then the first intersection is at parameter value zero and can be divided out, leaving us with just the one desired solution and no need to compute square roots.

I'll try to do this with the necessary mathematical rigour in the next few days.

I am not sure I understand the (Py - Length) term ... ?

My own (Py - 1) comes from "subtract the Pole (0, 1, 0) from the point (Px, Py, Pz)", because I need a direction vector from the pole to the point P (for the Riemann projection). It just so happens that the Y axis is the only coordinate where that requires actual computation.

I'm just computing the angles Ax and Az for (Px/Length, Py/Length, Pz/Length) which gives Rx = Px/Length / (Py/Length - 1) = Px / (Py - Length).  Alternatively...

... when you map a point whose distance from the origin is Length, the pole is at (0, Length, 0).

Ah, that one fits my mental image. Thank you! I had caged myself into the unit sphere, but the radius doesn't really matter at all.

Here's the first attempt to render this fractal, doubling angles and squaring magnitude. I might've made a mistake, so others should try themselves. I used the cot+csc root only. Its possible the roots may need to be selected depending on some criteria. max iterations = 25.

No matter wether or not this includes an error: It looks very promising :D
Now, it's a total brocoli :)

Thanks, msltoe, for your quick efforts! That mushroom doesn't look nearly as boring as I had suspected.

Here is my attempt at an inverse coordinate transform. I don't have a closed formula, but the amount of computation is quite reasonable. From the arc lengths Ax and Az, first we compute Riemann projections onto the cartesian axes:

Rx = sin(Ax)/(1 - cos(Ax))
Rz = sin(Az)/(1 - cos(Az))

then we compute an auxiliary value, a common subexpression (really the free parameter of a ray starting in the pole and having a direction towards the projected point on the "floor")

temp = 2/(Rx*Rx + Rz*Rz + 1)

and finally the point on the unit sphere

Px = Rx*temp
Py = 1 - temp
Pz = Rz*temp

These formulas are completely untested and may contain errors. Use at your own peril. :-)

I've taken a few liberties on the algorithms suggested above, so here's the code I'm using for reference.
There several variations I've tried, but this seems to be the best from an aesthetic point of view.

   r = x*x+y*y+z*z;
   r1= sqrt(r);
   x /= r1; y /= r1; z /= r1;
   
   if ((x==0)&&(z==0)) {
    theta = 0; phi = 0;
   } else {
    rx = x/(y-1);
    theta = 8*atan2(2*rx,rx*rx-1);
    rz = z/(y-1);
    phi   = 8*atan2(2*rz,rz*rz-1);
   }

   rx = sin(theta)/(1+cos(theta));
   rz = sin(phi)/(1+cos(phi));

   d = 2/(rx*rx+rz*rz+1);

   a1 = rx*d;
   b1 = (rx*rx+rz*rz-1)*0.5*d;
   c1 = rz*d;

   x = a+a1*r*r*r*r;
   y = b+b1*r*r*r*r;
   z = c+c1*r*r*r*r;

also a nice one :D

I wonder, what's the *correct* version :)

There probably is no correct one. After all, there exists no "field of numbers" structure on top of a 3D vector space. The aesthetic point of view is not a bad criterion at all.

Msltoe, as far as I can see you seem to have taken a mix of mine and Pablo's inverse transform, and are trying to emulate an eight power like the mandelbulb?

I would find it instructive to see a second power, to better judge the amount of whipped cream ... I guess I will have to bite the bullet and learn about the algorithms needed to render these kinds of fractals. But first, I should test my forward and inverse transforms for correctness.

I sanity-checked my coordinate transforms and found a mistake in the first, cartesian to monopolar, formula. I flipped the sign of the Y axis somewhere. Here are the corrected versions. The origin of the spherical coordinates is still at the pole in this version.

// inputs:  point on unit sphere (Px, Py, Pz)
// outputs: arc lengths Ax, Az
// (origin at the pole)
void cartesian2monopolar(double& Ax, double& Az,
                         const double Px, const double Py, const double Pz) {
  
  if (Py >= 1.0) {  // check for pole
    Ax = 0;
    Az = 0;
  } else {
    double Rx = Px/(1.0 - Py);        // Riemann projection
    Ax = atan2(2.0*Rx, Rx*Rx - 1.0);  // arc length
    double Rz = Pz/(1.0 - Py);
    Az = atan2(2.0*Rz, Rz*Rz - 1.0);
  }
}

// inputs:  arc lengths Ax, Az
// outputs: point on unit sphere (Px, Py, Pz)
// (origin at the pole)
void monopolar2cartesian(double& Px, double& Py, double& Pz,
                         const double Ax, const double Az) {
  
  if (Ax*Az == 0.0) {  // if either Ax or Az equal zero
    Px = 0.0;
    Py = 1.0;
    Pz = 0.0;
  } else {
    double Rx = sin(Ax)/(1.0 - cos(Ax));      // Riemann projection
    double Rz = sin(Az)/(1.0 - cos(Az));
    double temp = 2.0/(Rx*Rx + Rz*Rz + 1.0);  // ray parameter
    Px = Rx*temp;
    Py = 1.0 - temp;
    Pz = Rz*temp;
  }
}

Msltoe lent me a hand in doing a few renders of my own. I think I can now state with some confidence that his first picture (reply #14, on page 1) is "correct", albeit with the origin of the spherical coordinates opposite the pole. My first formulas had erroneously put the origin there, and consequently, Paolo's inverse transform did the same.

With the origin of the spherical coordinates at the pole, the image looks quite different. Still, this isn't the holy grail. Sorry.

I think, the holy grail already was found:
A whole family of 3D-Mandelbrots :)

Often there are multiple ways to generalize a simple principle and if you generalize the generalizations, you suddenly find a singe solution, including them all...

Most likely, this is happening here :)

Your steps are the same as my computation except that in this step I have

Rx = cot Ax +- csc Ax = (cos(Ax) +- 1)/sin(Ax)
Rz = cot Az +- csc Az = (cos(Az) +- 1)/sin(Az)

which is exactly the reciprocal.  Have you checked that you can "roundtrip" a conversion?  BTW if you fix the sign in the formulas for cartesian->riemannian coordinates, my formulas can be easily adjusted to cope with the change: just change the sign of Px and Pz so that the last step becomes the same as yours:

Px = 2*Rx/(Rx^2+Rz^2+1)
Py = (Rx^2+Rz^2-1)/(Rx^2+Rz^2+1)
Pz = 2*Rz/(Rx^2+Rz^2+1)

@msltoe: strictly speaking it is incorrect to use always the same sign in cot/csc (the reason you get two solutions is that taking the tangent reduces the period from 2pi to pi, and you have to choose the solution in the right half), you may give a try to using the right sign.

That's what I meant with sanity check (in reply #20): take a random point on the unit sphere, transform it onto two arc lengths, then transform those back onto cartesian coordinates and subtract the result from the original random point.

For a few million points, the transform was accurate within 15 to 16 decimals. My way of generating random points on the sphere was not optimal, but good enough for these purposes, I guess: create uniformly distributed random points in the (-1, -1, -1) to (1, 1, 1) cube and normalize them to unit length.


In my first attempt (reply #6), I had unintentionally placed the spherical origin opposed to the pole. Later (in reply #20) it is at the pole, because I "fixed" the forward transform to fit my intentions (while you accounted for my misplaced origin in your inverse transform). Msltoe's images, despite the uncertainty in sign, agree with my own experiments so far. I have tried both alternatives, with the spherical origin either at the pole or opposite to it, and msltoe's images look exactly like mine when the origin is opposite.

BTW, here is a degree 8 version of the monopolar fractal. In contrast to msltoe's picture (in reply #17), I used coordinates with the origin at the pole. The general feel of the images is very similar, but they differ quite a bit in the distribution of detail. I am particularly intrigued by the structure that seems to be a four pronged star, apparently diagonal to the monopolar coordinate axes, a little below and left to the image center.

I don't think this thing is visually as rich as the mandelbulb. But on the positive side, the minibulbs here seem to vary more strongly as you travel around the "planet". So there are flat, spiky, and squeezed minibulbs to be explored ... this certainly looks like an interesting alternative to the usual triplex coordinates, which finally brings us back to the topic. :-)

I set my mind on learning more about the nuts and bolts of fractal rendering algorithms. In terms of image quality, the distance estimators seem to be the best bet.

But for those, I need to get a better understanding of the monopolar coordinate transforms. Ideally, I should try to eliminate the trigonometric function calls, and find derivatives analytically. I have read that this has been done for the original triplex mandelbulb. Is there a standard approach to this kind of reformulation, or was it all hard work and divine inspiration?

Well, it seems everyone is working with the monopolar system, but I'd still like to see what results from using a bi-distance coordinate system. I first tried to work what exactly the mapping is in 2D so I could generalize it to 3D... That is, for polar coordinates, the mapping is (Theta,R)->(2*Theta,R^2), which can be generalized to (Theta,Phi,R)->(2*Theta,2*Phi,R^2). For Cartesian it's (x,y)->(x^2-y^2,2xy), which can be generalized using quaternions. I tried to figure out the mapping of (Da,Db)_S, where Da is the distance from (0,1), Db is the distance from (0,-1), and S is -1 or 1 based on the sign of the x-coordinate. Sadly, the mapping for the 2D mandelbrot is very complex; I can't see much pattern to it, making it hard to bring into 3D. First we map (Da,Db) to (x,y) using the correct formula, then (x,y) to (xNew,yNew) using regular complex squaring, and then from (xNew,yNew) back to (DaNew,DbNew). I've found that (xNew,Ynew), as a function of Da and Db, is


Then, (DaNew,DbNew) = ( Sqrt(xNew^2 + (yNew-1)^2) , Sqrt(xNew^2 + (yNew-1)^2). I can't find any pattern to this polynomial for yNew, other than, in each group where Da and Db are raised to the same power overall, (that is, if it's Da^n * Db^m, the portion of the polynomial where n+m is constant) the signs alternate, and it's symmetric. Some of the coefficients remind me of the Boole's rule/Simpson's 3/8 rule, but they aren't the same. Any thoughts?

This is only a crazy idea, thrown into the debate without much advance thought: if the rotation is hard to do in bi-distance coordinates, why not turn around? Do the squaring in the complex plane, but the addition in bi-distance space.

Okay, so this does break the paradigm of generalizing the rotation, but so what? We are exploring without a sound theoretical foundation anyway (well, except Paolo's interesting paper on representing rotations with quaternions - but that theory was discovered after the mandelbulb, not before).

hobold:

If you find a derivative of the first term for the set, anlytically, it's easy to get any further term as the chain-rule applies then which gives

Actually, I'd considered that. The problem is that not all coordinate pairs for bidistal (adjective form ?) coordinates are valid. For instance, (1 , 2.5) and (2 , 3) are both valid coordinates, but (3 , 5.5) isn't.

How about "bidistant" coordinates? No idea how that sounds to a native English speaker. :-)

So the trouble is that those coordinates are not well behaved, probably because the grid lines don't intersect at 90 degree angles ... and some don't intersect each other at all ... Hmm. Well.

Wait! Do we not know that all the interesting Mandelbrot dynamics happens in a compact disk around the origin? If we limit the computation to that disk, maybe one could choose two anchor points such that the coordinates behave well at least inside that disk?

Bidistant sounds good  :) I'm guessing that if we put the two anchor points far enough outside the circle, such as (0,8) and (0,-8), it might work. It would be hard to show though. I'll just try running it through the compiler with x and y specifically set as floats - you can do that, right? - and then see if it ever throws an error.

Two more "visual thoughts" for the bidistant coordinates. I have not lurked here long enough to know if this kind of brainstorming is frowned upon, so in case of emergency, tell me to shut up before I become an annoyance. :-)

Mental image number one: imagine a special bidistant coordinate system, with one anchor point infinitely far away to the "south", and the other one infinitely far away to the "west". Pick a point as the origin, and you have cartesian coordinates. Those are boring. When we move the anchor points closer, the coordinate grid lines become more curved, and thus potentially more interesting. So what we are looking for is how close we can pull the anchor points to the disk of "safe" arithmetic.

Mental image number two: picture an equilateral triangle, say, resting on an edge, with a corner pointing "north". Draw a circle around each vertex, with a radius equal to half the edge length (so the three circles just touch each other). Draw two additional circles with three times that radius around the two corners at the base (so the larger circles just encompass the small circle at the top). The intersection of the hollowed large circles is the area where the bidistant coordinate values are both in the interval [0.5r, 1.5r]. And the top circle is the largest disk contained in that area. Pick the center of the top circle as the origin of the bidistant coordinates. This is a "safe disk" to work with, and it has the curviest coordinate grid possible. No proof, just intuition - build upon this foundation at your own risk.

(A note about me: I was allowed to enjoy a thorough mathematical education, so I am well prepared to make a fool out of myself on a public forum by being sloppy with math. :-) However, I am more of a visual thinker, so as long as no one objects, I will stick to sketching images rather than write down formulas. After all, I am here for fun, not for fame and fortune. I am grateful that I recently discovered the Mandelbulb and fractalforums.com; it reminded me how beautiful and exciting pointless math can be.)

Hmm, sounds interesting. I'm also relatively new here, and I don't even believe in lurking. Just put yourself out there, neh?

I agree with both your mental images. I agree that this "top disk" is the smallest disc inscribable  into these two rings. I just don't understand how you exactly have an "origin" for these coordinates; you have the two anchor points, and that's it. I also don't see exactly how you reach the conclusion that the top circle is a safe disk. I'm glad people are taking an interest!

I used "origin" as mathematical slang for the (0, 0) reference point. In the bidistant coordinates, that point doesn't exist. But (0, 0) really is just a label that you can put anywhere you wish. So you take the center of the top disk, which is at the two distances (edge length, edge length), and translate it by moving all coordinates along the direction vector (-edge length, -edge length). That allows us to do the arithmetic with coordinate values that we need for Mandelbrot iterations. (That particular arithmetic revolves somewhere around zero, so we pull zero to the place where we need it. We bail out of the computation anyway when magnitudes get too large, i.e. when we have gone too far from zero.)

And the disk is "safe" in the sense that inside it, the bidistant coordinates share qualities of other, more traditional, coordinate systems:

- each grid line of "latitude" intersects each grid line of "longitude" exactly once, and vice versa; which means every point has coordinates, and those coordinates are uniquely assigned to that one point
- the coordinate values all come from intervals, in this case [-0.5 edge length, 0.5 edge length], so there are no gaps or holes or infinities

which in turn means that doing computation with coordinate values is somewhat well behaved. You know what you're getting yourself into, before you even start.

Very interesting thread, i have done that in Reply #17 from msltoe, looks like a tropic fruit  :)

@jessy, what about exponent 2?

Just to be sure:
According to #17 i have only to change the two  8*atan2 into 2*atan2  and the end part into x = a+a1*r and the same with y,z?

This one seems to have very thin slices, not easy to render.

beautiful fruit :D

The power 2 salad, slices are very big and i had to zoom out to 0.6

Wow, Jessy, these are very detailed renderings. In that kind of shining quality, it almost looks as if further exploration was worthwhile. Thank you!

Oh, BTW, thinking about Timeroot's exotic coordinate systems, I realized that the monopolar coordinates potentially spawn a whole family of 'bulbs. That's because in those coordinates, too, one could place the origin arbitrarily, and that would influence the dynamics of the iterated function. The added bonus would be that any two such shapes could be seamlessly morphed in an animation where the origin travels along a smooth path.

But before I saw Jessy's pictures, I didn't think the monopolar bulb was detailed enough to bother.

Another one from the top, should have been from the front but i must have lost the orientation  ;D

An animation from power 2 to higher ones should be nice, but that would take too much time for me.
Beneath is one with power 4 but multiplying angles with 8...

Oh, and yet another breathless idea: it might just be possible to morph the standard triplex coordinates into monopolar coordinates, by way of trying to represent the usual latitude/longitude coordinates as a special case of the general bipolar coordinates. And then you could move the two poles arbitrarily, particularly on top of each other.

Moving the origin (not the pole) of the monopolar coordinate system does indeed work. It doesn't really add variety, but does shake up the perfect symmetries. Here's a bit of code that introduces two new parameters AxOffset and AzOffset. For reasons of symmetry, the interesting ranges of those parameters are 0 <= AxOffset <= AzOffset <= Pi. Other values are possible, but do not lead to new results.


    // normalize (Px, Py, Pz) first as usual, then rotate it with the following code

    if (Py >= 1.0) {  // check for pole
      Ax = 0;
      Az = 0;
    } else {
      double R = Px/(1.0 - Py);      // Riemann projection
      Ax = atan2(2.0*R, R*R - 1.0);  // arc length
      R = Pz/(1.0 - Py);
      Az = atan2(2.0*R, R*R - 1.0);
    }
    Az -= AzOffset;
    Ax -= AxOffset;
    
    // manipulate Ax, Az here
    // for example the standard emulation of an eighth power:
    Ax *= 8.0;
    Ay *= 8.0;
    
    // transform monopolar back to cartesian
    Ax += AxOffset;
    Az += AzOffset;
    if (Ax*Az == 0.0) {  // if either Ax or Az equal zero
      Px = 0.0;
      Py = 1.0;
      Pz = 0.0;
    } else {
      double Rx = sin(Ax)/(1.0 - cos(Ax));      // Riemann projection
      double Rz = sin(Az)/(1.0 - cos(Az));
      double temp = 2.0/(Rx*Rx + Rz*Rz + 1.0);  // ray parameter
      Px = Rx*temp;
      Py = 1.0 - temp;
      Pz = Rz*temp;
    }

    // now proceed to set the length of (Px, Py, Pz) as usual


It should be possible to morph between, say, the "origin at pole" and "origin opposite the pole" versions by varying AxOffset and AzOffset from zero to Pi in lockstep. But any other smooth path should lead to seamless morphs, I guess.


Jessy, did you use a renderer of your own? Or is there some visualization toolkit already out there?

@hobold

I can try this one, but what about morving the Riemannian geometry into a linear Euclidian geometry?
Putting infinity not to the opposite pole, but nearer and nearer to lower angles, so it becomes linear? (I am not the mathematic genius, but should work somehow, i hope)

Would be interesting to see the classic bulb becoming a riemannian one!

Yes, i have my own software project which is still in developement. Just tried Chaos Pro, that is for free and seems to be astounding complex. Including writing your own formulas, i guess. But it would take more time for me to get into it, instead of programming by myself.

I just cant say if or when i release my program, because by now it is also very difficult to handle and understand for somebody else.
And no function parser so far.

That does not easily work, because the sphere and the flat plane are not really ... compatible (the buzzword here is "topology"). Riemann had to add "infinity" as one more point to the set, otherwise his sphere would have had a tiny tiny hole at its pole. The sphere needs that one extra point to be complete, but the flat plane does not really have room for that one point. That's why the added point does not have coordinates in the flat plane; it needs to be out of reach of the usual (x, y) number pairs. That's why it is called the "infinitely distant" point, literally beyond the flat coordinates.

Or in other words, when you try to lower the pole of Riemann's sphere to lower angles, the sphere will have a hole and be incomplete. There would be points for which no coordinates can be easily defined. So you would be unable to do any fractal iterations with those points.


My other point about morphing between the classical Mandelbulb and the monopolar fractal is a bit trickier than I thought. There is no obvious way to parameterize the circular grid lines consistently. I noticed this when I tried to do a sketch with a north pole and an east pole. It is possible to do that, but the sketch would be somewhat arbitrary with respect to the distances between adjacent grid lines.


About your renderer: this was not an attempt to bait you into giving your code away. I was just impressed how quickly you were able to render an arbitrary formula in such high quality. I am currently tinkering with my own pre-pre-alpha version of a low quality renderer. It can already render flat outlines of 3D fractal shapes. It will be terribly slow and imprecise, but it's fun to go my own way, and see the shapes slowly materializing out of the fog, so to speak ... :-)

Ok, i made a also a mistake: if infinity becomes Pi in a riemann sphaere (is this correct?), so we had to morph the way that infinity becomes infinity again.  ???

The progamming thing: i startet with slicing from background to foreground, until i found out that if i slice the different way i can ommit the pixels that are already in the set.  :) Then i made the DE thing and this was also faster because for every pixel you can skip many pixels in flat areas to calculate.
And it was not a big step from my first attempts to now, so you are on a good way.

Another question: if i dont want to register to youtube, where should i upload an animation (1.8MB)?

I talked Jessy into letting me host his animation on my webspace. The video shows monopolar bulbs with a smoothly varying exponent from 2 to 10. This is an experiment to see what my humble virtual server can handle, so the video is linked from nowhere but here. Have a look at: http://www.vectorizer.org/guesthouse/RiePow1to10.AVI (http://www.vectorizer.org/guesthouse/RiePow1to10.AVI).

I tried some offsets, but so far i would say that the changes are not very great or leading to very interesting morphs... but i may do more testing if i find more time for it. So no animation for this one by now. (the little ani you got took about 10 hours)

As far as I can tell, the displaced origin causes the grid cells of the "Riemandelbulb" to shift around a bit, without changing their underlying shape. It doesn't change the nature of the fractal, but breaks the perfect symmetry. I cannot render good pictures yet ... trying to shade a fractal surface is a thankless job. :-)

I guess I really need to find out more about this idea of moving the poles independently. Morphing between the original Mandelbulb and the Riemandelbulb should lead to more interesting shapes. But for now I am wrestling with rendering algorithms.

Oh and the "little anim" is quite striking. This thing really seems to differ from the Mandelbulb in substantial ways. Thanks for taking the time to render this!


Edit: another thing. I need a better name for the monopolar fractal. How does "Riemandelettuce" sound? :-)

Yes, thats why the normals are calculated at some distance from the "real" surface, that is the whole trick.
Else you have to average the iterationcounts from many points to get a better estimate.



So we are all inventing the wheel again, but thats live  :)


Sounds Riemandelicious  ;)
For the higher power versions i had the word Riemandianpineapple in mind, but that gag doesnt work in english  ::)
Hmm, its really striking to explore new things, there had to be a gallery from all discovered bulbs so far, this would also help not to discover things again and again...

Riemandelsche Ananas? Haha, nice :)

Ah! Thanks!
I was wondering how you are doing to get those so beautiful and clean renderings :D

Wow, for some reason I don't get it... Could you post pseudocode for normal? Thanks.

About the Normals, that is all explained in the endless Threads with Distance Estimation, i just cant get helpful links from scratch.

Maybe an illustration helps, you step along the ray and if the distance estimation (DE) you  get on the ray is below a threshold,
you step back to the threshold (blue points) by a binary search and calculate the normals from the local gradients in form of DEs, or you can use the gradients from the smooth iterations itself for the normals.

But i am still learning and doing improvements, so this is a rough explanation.
Just found a bug in the phong shading, so the next images will be probably better  :)

A sidenote: I decided to cheat for my rendering experiments. I will separate the steps of fractal creation, distance estimation, and rendering/lighting from each other. I know this approach has downsides (for example, you cannot efficiently animate changing parameters of the formula), but overall it seems to be a good trade-off.

The plan is
1. to fill a 3D volume with just the inside/outside information of any arbitrary fractal formula (just one bit per voxel)

2. do a general distance transform on that (only needs to be very accurate near the fractal border, so one byte per voxel should do)

3. trace rays through the volume of distances to render isosurfaces

The hard part was number 2, but I made very good progress on that. One 1000x1000 slice takes less than 0.5 seconds to transform with Saito's algorithm, and extending the method to three dimensions is straight forward. So I should be able to obtain the exact distance transform of a 1000^3 volume in less than 1000 seconds on one processor core. (That's why my renderer will only be good for flying around static objects, but that's my first goal.)

I already have a basic raytracer that uses second order spline interpolation of the voxel data for smooth isosurfaces and consistent surface normals. I hope I can speed it up significantly using the exact distance information.


My renderings won't be so beautiful, but I should be able to produce fly around animations of any weird fractal formula, no matter if an analytical distance estimate even exists. And I would be able to render inside views. Main memory is the limiting factor of the basic method as outlined here - a 1024^3 volume needs at least a gigabyte of RAM during rendering - but if this works at all, it can always be extended with more efficient data structures like an octree.

This makes sense, thanks.

Hobold, in my wishlist is also a flymode, or as i would implement it: a slow walking mode  :)
Doing some basic OpenGL that is not too difficult and calculating the surface in the near surrounding via CPU.

But i have to finish the current project before...

I realize that everyone is basically using the monopolar coordinates, but I'd like to just add one more idea to the mix. In my first post, I mentioned an idea with 4 poles, with the two North poles being perpendicular. It just occured to me now that if we arranged these four poles on the sphere like a tetrahedron's vertices, and measure the latitudes from the lines connecting two (we'd only connect two pairs, they would be skew lines), this might preserve more symmetry. Just an idea.

@Timeroot: sorry for hijacking your thread. I hope to return to the original journey, exploring more exotic coordinate systems. I try to keep my planned renderer generic and independent of specific formulas for that very reason.

Your sketch of "quadrupolar" coordinates ... I am trying to picture them. It seems to me that what you are doing is to drag out each pole into a finite line segment. The ending points of such a line segment would then be the focal points of "concentric" elliptical grid lines. All this projected onto a sphere, so the grid lines are really polynomial curves of order four or higher. This will be complicated. But by varying lengths and orientations of the northern and the southern line segment each, you would be able to break the symmetry of the standard spherical coordinates. This could well lead to more variety of shapes.

My Avatar on Riemann sphere.