"makc" <mak### [at] gmailspamcom> wrote:
> "Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> > [SNIP]
> > // It can be used like this:
> > #declare MandelBulbFn = MandelBulbFunction(8, 3, 8, pi/2, 8, 5)
> >
>
> could you please make a pov file with that for all the newbies to learn from?

Ok. See the attached pov-file.
But it may not be the easiest example for new users to learn from.

Note that if one want to see more details at higher powers,
then this smoothing expression should probably be changed:

  1/(I - ln(ln(_r)/ln_R_BO)/ln_R_Pwr)

--
Tor Olav
http://subcube.com

Post a reply to this message

Attachments:
Download 'mandelbulb.pov.txt' (3 KB)

Tor Olav Kristensen wrote:
 > Ok. See the attached pov-file.

That is very nice, indeed, and far easier to read than my formulation. 
It probably renders faster than my recursive SDL hack, too.

A few quick renders seems to indicate your formula may match one of the 
bizarre "negative power" variations related to the tricorn fractal 
rather than one of the standard mandelbulb functions.  (You should still 
be able to get the "classic" mandelbulbs by messing with the phase and 
the signs of the powers.)  I don't have time right now to examine it in 
detail, but I would take a look at the use of the built-in f_ph() and 
f_th() functions; they don't correspond directly to published mandelbulb 
functions[1], nor to the conventional spherical coordinate system[2].

> But it may not be the easiest example for new users to learn from.

Plain old isosurfaces are tough for new users to tackle at all, and more 
power to those that do!

> Note that if one want to see more details at higher powers,
> then this smoothing expression should probably be changed:
> 
>   1/(I - ln(ln(_r)/ln_R_BO)/ln_R_Pwr)

Can you explain what you mean here, or post an example?

The smoothing function should not smooth the surface itself, it should 
just decrease the actual max_gradient of the function and make it easier 
for the root solver to find the surface.  To get to higher iteration 
surfaces, lower the isosurface threshold to a value closer to zero (from 
1/2 as it is now to 1/3, 1/4, and so on to get more and more fractal 
detail.)

~David

[1]
http://www.skytopia.com/project/fractal/2mandelbulb.html#formula

[2] 
http://en.wikipedia.org/wiki/Spherical_coordinate_system#Coordinate_system_conversions

Post a reply to this message

I messed with the f_mandelbulb internal function, squeezed about 10-15% better
performance out of it, and posted what I have so far below.  (Note the handy
sincos() function in the standard library saving a couple of trig calls.)

Interestingly, I also found an additional 10-15% improvement in render time by
seriously overloading the processors with one to two hundred POV-Ray worker
threads on eight cores and using smaller render block size (16 for 640*360
images).  I'm guessing the extra switching cost is more than offset by keeping
the floating-point pipelines full.

~David Wagner

DBL f_mandelbulb(FPUContext *ctx, DBL *ptr, unsigned int) // 79
{  // Coded by David Wagner, and based on
   // Daniel White's original squaring formula,
   // Paul Nylander's generalization and phi phase shift formulation,
   // the Normalized Iteration Count Algorithm,
   // and Abram Hindle's POV-Ray internal function patch.
   DBL cx=PARAM_X, cy=PARAM_Y, cz=PARAM_Z;
   DBL halfp_r   = PARAM(0);// Radial power exponent.
   DBL p_theta   = PARAM(1);// Power of elevation theta.
   DBL p_phi     = PARAM(2);// Power of azimuth phi.
   DBL phase     = PARAM(3);// Phase shift of phi.
   int i_bailout = PARAM(4);// Maximum number of iterations.
   DBL r2_bailout = pow(PARAM(5),2);// Assumed divergence radius.
   DBL x = cx, y = cy, z = cz;
   DBL r2 = x*x + y*y + z*z;
   DBL rp, sinpphi, cospphi, sinptheta, cosptheta;
   int i=1;
   halfp_r*=0.5;
   while(i < i_bailout && r2 < r2_bailout) {
       ++i;
       rp = pow(r2,halfp_r);
       sincos(p_phi * atan2(z,sqrt(x*x + y*y)) + phase, &sinpphi, &cospphi);
       sincos(p_theta * atan2(y,x), &sinptheta, &cosptheta);
       z = cz + rp * sinpphi;
       x = cx + cosptheta * rp*cospphi;
       y = cy + sinptheta * rp*cospphi;
       r2 = x*x + y*y + z*z;
   }
   if (i < i_bailout) {
       return 1/( i + log(log(r2_bailout) / log(  r2))
          / (log(halfp_r)+0.693147180559945) );
   }//          ==log(2*halfp_r)
   return 1/( i + log(log(r2_bailout) / log(1+r2))
      / (log(halfp_r)+0.693147180559945) );
}

