After seeing the mandelbulb getting some press recently on slashdot, I 
started to wonder how close I could get with povray.
I forgot to segment the parts of the isosurface into the x,y,z 
components (added them instead), and this happened, at least it's fun 
looking.

#local n = 8;
#local r = function{sqrt(pow(x,2)+pow(y,2)+pow(z,2))};
#local theta = function{atan2(sqrt(pow(x,2)+pow(y,2)),z)};
#local phi = function{atan2(y,x)};
isosurface{
   function { 
pow(r(x,y,z),n)*(sin(theta(x,y,z)*n)*cos(phi(x,y,z)*n)+sin(theta(x,y,z)*n)*sin(phi(x,y,z)*n)+cos(theta(x,y,z)*n))

}
   threshold 0
   max_gradient 57
   contained_by {sphere{0,1}}
   texture{
     pigment{color rgb 0.8}
     finish{ambient 0 diffuse 1}
   }
}

Post a reply to this message

Attachments:
Download 'mandelball.jpg' (22 KB)

Preview of image 'mandelball.jpg'

That's cool.

I've been wondering the same thing, but I haven't made any effort to 
find out if it's possible to do the Mandelbulb in POV.  I figure someone 
who knows a lot more than me will figure it out first.

On 2009-11-16 20:30, CShake wrote:
> After seeing the mandelbulb getting some press recently on slashdot, I
> started to wonder how close I could get with povray.
> I forgot to segment the parts of the isosurface into the x,y,z
> components (added them instead), and this happened, at least it's fun
> looking.
>
> #local n = 8;
> #local r = function{sqrt(pow(x,2)+pow(y,2)+pow(z,2))};
> #local theta = function{atan2(sqrt(pow(x,2)+pow(y,2)),z)};
> #local phi = function{atan2(y,x)};
> isosurface{
> function {
>
pow(r(x,y,z),n)*(sin(theta(x,y,z)*n)*cos(phi(x,y,z)*n)+sin(theta(x,y,z)*n)*sin(phi(x,y,z)*n)+cos(theta(x,y,z)*n))
> }
> threshold 0
> max_gradient 57
> contained_by {sphere{0,1}}
> texture{
> pigment{color rgb 0.8}
> finish{ambient 0 diffuse 1}
> }
> }

Post a reply to this message

> I've been wondering the same thing, but I haven't made any effort to find 
> out if it's possible to do the Mandelbulb in POV.  I figure someone who 
> knows a lot more than me will figure it out first.

I think it would be easiest (ie not take 400 years) if you made a program in 
a faster language (eg C++) to write a df3 file, and then used POV to render 
the df3 file as an isosurface.

Post a reply to this message

scott wrote:
>> I've been wondering the same thing, but I haven't made any effort to 
>> find out if it's possible to do the Mandelbulb in POV.  I figure 
>> someone who knows a lot more than me will figure it out first.
> 
> I think it would be easiest (ie not take 400 years) if you made a 
> program in a faster language (eg C++) to write a df3 file, and then used 
> POV to render the df3 file as an isosurface.
> 
> 

Like this?
http://news.povray.org/povray.binaries.animations/thread/%3Cweb.4b02da71bde7fd6d299b4a940%40news.povray.org%3E/
That 256x256x256 df3 took a few minutes to generate on my machine, so 
the proof of concept works.

I haven't optimized the code too far yet, it's still using the trig 
functions, but it can be used for any value N. It's ready to render a 
XxYxZ resolution mesh at any zoom, defined by passing min and max values 
for each dimension. Unfortunately it's not multi-threaded yet either, 
but as soon as I learn a bit more about how to write that, the structure 
of the code will require very little modification to allow that.

Chris

Post a reply to this message

> Like this?
>
http://news.povray.org/povray.binaries.animations/thread/%3Cweb.4b02da71bde7fd6d299b4a940%40news.povray.org%3E/
> That 256x256x256 df3 took a few minutes to generate on my machine, so the 
> proof of concept works.

Hehe I just did the same :-)  Mine was 1024x1024x1024 df3 file which took 
about half an hour multithreaded under c#.net (I decided the speedup I could 
get by easy multithreading in c# outweighed the speedup I could get with C++ 
over C#).  The render only took about 2 minutes, it's just an isosurface and 
a few lights.

> I haven't optimized the code too far yet, it's still using the trig 
> functions, but it can be used for any value N.

Yeh mine too, it looks like there should be a way to lose the trig even with 
N=8, but it might get a bit scary...

> Unfortunately it's not multi-threaded yet either, but as soon as I learn a 
> bit more about how to write that, the structure of the code will require 
> very little modification to allow that.

Yeh, I chose to do it under C# because it's very easy to do the 
multithreading on there and I have no experience of doing multithreading on 
normal C++.  I just wanted to get something working this afternoon to see 
what it looked like.

The issue is that the isosurface is still made up of millions of little cube 
shaped voxels, I think the only way to improve that is to write a 
fractal-ray tracer too!  Or maybe patch POV...

Post a reply to this message

Attachments:
Download 'mandelbulb.jpg' (112 KB)

Preview of image 'mandelbulb.jpg'

scott wrote:
>> Like this?
>>
http://news.povray.org/povray.binaries.animations/thread/%3Cweb.4b02da71bde7fd6d299b4a940%40news.povray.org%3E/

>>
>> That 256x256x256 df3 took a few minutes to generate on my machine, so 
>> the proof of concept works.
> 
> Hehe I just did the same :-)  Mine was 1024x1024x1024 df3 file which 
> took about half an hour multithreaded under c#.net (I decided the 
> speedup I could get by easy multithreading in c# outweighed the speedup 
> I could get with C++ over C#).  The render only took about 2 minutes, 
> it's just an isosurface and a few lights.
> 
>> I haven't optimized the code too far yet, it's still using the trig 
>> functions, but it can be used for any value N.
> 
> Yeh mine too, it looks like there should be a way to lose the trig even 
> with N=8, but it might get a bit scary...
> 
>> Unfortunately it's not multi-threaded yet either, but as soon as I 
>> learn a bit more about how to write that, the structure of the code 
>> will require very little modification to allow that.
> 
> Yeh, I chose to do it under C# because it's very easy to do the 
> multithreading on there and I have no experience of doing multithreading 
> on normal C++.  I just wanted to get something working this afternoon to 
> see what it looked like.
> 
> The issue is that the isosurface is still made up of millions of little 
> cube shaped voxels, I think the only way to improve that is to write a 
> fractal-ray tracer too!  Or maybe patch POV...
> 
> 
> ------------------------------------------------------------------------
> 

Amazing!  I wish I was half as smart as all these programmers around 
here.  I'd love to see a large and detailed render.

Post a reply to this message

scott wrote:
>> Like this?
>> http://news.povray.org/povray.binaries.animations/thread/%3Cweb.4b02da
71bde7fd6d299b4a940%40news.povray.org%3E/ 
>>
>> That 256x256x256 df3 took a few minutes to generate on my machine, so 

>> the proof of concept works.
> 
> Hehe I just did the same :-)  Mine was 1024x1024x1024 df3 file which 
> took about half an hour multithreaded under c#.net (I decided the 
> speedup I could get by easy multithreading in c# outweighed the speedup
 
> I could get with C++ over C#).  The render only took about 2 minutes, 
> it's just an isosurface and a few lights.
> 
>> I haven't optimized the code too far yet, it's still using the trig 
>> functions, but it can be used for any value N.
> 
> Yeh mine too, it looks like there should be a way to lose the trig even
 
> with N=8, but it might get a bit scary...
> 
>> Unfortunately it's not multi-threaded yet either, but as soon as I 
>> learn a bit more about how to write that, the structure of the code 
>> will require very little modification to allow that.
> 
> Yeh, I chose to do it under C# because it's very easy to do the 
> multithreading on there and I have no experience of doing multithreadin
g 
> on normal C++.  I just wanted to get something working this afternoon t
o 
> see what it looked like.
> 
	Well, if your compiler supports OpenMP, the multithreading is as 
simple as including omp.h and writing "#pragma omp parallel for 
shared(a)" just before your outer loop (where "a" is the name of the 
array in which you store your results)...

See: https://computing.llnl.gov/tutorials/openMP/

		Jerome
-- 
mailto:jeb### [at] freefr
http://jeberger.free.fr
Jabber: jeb### [at] jabberfr

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

scott schrieb:
> 
> The issue is that the isosurface is still made up of millions of little 
> cube shaped voxels, I think the only way to improve that is to write a 
> fractal-ray tracer too!  Or maybe patch POV...

... or use the "interpolate" keyword?

If you use tricubic interpolation, you may want to change your generator 
program though, to output not values 0 and 255, but something like 64 
and 192, as some versions of POV-Ray have bugs in the interpolation code 
that may otherwise cause artifacts due to "overshoot".

Post a reply to this message

> ... or use the "interpolate" keyword?

It's already using interpolate 1 (interpolate 2 was very slow and I couldn't 
see much difference from this zoom), but as all voxels are either 0 or 255 
you still get a very rough look.

> If you use tricubic interpolation, you may want to change your generator 
> program though, to output not values 0 and 255, but something like 64 and 
> 192,

Yeh good idea, I could do something clever in the df3 generator to output a 
varying value depending on how "close" the voxel is to the border.

Post a reply to this message

> Amazing!  I wish I was half as smart as all these programmers around here. 
> I'd love to see a large and detailed render.

Better?  There are still artifacts due to the discrete nature of the df3 
file, but I'm working on it.

Generating a df3 file from code outside of POV is not very hard.  And I just 
copied the formulas to generate the fractal from the websites referenced.

Post a reply to this message

Attachments:
Download 'mandelbulb4.jpg' (490 KB)

Preview of image 'mandelbulb4.jpg'

scott schrieb:

> Better?  There are still artifacts due to the discrete nature of the df3 
> file, but I'm working on it.

That's an interesting effect though. Looks like knitwear or the like.

Post a reply to this message

"scott" <sco### [at] scottcom> wrote:
> Better?  There are still artifacts due to the discrete nature of the df3
> file, but I'm working on it.
>
> Generating a df3 file from code outside of POV is not very hard.  And I just
> copied the formulas to generate the fractal from the websites referenced.

I modified the (illegal, but still renders) recursive function formulation
posted by Warp and managed to get a straight SDL isosurface.  This is the result
of six iterations.  The render time isn't too terribly bad if you can find a
good combination of accuracy and max_gradient.  Due to the object's fractal
nature, the reported maximum gradient doesn't help, though.

Shutdown Warning: The maximum gradient found was 1019075328.000, but
 max_gradient of the isosurface was set to 2048.000. The isosurface may contain
 holes! Adjust max_gradient to get a proper rendering of the isosurface.

-David

Post a reply to this message

Attachments:
Download 'mandelbulb8i6.015.png' (602 KB)

Preview of image 'mandelbulb8i6.015.png'

waggy wrote:
> I modified the (illegal, but still renders) recursive function formulation
> posted by Warp and managed to get a straight SDL isosurface.  This is the result
> of six iterations.  The render time isn't too terribly bad if you can find a
> good combination of accuracy and max_gradient.  Due to the object's fractal
> nature, the reported maximum gradient doesn't help, though.
> 
> Shutdown Warning: The maximum gradient found was 1019075328.000, but
>  max_gradient of the isosurface was set to 2048.000. The isosurface may contain
>  holes! Adjust max_gradient to get a proper rendering of the isosurface.
> 
> -David
> 
> ------------------------------------------------------------------------
> 
Nice!
Now figure out how to zoom in to get all the fun details... ;)

Chris

Post a reply to this message

CShake wrote:
> Nice!
> Now figure out how to zoom in to get all the fun details... ;)

Thanks!

Since it's a just an isosurface, all you have to do is move the camera closer
and adjust the accuracy and max_gradient proportional to the "zoom level".

This is still six iterations.

~David

Post a reply to this message

Attachments:
Download 'mandelbulb8i6-closer.png' (346 KB)

Preview of image 'mandelbulb8i6-closer.png'

Oh, and here is the same view with the isosurface function limited to eight
iterations.

I just found the function also works well, and is far, far quicker, as a media
density.

Good times.

~David

Post a reply to this message

Attachments:
Download 'mandelbulb8i8-closer.png' (346 KB)

Preview of image 'mandelbulb8i8-closer.png'

waggy wrote:
> Oh, and here is the same view with the isosurface function limited to eight
> iterations.
> 
> I just found the function also works well, and is far, far quicker, as a media
> density.
> 
> Good times.
> 
> ~David

Well, I'm seeing that the actual surface generation and rendering is 
probably best left to people like you who seem to get good results, so I 
figured I might as well go another direction with it.