Post a reply to this message

On 06.02.10 07:40, waggy wrote:
> I messed with the f_mandelbulb internal function, squeezed about 10-15% better
> performance out of it, and posted what I have so far below.  (Note the handy
> sincos() function in the standard library saving a couple of trig calls.)

Except that it is non-standard...

	Thorsten

Post a reply to this message

On 06.02.10 07:40, waggy wrote:
> I'm guessing the extra switching cost is more than offset by keeping
> the floating-point pipelines full.

Your guess is wrong as long as you counted "cores" as the logical number of 
cores seen by the operating system - including simultaneous multi-threading 
capabilities your processor may have.

What you are most likely seeing is that your OS gives your application 
slightly higher priority as a whole if it is running more threads, either 
because it is designed to detect compute-heavy applications or because its 
internal scheduling is on a thread rather than process basis.

	Thorsten

Post a reply to this message

Thorsten Froehlich wrote:
> On 06.02.10 07:40, waggy wrote:
 >>[...]
>> sincos() function in the standard library saving a couple of trig calls.)
> 
> Except that it is non-standard...
> 
>     Thorsten

Ah, thanks.  It's a GNU C extension.  I'll make a note to guard its use 
with a macro, and use an alternative with other compilers.

Google does not make it easy to find anything about sincos() since it 
returns results for sin_cos (where _ is any or no character).

~David

Post a reply to this message

Thorsten Froehlich wrote:
> On 06.02.10 07:40, waggy wrote:
>> I messed with the f_mandelbulb internal function, squeezed about
>> 10-15% better
>> performance out of it, and posted what I have so far below.  (Note the
>> handy
>> sincos() function in the standard library saving a couple of trig calls.)
> 
> Except that it is non-standard...

  AFAIK it's part of the C99 standard.

Post a reply to this message

Thorsten Froehlich wrote:
> On 06.02.10 07:40, waggy wrote:
>> I'm guessing the extra switching cost is more than offset by keeping
>> the floating-point pipelines full.
> 
> Your guess is wrong as long as you counted "cores" as the logical number 
> of cores seen by the operating system - including simultaneous 
> multi-threading capabilities your processor may have.
> 
I'm counting the eight physical cores in the two quad-core AMD 2344 HE 
sockets F on the motherboard.

> What you are most likely seeing is that your OS gives your application 
> slightly higher priority as a whole if it is running more threads, 
> either because it is designed to detect compute-heavy applications or 
> because its internal scheduling is on a thread rather than process basis.
> 
Interesting.  This is a on recent install of Ubuntu 9.10 Server Edition 
with their "server" kernel.  I'll do some better timing tests after I 
set up another one of these boards headless.

~David

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Thorsten Froehlich wrote:
> > On 06.02.10 07:40, waggy wrote:
> >> I messed with the f_mandelbulb internal function, squeezed about
> >> 10-15% better
> >> performance out of it, and posted what I have so far below.  (Note the
> >> handy
> >> sincos() function in the standard library saving a couple of trig calls.)
> >
> > Except that it is non-standard...
>
>   AFAIK it's part of the C99 standard.

So far as I can find, Gnu[1], Intel, HP[2], and Sun[3] include sincos() in libm
for C99.  It may take a bit more digging to sort out what compiler flags (if
any) are needed to use it with each of these.  I haven't found an answer for
Apple.

~David

[1] http://linux.die.net/man/3/sincos
[2] http://docs.hp.com/en/5992-2854/ch09s12.html
[3] http://docs.sun.com/app/docs/doc/816-5172/sincos-3m?a=view

Post a reply to this message

waggy wrote:
> So far as I can find, Gnu[1], Intel, HP[2], and Sun[3] include sincos() in libm
> for C99.  It may take a bit more digging to sort out what compiler flags (if
> any) are needed to use it with each of these.  I haven't found an answer for
> Apple.

  Well, at least with gcc if your program is C, then the compiler option
would be "-std=c99" (I really can't understand why that's not the
default). With C++ you could try "-std=c++0x".

Post a reply to this message