Instead of going for the full 3d, as many of you are, I decided to make 
a way to get 2d 'slices' of this beast that allow for nice smooth 
coloring based on divergence rate, like most of the pictures for the 
original Mandelblot, instead of only edge finding like everyone seems to 
be doing with this so far. I wrote some code that will generate 
grayscale images based on number of iterations according to various 
parameters.

Here is one slice, generated with parameters mirroring povray:
center = <0.7275,0.272,0.5>
right = <0.001,0,0>
up = <0,0.001,0>
n = 8
max_iterations = 200
This image is NOT pov-created, but can be used for patterns and the 
like. It was originally generated at 5000x5000 (.png) which took about a 
minute, then downsized for uploading here.

C++ source available on request, the only dependencies are ImageMagick 
for creating the image file itself, and a compiler supporting OpenMP.

Post a reply to this message

Attachments:
Download 'mb_slice_demo.jpg' (270 KB)

Preview of image 'mb_slice_demo.jpg'

"scott" <sco### [at] scottcom> wrote:

> Hehe I just did the same :-)  Mine was 1024x1024x1024 df3 file which took
> about half an hour multithreaded under c#.net (I decided the speedup I could
> get by easy multithreading in c# outweighed the speedup I could get with C++
> over C#).  The render only took about 2 minutes, it's just an isosurface and
> a few lights.

Nice work, Scott. And others!

I have a slow old machine, with only 768MB of RAM, so my renders take a bit
longer, and my biggest so far is 800³, which you can see below.

I'm especially jealous of that special version of povray that can do custom
fractal functions. :) But I suppose it's probably slower than using a density
file. (I haven't played with them much before, and I'm frankly amazed at how
fast those things parse, even fairly huge ones.)

I *think* I figured a way to do this Mandelbulb function using standard SDL. We
don't need the ability to do arbitrarily deep iterations, since 6 or
7 are quite adequate. So we could unroll the iteration loop... into a veritable
rats' nest of functions, which would probably involve lots of duplicated
evaluations & be incredibly slow. :)

> > I haven't optimized the code too far yet, it's still using the trig
> > functions, but it can be used for any value N.
>
> Yeh mine too, it looks like there should be a way to lose the trig even with
> N=8, but it might get a bit scary...

You can lose the trig functions by using the formulae of sin(2t) & cos(2t) in
terms of sin(t) & cos(t). We want the 8th power, so we just double the angle 3
times. My first explorations of the Mandelbulb used Python to generate the voxel
data, but I translated my code to C today, and it should compile with no
problems on any system (if it supports doubles :)).

To avoid clutter, I'll post my C source in a separate message in this thread.

> The issue is that the isosurface is still made up of millions of little cube
> shaped voxels, I think the only way to improve that is to write a
> fractal-ray tracer too!  Or maybe patch POV...

Your renders look a fair bit smoother than mine. What accuracy are you using on
the isosurface, and what sort of max_gradient for that size grid? The one below
uses max_gradient 1072, accuracy 0.002.

The pigment on the attached image is just function{sqrt(x*x+z*z)*4.5}, with an
old favourite colour map I created many years ago when I was writing 2D
Mandelbrot programs on the Amiga.

Post a reply to this message

Attachments:
Download 'mandelbulbg8sa90.jpg' (160 KB)

Preview of image 'mandelbulbg8sa90.jpg'

Simple "Mandelbulb" C source code.

Compile with

gcc -o Mandelbulb Mandelbulb.c -lm -O3


/*
 * Mandelbulb
 *
 * Written by PM 2Ring November 2009.
 * Converted from Python to C, 2009.11.21
 *
 */

/*

From http://www.skytopia.com/project/fractal/mandelbulb.html

Similar to the original 2D Mandelbrot , the 3D formula is defined by:

z -> z^n + c

....but where 'z' and 'c' are hypercomplex ('triplex') numbers, representing
Cartesian x, y, and z coordinates. The exponentiation term is defined by:

{x,y,z}^n = r^n {sin(theta*n) * cos(phi*n), sin(theta*n) * sin(phi*n),
cos(theta*n)}
where
r = sqrt(x^2 + y^2 + z^2)
theta = atan2(sqrt(x^2+y^2), z)
phi = atan2(y, x)
n is the order of the 3D Mandelbulb. Use n=8 to find the exact object in this
article.

The addition term in z -> z^n + c is similar to standard complex addition,
and is simply defined by:

{x,y,z}+{a,b,c} = {x+a, y+b, z+c}

The rest of the algorithm is similar to the 2D Mandelbrot!

*/

#include <math.h>
#include <stdio.h>
#include <time.h>

//Compute sin(8t) & cos(8t) given r*sin(t), r*cos(t) & r
void trig8(double *ps, double *pc, double r)
{
    //int i;
    double c = *pc, s = *ps, t;

    if (r > 0.0)
    {
        s /= r;
        c /= r;
        //Iterate formulae for sin(2t) & cos(2t) 3 times
        //to get sin(8t) & cos(8t)
        //for (i=0; i<3; i++)
        //{
            t = 2.0*s*c; c = c*c - s*s; s = t;
            t = 2.0*s*c; c = c*c - s*s; s = t;
            t = 2.0*s*c; c = c*c - s*s; s = t;
        //}

        *ps = s;
        *pc = c;
    }
}

//Determine if voxel (cx, cy, cz) is in the Mandelbulb
int Mandel3D(double cx, double cy, double cz, int iters)
{
    double x = cx, y = cy, z = cz, w, w2, r, r2, r8,
    sth8, cth8, sph8, cph8;
    int i;

    for (i=0; i<iters; i++)
    {
        //Convert (x, y, z) coordinates to polar (r, th, ph)
        w2 = x*x + y*y;
        w = sqrt(w2);
        r2 = w2 + z*z;
        r = sqrt(r2);
        if (r >= 2.0)
            return 0;

        //Raise (r, th, ph) to the 8th power
        sth8 = w; cth8 = z; trig8(&sth8, &cth8, r);
        sph8 = y; cph8 = x; trig8(&sph8, &cph8, w);

        //(r, th, ph) <- c + (r, th, ph)^8
        r8 = r2 * r2 * r2 * r2;
        x = cx + r8 * sth8 * cph8;
        y = cy + r8 * sth8 * sph8;
        z = cz + r8 * cth8;
    }
    return 1;
}

int Mandelbulb(double vx, double vy, double vz, double scale, int side, int
iters, char *fname)
{
    FILE *f;
    unsigned char *row;
    int i, j, k;
    time_t itime;
    double x, y, z;

    if(!(f = fopen(fname, "wb")))
        return 1;

    if(!(row = (unsigned char *) malloc(side)))
        return 1;

    //Write header: voxel grid dimensions in little endian
    {
        unsigned char lo = side & 0xff, hi = side >> 8;

        fprintf(f, "%c%c%c%c%c%c", hi, lo, hi, lo, hi, lo);
    }

    itime = time(NULL);
    for (k=0; k<side; k++)
    {
        //Planes
        z = vz + scale * k;
        for (j=0; j<side; j++)
        {
            //Rows
            y = vy + scale * j;
            for (i=0; i<side; i++)
                //Voxels
                row[i] = Mandel3D(vx + scale * i, y, z, iters) ? 255 : 0;
            fwrite(row, 1, side, f);
        }

        if (k%10 == 0)
        {
            int n = (int) difftime(time(NULL), itime);

            //fputc('.', stderr);
            fprintf(stderr, "\r %2d:%02d:%02d Plane %d of %d ",
                n/3600, (n/60)%60, n%60, k, side);
        }
    }

    free(row);
    fclose(f);

    return 0;
}

int main(int argc, char *argv[])
{
    int side, iters, rc;
    char *fname;
    double r, scale;

    side = argc > 1 ? atoi(argv[1]) : 100;
    fname = argc > 2 ? argv[2] : "Mandelbulb.df3";
    iters = argc > 3 ? atoi(argv[3]) : 7;

    r = 1.1;    //Mandelbulb Set "radius"
    //r = 1.05 * (1.0 + 2.0 / side);
    scale = 2.0*r / (side - 1);

    rc = Mandelbulb(-r, -r, -r, scale, side, iters, fname);

    fputc('\n', stderr);
    return rc;
}

Post a reply to this message

scott wrote:
> I think it would be easiest (ie not take 400 years) if you made a
> program in a faster language (eg C++) to write a df3 file, and then used
> POV to render the df3 file as an isosurface.

  Why does it have to be an isosurface? If you created a mesh out of it,
it would probably render about a thousand times faster, in which case
you could start adding fancy texturing, lighting and other effects
without having to wait until the Sun dies.

Post a reply to this message

CShake wrote:
> Well, I'm seeing that the actual surface generation and rendering is
> probably best left to people like you who seem to get good results, so I
> figured I might as well go another direction with it.
>
Wow!  That's gorgeous!  I can imagine some good uses for it.

To see about making an animated fly-through, I zoomed way in by using trace() to
place the camera on a surface a few iteration levels above the look_at point on
the iteration ten (10) surface here rendered.  Since I picked starting and
target points more-or-less at random, I have no idea where this surface is, and
there is only a single light source placed at the camera location.  I also
shrunk the contained_by (too much, it turned out) to avoid overheating the CPU
when the sun goes nova.

Are we having too much fun yet?

~David


  Trace Time:       1 hours 45 minutes 26 seconds (6326.522 seconds)
              using 8 thread(s) with 47526.303 CPU-seconds total

Post a reply to this message

Attachments:
Download 'mb8i10_zoom_1.png' (220 KB)

Preview of image 'mb8i10_zoom_1.png'

waggy wrote:
> CShake wrote:
>> Well, I'm seeing that the actual surface generation and rendering is
>> probably best left to people like you who seem to get good results, so I
>> figured I might as well go another direction with it.
>>
> Wow!  That's gorgeous!  I can imagine some good uses for it.
> 
> To see about making an animated fly-through, I zoomed way in by using trace() to
> place the camera on a surface a few iteration levels above the look_at point on
> the iteration ten (10) surface here rendered.  Since I picked starting and
> target points more-or-less at random, I have no idea where this surface is, and
> there is only a single light source placed at the camera location.  I also
> shrunk the contained_by (too much, it turned out) to avoid overheating the CPU
> when the sun goes nova.
> 
> Are we having too much fun yet?
> 
> ~David
> 
> 
>   Trace Time:       1 hours 45 minutes 26 seconds (6326.522 seconds)
>               using 8 thread(s) with 47526.303 CPU-seconds total
> 
> 
> ------------------------------------------------------------------------
> 

Here's another one, grayscale generated in c++ in 5 minutes or so 
(5000x5000), used as an image_pattern in povray with a color map 
applied, rendered at 2500x2500 (15 seconds), then resized down for 
upload (and to smooth a bit).
The hardest part is finding where to zoom in actually, there are a lot 
of places with nothing, then others with lots of curved lines going the 
same way.

Post a reply to this message

Attachments:
Download 'mbslice_colored3.jpg' (281 KB)

Preview of image 'mbslice_colored3.jpg'

I dare you to render this thing as glass.

--
Tim Cook
http://empyrean.freesitespace.net

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> scott wrote:
> > I think it would be easiest (ie not take 400 years) if you made a
> > program in a faster language (eg C++) to write a df3 file, and then used
> > POV to render the df3 file as an isosurface.
>
>   Why does it have to be an isosurface? If you created a mesh out of it,
> it would probably render about a thousand times faster, in which case
> you could start adding fancy texturing, lighting and other effects
> without having to wait until the Sun dies.

Hi, Warp.

How do you turn a df3 density file into a mesh? Or do you mean convert the voxel
data into a mesh before feeding it to povray? Is there an easy way to do this? I
know how to turn a heightfield into a mesh, but not a solid 3D object like the
Mandelbulb, with its many internal holes.

Here is a monochrome GIF anim of XY plane cross sections through a 121³ voxel
Mandelbulb. (174410 bytes)
http://i2.photobucket.com/albums/y43/PM2Ring/Mandel3danim2a.gif

Here's my most recent render, a stereo pair using 500³ voxels.

Post a reply to this message

Attachments:
Download 'mandelbulbg9rls90.jpg' (149 KB)

Preview of image 'mandelbulbg9rls90.jpg'

"waggy" <hon### [at] handbasketorg> wrote:

> I modified the (illegal, but still renders) recursive function formulation
> posted by Warp and managed to get a straight SDL isosurface.  This is the result
> of six iterations.  The render time isn't too terribly bad if you can find a
> good combination of accuracy and max_gradient.  Due to the object's fractal
> nature, the reported maximum gradient doesn't help, though.

So is this a function that you have defined within povray for the isosurface or
are you using a df3 file?

Instead of fiddling with user-definable functions within povray I added a new
function to povray's fnintern.cpp which allowed me to render mandelbulbs with
povray.

The patch:
http://softwareprocess.es/x/x/mandelbulb/fnintern.cpp.patch

How I call it:
http://softwareprocess.es/x/x/mandelbulb/mandelbulb.pov

And a description of how I got here:
http://softwareprocess.us/index.cgi/Mandelbulb

I really think the functional approach is superior to the voxel approach since
getting 1000x1000x1000 voxels is time consuming and space consuming.

But if you did define your own function in isosurface I'd love to see it.

abram

Post a reply to this message

Attachments:
Download '1povaa.640480.png' (182 KB)

Preview of image '1povaa.640480.png'

abram wrote:
> So is this a function that you have defined within povray for the isosurface or
> are you using a df3 file?
> 
> Instead of fiddling with user-definable functions within povray I added a new
> function to povray's fnintern.cpp which allowed me to render mandelbulbs with
> povray.
> 
> The patch:
> http://softwareprocess.es/x/x/mandelbulb/fnintern.cpp.patch
> 
> How I call it:
> http://softwareprocess.es/x/x/mandelbulb/mandelbulb.pov
> 
> And a description of how I got here:
> http://softwareprocess.us/index.cgi/Mandelbulb
> 
> I really think the functional approach is superior to the voxel approach since
> getting 1000x1000x1000 voxels is time consuming and space consuming.
> 
> But if you did define your own function in isosurface I'd love to see it.
> 
> abram
> 
> 
> ------------------------------------------------------------------------
> 
Very nice!

I was hoping that someone would take that approach, I looked into the 
source but didn't understand it quite well enough to make my own patch.

On that note, I wonder if it would be feasible to add some sort of 
user-defined recursive function to the fractal class (z=z^n+c for this, 
but replace that ^n part with whatever you want), much like 
julia_fractal takes the function name as a parameter. It would make POV 
into a very usable fractal generator, since the raytracing side of it is 
so well defined already, and most of the other fractal tracers are 
homebrew contraptions that are struggling to get good shading but have 
the math down.

Post a reply to this message

PM 2Ring wrote:
> How do you turn a df3 density file into a mesh?

  You don't turn a df3 density file into a mesh. You calculate a mesh
from the original fractal.

  (Granted, it's not a trivial task, requiring using something like the
marching triangles algorithm, but still beneficial in terms of rendering
speed.)

Post a reply to this message

abram schrieb:

> Instead of fiddling with user-definable functions within povray I added a new
> function to povray's fnintern.cpp which allowed me to render mandelbulbs with
> povray.

Good stuff!

However, regarding the return value, note that the "threshold" parameter 
in the isosurface statement is a /borderline/ value; with your 
implementation, the default value will cause the isosurface to misbehave 
in situations where "insideness" needs to be tested. This can easily be 
fixed by using an isosurface threshold of e.g. -0.5, but I think it 
would be more elegant to have the function return -1 and 1, respectively.

I'd also be curious whether rendering speed might be improved by 
choosing different return values, that might give POV-Ray a hint how 
close it might be to the surface. Anyone some experience with that?

Post a reply to this message

"abram" wrote:

> So is this a function that you have defined within povray for the isosurface or
> are you using a df3 file?

It's a pair of functions, one to do the iterations, and another to return a
value suitable for making an isosurface.  The plan was to add additional
functions better suited to use as a pattern, media, etc.

> Instead of fiddling with user-definable functions within povray I added a new
> function to povray's fnintern.cpp which allowed me to render mandelbulbs with
> povray.

I agree, and thanks for making the patch available.  I may take a whack at
modifying it to use  PM 2Ring's trigless algorithm.

> I really think the functional approach is superior to the voxel approach since
> getting 1000x1000x1000 voxels is time consuming and space consuming.
>
> But if you did define your own function in isosurface I'd love to see it.

OK.  I've avoided posting it since it's an illegal recursive function and can
crash 3.7.  It seems to work only when there is just one recursive function
defined, and this recursive function does not call any other user-defined
function.  There are posts to this site showing how to unroll these type of
functions using macros to make everything legal, and I may try that, as well.

However, to make a good isosurface I found it necessary to modify the return
value so it is no longer strictly a step function returning a value proportional
to just the iteration number.  It seems this is needed so the isosurface's
surface normal can be calculated correctly, and it also speeds rendering and
works with lower max_gradient and larger accuracy values.  I probably don't have
the quite the right formulation yet, but what's below works pretty well.

~David Wagner

P.S. Attached are some Easter eggs courtesy of the Basic scene template.

// Persistence of Vision Ray Tracer Scene Description File
// File: mandelbulb.inc
// Vers: 3.6.1, 3.7
// Desc: Mandelbulb Functions
// Date: 11/18/09
// Auth: David Wagner


//Making the return value a float by adding how close to the radius of
convergence REALLY helps!
//Returns 0 to mb_imax+2?  Taking off 3 seems to work best.
//This new version seems to have interior surfaces, too.

#declare mb_fn_iterator_frac = function(mb_i,mb_imax, mb_in, x,y,z,
mb_ix,mb_iy,mb_iz) {
   select(mb_i > mb_imax | pow(mb_ix,2) + pow(mb_iy,2) + pow(mb_iz,2) >4, 0,
      mb_fn_iterator_frac(mb_i+1,mb_imax, mb_in, x,y,z,

         x + pow(pow(mb_ix,2) + pow(mb_iy,2) + pow(mb_iz,2) , mb_in/2)
             * sin( atan2( sqrt(pow(mb_ix,2) + pow(mb_iy,2)), mb_iz) * mb_in)
             * cos( atan2(mb_iy,mb_ix) * mb_in),

         y + pow(pow(mb_ix,2) + pow(mb_iy,2) + pow(mb_iz,2) , mb_in/2)
             * sin( atan2( sqrt(pow(mb_ix,2) + pow(mb_iy,2)), mb_iz) * mb_in)
             * sin( atan2(mb_iy,mb_ix) * mb_in),

         z + pow(pow(mb_ix,2) + pow(mb_iy,2) + pow(mb_iz,2) , mb_in/2)
             * cos( atan2( sqrt(pow(mb_ix,2) + pow(mb_iy,2)), mb_iz) * mb_in)
         ),
      mb_i + 1/(pow(mb_ix,2) + pow(mb_iy,2) + pow(mb_iz,2) -3 )
      )//end select
   };

#declare mb_fn_iso = function(x,y,z, mb_fn_n, mb_fn_iterations) {
   ( mb_fn_iterations - mb_fn_iterator_frac(0,mb_fn_iterations-1, mb_fn_n,
x,y,z, x,y,z) -0.5 )
   / mb_fn_iterations
   };

/*
  The iteration number is negated so the inside is defined correctly.
  Taking off 0.5 here may be a mistake now that the iteration is no longer an
integer...
    but it seems to work best for isosurfaces.
*/

/*
//Use the include file as follows:

#include "mandelbulb.inc"

#local mb_n=8;           // Mandelbulb Power
#local mb_iterations=6;
#local mb_zoom=2;        // Use higher values for tighter views.

isosurface {
  function { mb_fn_iso(y, x, z, mb_n, mb_iterations) }
  threshold 0.0
  contained_by { sphere { <0,0,0>, 1.2 } } //Power 8

  //For power 8
  accuracy     pow(2,-mb_iterations  )  /32 /mb_zoom
  max_gradient pow(2, mb_iterations/2)  *32 *mb_zoom

texture{pigment{color White}}
finish{ambient 0 diffuse 0.9 phong 0.1 specular 0.0}
}
*/

Post a reply to this message

Attachments:
Download 'mb_pattern_basic_set.png' (134 KB)

Preview of image 'mb_pattern_basic_set.png'

Well, now here's an accidental isosurface at today's Astronomy Picture of the
Day.

http://antwrp.gsfc.nasa.gov/apod/ap091122.html

It kinda looks like someone hit a lower-power mandelbulb with a turbulence warp.

That inspired me to try mandelbulbs with fractional powers.  Attached is a power
2.3 mandelbulb, 20 iterations, rotated off-axis, and rendered as media.

Post a reply to this message

Attachments:
Download 'mb2-3i20_media.png' (193 KB)

Preview of image 'mb2-3i20_media.png'

waggy schrieb:

> That inspired me to try mandelbulbs with fractional powers.  Attached is a power
> 2.3 mandelbulb, 20 iterations, rotated off-axis, and rendered as media.

Tried that, too, with solids. Doesn't look too pretty though, as such 
variants exhibit a distinctive discontinuity at one side. Apparently 
you'd need more than 360 degrees in a circle to give them rotational 
symmetry...

Post a reply to this message

>> I think it would be easiest (ie not take 400 years) if you made a
>> program in a faster language (eg C++) to write a df3 file, and then used
>> POV to render the df3 file as an isosurface.
> 
>  Why does it have to be an isosurface? If you created a mesh out of it,
> it would probably render about a thousand times faster, 

But take a thousand times longer to code :-)

Post a reply to this message

abram wrote:
> The patch:
> http://softwareprocess.es/x/x/mandelbulb/fnintern.cpp.patch

Looking at it again, I can see a simple improvement that shouldn't cost 
too much computing power and would make it much more usable for pigments 
and media - returning smooth values based on rate of divergence.

No change needed on your if(cnt<=0){return -1.0;}, but what you can do 
for the other condition is:
return (cnt+log(log(r)/log(2.0))/log(n))/(iterations);

In words: find the count you got down to, and add a fraction to it that 
approximates how close it was to taking one less iteration, then 
normalizing that so it will return a range from 0 to 1+, where 0 is when 
you've reached nearly the max iterations, and 1+ when it takes only 1 
iteration to diverge, and higher than that when it diverges really far 
in the first step.
The actual formula for that fraction is log[base n](log[base 
threshold](cnt)), where your threshold for the radius is 2.0.

This would let you get smoothly colored pigment patterns if you want to 
do any rate of divergence coloring, which could be interesting. Of 
course feel free to change the range of returned values, this is just an 
idea for normalizing. To save very minor computational cost you can 
pre-calculate the log(2.0), or even change your divergence radius to E.

Chris

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> PM 2Ring wrote:
> > How do you turn a df3 density file into a mesh?
>
>   You don't turn a df3 density file into a mesh. You calculate a mesh
> from the original fractal.
>
>   (Granted, it's not a trivial task, requiring using something like the
> marching triangles algorithm, but still beneficial in terms of rendering
> speed.)

Thanks, Warp.

I found the Marching Cubes C code (cunningly disguised as C++ code...) in p.b.u.
It
converts 8 bit df3 files ok, but of course the resulting mesh isn't quite as
accurate as a POV isosurface. The mesh renders much faster, but it does take
more memory & is much slower to render. So for some applications (eg a lot of
small renders for an animation) I prefer to use the isosurface.

Maybe I need to use the df3 file more efficiently. Currently, I'm only storing 1
bit per voxel: 0 if it's not in the Mandelbulb, 255 if it is. I'm wondering if
there's a better way.


Someone mentioned earlier about doing a glass Mandelbulb. I don't know if this
would work very well, since the surface is fractally bumpy. I've done a glassy
one of a 100³ grid (ior 1.5, no dispersion, photons, or radiosity) amd a shiny
metallic one, and they both look interesting, but a metallic one of a 500³ grid
doesn't look very shiny; as you can see below, it's more like a scrunched up
ball of foil.

Post a reply to this message

Attachments:
Download 'mandelbulbi5s90.jpg' (160 KB)

Preview of image 'mandelbulbi5s90.jpg'

waggy wrote:
> That inspired me to try mandelbulbs with fractional powers.  Attached is a power
> 2.3 mandelbulb, 20 iterations, rotated off-axis, and rendered as media.

  There's a skull in that image.

Post a reply to this message

PM 2Ring a écrit :
> Warp <war### [at] tagpovrayorg> wrote:
>> PM 2Ring wrote:
>>> How do you turn a df3 density file into a mesh?
>>   You don't turn a df3 density file into a mesh. You calculate a mesh
>> from the original fractal.
>>
>>   (Granted, it's not a trivial task, requiring using something like the
>> marching triangles algorithm, but still beneficial in terms of rendering
>> speed.)
> 
> Thanks, Warp.
> 
> I found the Marching Cubes C code (cunningly disguised as C++ code...) in p.b.u.
> It
> converts 8 bit df3 files ok, but of course the resulting mesh isn't quite as
> accurate as a POV isosurface. The mesh renders much faster, but it does take
> more memory & is much slower to render. So for some applications (eg a lot of
> small renders for an animation) I prefer to use the isosurface.
> 
> Maybe I need to use the df3 file more efficiently. Currently, I'm only storing 1
> bit per voxel: 0 if it's not in the Mandelbulb, 255 if it is. I'm wondering if
> there's a better way.
> 
> 
> Someone mentioned earlier about doing a glass Mandelbulb. I don't know if this
> would work very well, since the surface is fractally bumpy. I've done a glassy
> one of a 100³ grid (ior 1.5, no dispersion, photons, or radiosity) amd a shiny
> metallic one, and they both look interesting, but a metallic one of a 500³ grid
> doesn't look very shiny; as you can see below, it's more like a scrunched up
> ball of foil.
> 
> 
> 
> ------------------------------------------------------------------------
> 
If you want to make it glass or metallic, you need to change a few 
things for the DF3 way:
Outside value: 16
Inside value: 200
This is to get rid of the overshot artefacts you can get with the 
interpolation. Interpolate 2 realy don't work well when you have sharp 
jumps to zero and 255.

Use interpolate 2
Gives you a nice smooth, curvy, interpolation.




Alain

Post a reply to this message

PM 2Ring wrote:
> Someone mentioned earlier about doing a glass Mandelbulb. I don't know if this
> would work very well, since the surface is fractally bumpy. I've done a glassy
> one of a 100³ grid (ior 1.5, no dispersion, photons, or radiosity) amd a shiny
> metallic one, and they both look interesting, but a metallic one of a 500³ grid
> doesn't look very shiny; as you can see below, it's more like a scrunched up
> ball of foil.

Goodness!  Who let a mathematician into the Brillo factory?

--
Tim Cook
http://empyrean.freesitespace.net

Post a reply to this message

Warp wrote:
>   There's a skull in that image.

These things can look weirdly organic, especially when rendered in media.
Attached is "side" view of a power 2, iteration 20 image.

Oh, for those who don't watch the binaries.animations newsgroup, I posted an
animation of mandelbulb powers 1 through 100 rendered in media.

http://news.povray.org/povray.binaries.animations/message/%3Cweb.4b09e469315ec22ef99d05c80%40news.povray.org%3E/#%3Cweb
.4b09e469315ec22ef99d05c80%40news.povray.org%3E

(Just remove the .dat extension and it should play on MS, Mac, and Linux
systems.)

Post a reply to this message

Attachments:
Download 'mb2i20_media_1024.png' (428 KB)

Preview of image 'mb2i20_media_1024.png'

"PM 2Ring" wrote:
> Someone mentioned earlier about doing a glass Mandelbulb. I don't know if this
> would work very well, since the surface is fractally bumpy. I've done a glassy
> one of a 100³ grid (ior 1.5, no dispersion, photons, or radiosity) amd a shiny
> metallic one, and they both look interesting, but a metallic one of a 500³ grid
> doesn't look very shiny; as you can see below, it's more like a scrunched up
> ball of foil.

I found the same thing.  However, lower iteration mandelbulbs show some promise,
especially if you just cut out part of it.  Attached are power 8, iteration 3
mandelbulbs in stock glass and chrome.  (I apologize I suck at glass.)

~David

Post a reply to this message

Attachments:
Download 'mb8i3_glass_chrome.png' (769 KB)

Preview of image 'mb8i3_glass_chrome.png'

PM 2Ring wrote:
> I found the Marching Cubes C code

  AFAIK the Marching Triangles algorithm produces meshes of much higher
quality than Marching Cubes.

  Marching Cubes tends to produce randomly-sized triangles and very thin
triangles whose size is in no way related to the shape, and it doesn't
take into account the curvature of the surface being tesselated.

  Marching Triangles, on the other hand, produces nice about
evenly-sized triangles for surfaces with the same curvature, and does so
adaptively, ie. producing smaller triangles at high curvature places and
larger triangles at low curvature places. The end result (when eg.
rendered as a wireframe) tends to look a lot more pleasing.

Post a reply to this message

Alain <aze### [at] qwertyorg> wrote:

> If you want to make it glass or metallic, you need to change a few
> things for the DF3 way:
> Outside value: 16
> Inside value: 200
> This is to get rid of the overshot artefacts you can get with the
> interpolation. Interpolate 2 realy don't work well when you have sharp
> jumps to zero and 255.
>
> Use interpolate 2
> Gives you a nice smooth, curvy, interpolation.

Thanks for the suggestion, Alain. It does look better, but it needs a much
higher max_gradient. And I noticed some strange artifacts when rendering a
simple cubical frame with interpolate 2, even though all the outer voxels in my
cube df3 are supposed to be outside the surface.

FWIW, the metallic Mandelbulb I posted was done using a mesh produced by
Marching Cubes.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> PM 2Ring wrote:
> > I found the Marching Cubes C code
>
>   AFAIK the Marching Triangles algorithm produces meshes of much higher
> quality than Marching Cubes.
>
>   Marching Cubes tends to produce randomly-sized triangles and very thin
> triangles whose size is in no way related to the shape, and it doesn't
> take into account the curvature of the surface being tesselated.
>
>   Marching Triangles, on the other hand, produces nice about
> evenly-sized triangles for surfaces with the same curvature, and does so
> adaptively, ie. producing smaller triangles at high curvature places and
> larger triangles at low curvature places. The end result (when eg.
> rendered as a wireframe) tends to look a lot more pleasing.

That sounds great, Warp. But after over an hour of searching for Marching
Triangles code, I haven't located anything yet, not even pseudocode. :( Do you
have any suggestions for where I should look? I have found some articles in PDF
format, but I haven't downloaded any of them to check if they contain source
code.

Post a reply to this message

On Sat, 28 Nov 2009 02:49:38 +0100, PM 2Ring <nomail@nomail> wrote:
>
> That sounds great, Warp. But after over an hour of searching for Marching
> Triangles code, I haven't located anything yet, not even pseudocode. :(  
> Do you have any suggestions for where I should look? I have found some
> articles in PDF format, but I haven't downloaded any of them to check if
> they contain source code.

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

The Wikipedia article links to:
http://local.wasp.uwa.edu.au/~pbourke/geometry/polygonise/#tetra



-- 
FE

Post a reply to this message

PM 2Ring a écrit :
> Alain <aze### [at] qwertyorg> wrote:
> 
>> If you want to make it glass or metallic, you need to change a few
>> things for the DF3 way:
>> Outside value: 16
>> Inside value: 200
>> This is to get rid of the overshot artefacts you can get with the
>> interpolation. Interpolate 2 realy don't work well when you have sharp
>> jumps to zero and 255.
>>
>> Use interpolate 2
>> Gives you a nice smooth, curvy, interpolation.
> 
> Thanks for the suggestion, Alain. It does look better, but it needs a much
> higher max_gradient. And I noticed some strange artifacts when rendering a
> simple cubical frame with interpolate 2, even though all the outer voxels in my
> cube df3 are supposed to be outside the surface.
> 
> FWIW, the metallic Mandelbulb I posted was done using a mesh produced by
> Marching Cubes.
> 

If the values reach zero or the highest possible value (255 for 8 bits), 
  you get overshots, and those results in warping around the resulting 
values from your density_map. If you go to zero, you get areas that will 
eroneously use the entry for 1 on the density map. If you go to 255, you 
get areas that will use the values for zero, or close to zero.

That's why I told tou to restrict the range of values used.



Alain

Post a reply to this message

"Fredrik Eriksson" <fe79}--at--{yahoo}--dot--{com> wrote:
> On Sat, 28 Nov 2009 02:49:38 +0100, PM 2Ring <nomail@nomail> wrote:
> >
> > That sounds great, Warp. But after over an hour of searching for Marching
> > Triangles code, I haven't located anything yet, not even pseudocode. :(
>
> http://en.wikipedia.org/wiki/Marching_tetrahedrons
>
> The Wikipedia article links to:
> http://local.wasp.uwa.edu.au/~pbourke/geometry/polygonise/#tetra

Thanks, Fredrik, but I've already seen those links. Marching Tetrahedrons is a
slight improvenent on Marching Cubes, but Marching Triangles appears to be quite
a different algorithm, with adaptive triangle sizes.

Post a reply to this message

Alain <aze### [at] qwertyorg> wrote:

> >> If you want to make it glass or metallic, you need to change a few
> >> things for the DF3 way:
> >> Outside value: 16
> >> Inside value: 200
> >> This is to get rid of the overshot artefacts you can get with the
> >> interpolation. Interpolate 2 realy don't work well when you have sharp
> >> jumps to zero and 255.

>
> If the values reach zero or the highest possible value (255 for 8 bits),
>   you get overshots, and those results in warping around the resulting
> values from your density_map. If you go to zero, you get areas that will
> eroneously use the entry for 1 on the density map. If you go to 255, you
> get areas that will use the values for zero, or close to zero.
>
> That's why I told you to restrict the range of values used.

I understand, Alain, and I have restricted the values: my df3 test files only
use 16 & 200 (I used tr to translate my existing files). But I still get these
artifacts. I didn't bother saving an image, but I'll generate a new one, if
you'd like to see for yourself.

Post a reply to this message

On Sat, 28 Nov 2009 03:24:08 +0100, PM 2Ring <nomail@nomail> wrote:
>
> Marching Tetrahedrons is a slight improvenent on Marching Cubes,
> but Marching Triangles appears to be quite a different algorithm,
> with adaptive triangle sizes.

Source code for that does seem to be scarce, but the original article (by  
Hilton & Illingworth) has a pretty detailed stepwise description of the  
algorithm. It should not be to difficult to work from that.



-- 
FE

Post a reply to this message

PM 2Ring wrote:
...
> That sounds great, Warp. But after over an hour of searching for Marching
> Triangles code, I haven't located anything yet, not even pseudocode. :( Do you
> have any suggestions for where I should look?
...

You can find some code in this thread:

http://news.povray.org/povray.binaries.scene-files/thread/%3C47be20ab%40news.povray.org%3E/

Subject: "Isosurface Approximation macros rewrite"	
From: Tor Olav Kristensen
Date: 22 Feb 2008 01:08:59

-- 
Tor Olav
http://subcube.com

Post a reply to this message

Tor Olav Kristensen <tor### [at] TOBEREMOVEDgmailcom> wrote:
> PM 2Ring wrote:
> ...
> > That sounds great, Warp. But after over an hour of searching for Marching
> > Triangles code, I haven't located anything yet, not even pseudocode. :( Do you
> > have any suggestions for where I should look?
> ...
>
> You can find some code in this thread:

Thanks, Tor Olav. I'll have a look at it when I wake up. :)

Post a reply to this message

PM 2Ring wrote:
> Tor Olav Kristensen <tor### [at] TOBEREMOVEDgmailcom> wrote:
>> PM 2Ring wrote:
>> ...
>>> That sounds great, Warp. But after over an hour of searching for Marching
>>> Triangles code, I haven't located anything yet, not even pseudocode. :( Do you
>>> have any suggestions for where I should look?
>> ...
>>
>> You can find some code in this thread:
> 
> Thanks, Tor Olav. I'll have a look at it when I wake up. :)

I see from your answer to Fredrik that it is not Marching Tetrahedrons you're after,
so what I linked to is probably not relevant for you.

-- 
Tor Olav
http://subcube.com

Post a reply to this message

Tor Olav Kristensen <tor### [at] TOBEREMOVEDgmailcom> wrote:
> PM 2Ring wrote:
> > Tor Olav Kristensen <tor### [at] TOBEREMOVEDgmailcom> wrote:
> >> PM 2Ring wrote:
> >> ...
> >>> That sounds great, Warp. But after over an hour of searching for Marching
> >>> Triangles code, I haven't located anything yet, not even pseudocode. :( Do you
> >>> have any suggestions for where I should look?
> >> ...
> >>
> >> You can find some code in this thread:
> >
> > Thanks, Tor Olav. I'll have a look at it when I wake up. :)
>
> I see from your answer to Fredrik that it is not Marching Tetrahedrons you're after,
> so what I linked to is probably not relevant for you.
>
> --
> Tor Olav
> http://subcube.com

That's OK. Once I had a look at the code, I realized it wasn't Marching
Triangles, but decided to try it out anyway. The meshes it produces do look
better than Marching Cubes, but of course it is very slow on large data sets,
being in POV SDL rather than C. Especially with recursion depth of 3 or more.

FWIW, in one of my tests I got an error message from POV saying that a normal
vector can't be <0,0,0>.

Post a reply to this message