Here's my latest Mandelbulb, rendered using the isosurface / df3 method.
Resolution = 800³. It uses pseudo-HDRI, with a light dome of 159 light sources,
but no radiosity: it was just too slow. This render took over 7 days on my
480MHz machine. I was hoping for a more impressive looking result, after all
that render time. Oh well.

Post a reply to this message

Attachments:
Download 'mandelbulbja0s90.jpg' (124 KB)

Preview of image 'mandelbulbja0s90.jpg'

"PM 2Ring" <nomail@nomail> schreef in bericht 
news:web.4b247f29ce81d185f4c648ed0@news.povray.org...
> Here's my latest Mandelbulb, rendered using the isosurface / df3 method.
> Resolution = 800³. It uses pseudo-HDRI, with a light dome of 159 light 
> sources,
> but no radiosity: it was just too slow. This render took over 7 days on my
> 480MHz machine. I was hoping for a more impressive looking result, after 
> all
> that render time. Oh well.

I do find it pretty impressive. Reminds me of some kind of delicate 
porcelaine vase. The absence of shadows increases that feeling. I am 
impressed by your patience too ;)

Thomas

Post a reply to this message

"Thomas de Groot" <tDOTdegroot@interDOTnlANOTHERDOTnet> wrote:

> I do find it pretty impressive. Reminds me of some kind of delicate
> porcelaine vase. The absence of shadows increases that feeling. I am
> impressed by your patience too ;)

Thanks, Thomas. I think my next Mandelbulb renders will be close-ups rather than
trying to do the whole thing. And I might compromise & use a mesh instead of the
isosurface. These complex objects take up so much memory, I couldn't really do
much else while rendering, or the machine would start using virtual memory. That
would've taken months!

Post a reply to this message

PM 2Ring wrote:
> Here's my latest Mandelbulb, rendered using the isosurface / df3 method.
> Resolution = 800³. It uses pseudo-HDRI, with a light dome of 159 light sources,
> but no radiosity: it was just too slow. This render took over 7 days on my
> 480MHz machine. I was hoping for a more impressive looking result, after all
> that render time. Oh well.
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
Nice.

Here's a 800^3 isosurface/df3, with radiosity and real HDRI, but I can't 
figure out what's wrong with my code, since the shape isn't right. It 
was supposed to be the n=8 shape from <-1.2,-1.2,-1.2> to <1.2,1.2,1.2>.

Time: 26 minutes with max_gradient 200 on a 2.6 GHz quad-core (AMD 
Phenom 9950) for the render, and somewhere around there for the 
generation on an older dual-core linux box.

Here's my c++ code for the iterations if anyone can figure out what is 
wrong, I've gone through it many times and can't figure out what's not 
right...

Chris

--------------------------------------------------------------------------
/* Iterates the formula at a given x,y,z and returns the smoothed number 
of iterations used */
float IteratePoint(double cx, double cy, double cz, double n, double 
bailout, int maxiter){
	double x=0.0,y=0.0,z=0.0;
	double r=0.0,rn=0.0,phin,thetan,sinthetan;
	for(int i=0;i<maxiter;i++){
		r=sqrt(pow(x,2)+pow(y,2)+pow(z,2));
		if(r>bailout){
			rn=pow(r,n);
			thetan=atan2(sqrt(pow(x,2)+pow(y,2)),z)*n;
			phin=atan2(y,z)*n;
			x=rn*sin(thetan)*cos(phin)+cx;
			y=rn*sin(thetan)*sin(phin)+cy;
			z=rn*cos(thetan)+cz;
			r=sqrt(pow(x,2)+pow(y,2)+pow(z,2));
			return (float)i + 1 - (log(log(r)/log(bailout)))/log(n);
		}
		rn=pow(r,n);
		thetan=atan2(sqrt(pow(x,2)+pow(y,2)),z)*n;
		phin=atan2(y,z)*n;
		x=rn*sin(thetan)*cos(phin)+cx;
		y=rn*sin(thetan)*sin(phin)+cy;
		z=rn*cos(thetan)+cz;
	}
	return (float)maxiter;
}

-------------------
and the loop part : (xs/xe are x-start, x-end values, same for y and z)
for (i=0;i<nx;i++){
	for (j=0;j<ny;j++){
	#pragma omp parallel 
shared(df3,nx,ny,nz,xs,xe,ys,ye,zs,ze,bailout,maxiter,n,i,j,chunk) 
private(k,cx,cy,cz)
	{
		#pragma omp for schedule(dynamic,chunk) nowait
		for (k=0;k<nz;k++){
			cx = (((double)i+0.5)/(double)nx)*(xe-xs)+xs;
			cy = (((double)j+0.5)/(double)ny)*(ye-ys)+ys;
			cz = (((double)k+0.5)/(double)nz)*(ze-zs)+zs;
			df3[i][j][k]=IteratePoint(cx,cy,cz,n,bailout,maxiter);
		}
	}
	if(j%2==0)
		ShowStatus(i*nx+j,nx*ny,"Iterating Fractal: ");
	}
}

Post a reply to this message

Attachments:
Download 'mandel_df3.jpg' (69 KB)

Preview of image 'mandel_df3.jpg'

CShake wrote:
[...]
>  return (float)i + 1 - (log(log(r)/log(bailout)))/log(n);
[...]

You're return value may be a bit off.  The function log(r)/log(bailout) is the
base bailout logarithm of r,* which may not be what you intended.  The usual
formulation of this part is the (base n log of the natural log of the bailout)
minus (the base n log of natural log of the radius), where n is the power of the
mandelbulb.  This can then be simplified a little.

  return (float)i + 1 - ( log(log(bailout))-log(log(r)) )/log(n)
//then
  return (float)i + 1 - log(log(bailout)/log(r)) / log(n)

(Somebody check my math, please.  This might be simplified a bit more using the
root/log relationships...)

I don't know if this is the root of your current problem; the formulation you're
using may be just fine.  I would like to test it, since I've been monkeying with
continuous return values for the last couple of weeks, but won't be able to do
much more on this until after finals.

* http://en.wikipedia.org/wiki/Logarithms#Change_of_base

Post a reply to this message

waggy wrote:
> CShake wrote:
> [...]
>>  return (float)i + 1 - (log(log(r)/log(bailout)))/log(n);
> [...]
> 
> You're return value may be a bit off.  The function log(r)/log(bailout) is the
> base bailout logarithm of r,* which may not be what you intended.  The usual
> formulation of this part is the (base n log of the natural log of the bailout)
> minus (the base n log of natural log of the radius), where n is the power of the
> mandelbulb.  This can then be simplified a little.
> 
>   return (float)i + 1 - ( log(log(bailout))-log(log(r)) )/log(n)
> //then
>   return (float)i + 1 - log(log(bailout)/log(r)) / log(n)

I spent a bit of time on that problem too, and ended up with my equation 
based on the Escape Time Algorithm as presented at: 
http://en.wikipedia.org/wiki/Mandelbrot_set#Continuous_.28smooth.29_coloring

Unless I'm reading it wrong, that formula is effectively ( i - log[base 
N](log[base bailout](r))), which is what I'm using. I assumed that in 
the formula on wiki that the inner log (hardcoded as base 2) is actually 
base 'bailout', where most formulations of the mandelbrot equation use 2 
as the bailout value. The Zn value is stated as the value after n 
iterations, which in this case is r. Either I interpreted that equation 
wrong, or I'm erroneous in applying the '2d' equation in '3d'.

However, I don't think that's the problem in my equations, since I still 
get the same basic shape if I return 'i' instead of the 'smooth' 
coloring. Also, I wouldn't expect it to completely remove some of the 
features if I got this part of it wrong.

Chris

(I'm also between class and finals, this is how I'm procrastinating 
instead of studying and grading a pile of lab reports... )

Post a reply to this message

CShake wrote:
> I spent a bit of time on that problem too, and ended up with my equation 
> based on the Escape Time Algorithm as presented at: 
> http://en.wikipedia.org/wiki/Mandelbrot_set#Continuous_.28smooth.29_coloring 

I'm an idiot, please note that I mean 'Normalized Iteration Count 
Algorithm' instead of Escape Time in that sentence.

Post a reply to this message

CShake wrote:
[...]
>    phin=atan2(y,z)*n;
[...]
>   phin=atan2(y,z)*n;
[...]

Hmm.  Perhaps these have a small error?  I think maybe they should be like this.

   phin=atan2(y,x)*n;

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

Also, I used the same starting point, then grabbed one of the wikipedia
references and read some more.  (I also think I found a small improvement and
plan to write it up over the break.)

Post a reply to this message

"PM 2Ring" wrote:
> Here's my latest Mandelbulb, rendered using the isosurface / df3 method.
> Resolution = 800³. It uses pseudo-HDRI, with a light dome of 159 light sources,
> but no radiosity: it was just too slow. This render took over 7 days on my
> 480MHz machine. I was hoping for a more impressive looking result, after all
> that render time. Oh well.

I like your color scheme, and also find the surface can have a nice, porcelain
look with the right finish.

Did you leave Jitter on?  Jitter on is the default, but I've found using -J
helps reduce "smearing" and "fuzzing" in the final image.

Post a reply to this message

waggy wrote:
> CShake wrote:
> [...]
>>    phin=atan2(y,z)*n;
> [...]
>>   phin=atan2(y,z)*n;
> [...]
> 
> Hmm.  Perhaps these have a small error?  I think maybe they should be like this.
> 
>    phin=atan2(y,x)*n;
> 
> http://www.skytopia.com/project/fractal/2mandelbulb.html#formula
> 
> Also, I used the same starting point, then grabbed one of the wikipedia
> references and read some more.  (I also think I found a small improvement and
> plan to write it up over the break.)
> 
Right you are, once again one character causes all the problem... Thanks!

That fixed code takes a bit longer to run, but all told this image took 
less than an hour, 800^3, n=8.0, radiosity, and the media halo uses the 
same df3 (you can see how the smooth scaling works). This isosurface was 
created by using function{0.06 - df3_func(x,y,z)}, the 0.06 part can 
then be tuned to make the surface 'grow'.

Now I wonder if it's worth doubling the integer size in the df3 to 
remove some of the grain.

Post a reply to this message

Attachments:
Download 'mandelbulb_df3.jpg' (79 KB)

Preview of image 'mandelbulb_df3.jpg'

PM 2Ring wrote:
> but no radiosity: it was just too slow. This render took over 7 days on my
> 480MHz machine. I was hoping for a more impressive looking result, after all
> that render time. Oh well.

I haven't used any raytracing software for years, but am wondering how 
much do the modern machines change the rendering times with something 
like this? for instance, i am currently using a quad-core 2.00 ghz 
machine with lots of ram. obviously, the quad-core would be faster, but 
by how much?

zutroi

Post a reply to this message

zutroi wrote:
> PM 2Ring wrote:
>> but no radiosity: it was just too slow. This render took over 7 days 
>> on my
>> 480MHz machine. I was hoping for a more impressive looking result, 
>> after all
>> that render time. Oh well.
> 
> I haven't used any raytracing software for years, but am wondering how 
> much do the modern machines change the rendering times with something 
> like this? for instance, i am currently using a quad-core 2.00 ghz 
> machine with lots of ram. obviously, the quad-core would be faster, but 
> by how much?
> 
> zutroi

Not only are current CPUs running faster clock speeds than old ones, but 
they tend to do more per clock cycle too.

My quad-core Q6600 (overclocked from 2.4GHz to 3.2GHz) really shovels 
through renders. It is easily four times as fast as my old dual core 
D820. I thought that was fast when I got it!

What CPU do you have? Look it up on Tom's Hardware for an idea how fast 
it is compared with others 
(http://www.tomshardware.co.uk/charts/processors,6.html)

Remember that POVRay 3.6 only uses a single core.. to use multi-core 
CPUs you need to move up to the 3.7 beta.

Rarius

Post a reply to this message

>PM 2Ring  on date 13/12/2009 06:44 wrote:
> Here's my latest Mandelbulb, rendered using the isosurface / df3 method.
> Resolution = 800³. It uses pseudo-HDRI, with a light dome of 159 light sources,
> but no radiosity: it was just too slow. This render took over 7 days on my
> 480MHz machine. I was hoping for a more impressive looking result, after all
> that render time. Oh well.
> 
> 
I find it somehow impressive.
;-)
Paolo

Post a reply to this message

Le 2009-12-14 06:04, zutroi a écrit :
> PM 2Ring wrote:
>> but no radiosity: it was just too slow. This render took over 7 days
>> on my
>> 480MHz machine. I was hoping for a more impressive looking result,
>> after all
>> that render time. Oh well.
>
> I haven't used any raytracing software for years, but am wondering how
> much do the modern machines change the rendering times with something
> like this? for instance, i am currently using a quad-core 2.00 ghz
> machine with lots of ram. obviously, the quad-core would be faster, but
> by how much?
>
> zutroi

Taking the overhead needed when multithreading, 4 cores and 4.166 times 
the CPU speed, around 14 to 16 times faster would seems like a realist 
estimate. Can even be a LOT faster if the slower machine had to use the 
swap and you don't need to on the new one.


Alain

Post a reply to this message

"PM 2Ring" <nomail@nomail> wrote:
> Simple "Mandelbulb" C source code.
> Compile with
> gcc -o Mandelbulb Mandelbulb.c -lm -O3

Greetings all,

Here's my humble contribution. The attached archive contains a C++ program that
computes the density file for the Mandelbulb, but using the GPU through an
OpenGL shader. The OpenGL context is provided by SDL 1.3 (currently still in
beta, but already working well).
Compile with:
g++ -Wall -O3 -msse2 -o mandelbulb_gpu -lGL $($SDL13_DIR/bin/sdl-config --cflags
--libs) mandelbulb_gpu.cpp
....where $SDL13_DIR is where you installed SDL 1.3.
On my system (AMD Athlon 64 X2, nVidia 8500 GT), it computes a density file of
1000x1000x1000 in about 12 seconds (using non-trigonometric expansion provided
elsewhere).

Hope this helps.

Best regards,

Post a reply to this message

Attachments:
Download 'mandelbulb.tar.gz' (3 KB)

Kafka wrote:
> "PM 2Ring" <nomail@nomail> wrote:
>> Simple "Mandelbulb" C source code.
>> Compile with
>> gcc -o Mandelbulb Mandelbulb.c -lm -O3
> 
> Greetings all,
> 
> Here's my humble contribution. The attached archive contains a C++ program that
> computes the density file for the Mandelbulb, but using the GPU through an
> OpenGL shader. The OpenGL context is provided by SDL 1.3 (currently still in
> beta, but already working well).
> Compile with:
> g++ -Wall -O3 -msse2 -o mandelbulb_gpu -lGL $($SDL13_DIR/bin/sdl-config --cflags
> --libs) mandelbulb_gpu.cpp
> ....where $SDL13_DIR is where you installed SDL 1.3.
> On my system (AMD Athlon 64 X2, nVidia 8500 GT), it computes a density file of
> 1000x1000x1000 in about 12 seconds (using non-trigonometric expansion provided
> elsewhere).
> 
> Hope this helps.
> 
> Best regards,
> 
Nice. I wanted to play with GPGPU code, but just now finished final 
exams for the semester and didn't find the time.
Without looking at the code, I have to ask a few questions:
Can you specify where to zoom in?
Is there any noticeable difference due to using single precision, or are 
you using the double registers on the GPU directly (and using 1/10th the 
power of the card)?

While I spent a bunch of time on my mbulb df3 generator, I'm probably 
going to move on to the native function patch for the ability to 
arbitrarily transform the surface (and not need to 'render' twice for 
each image)

Post a reply to this message

CShake <cshake+pov### [at] gmailcom> wrote:
> Kafka wrote:
> > "PM 2Ring" <nomail@nomail> wrote:
> >> Simple "Mandelbulb" C source code.
> > Here's my humble contribution. The attached archive contains a C++ program that
> > computes the density file for the Mandelbulb, but using the GPU through an
> > OpenGL shader. The OpenGL context is provided by SDL 1.3 (currently still in
> > beta, but already working well).
> >
> Nice. I wanted to play with GPGPU code, but just now finished final
> exams for the semester and didn't find the time.
> Without looking at the code, I have to ask a few questions:
> Can you specify where to zoom in?

No, values (boundaries, max_iters, etc.) are hard-coded in a bunch of constants
at the beginning of the source file. But feel free to change them, or I can
modify the code so that they're given as command-line parameters.

> Is there any noticeable difference due to using single precision, or are
> you using the double registers on the GPU directly (and using 1/10th the
> power of the card)?

I can't use double with OpenCL nor GLSL, as the driver and chipset I have don't
provide that extension. From what I read here and there, using double would
reduce performances by a factor of 5 to 10. That said, most of the time is
acutally spend into writing the file: see the attached code, it displays the
mandelbulb in less than a second (not generating the .df3 file, just displaying
using the shader).

> While I spent a bunch of time on my mbulb df3 generator, I'm probably
> going to move on to the native function patch for the ability to
> arbitrarily transform the surface (and not need to 'render' twice for
> each image)

Regards,

Post a reply to this message

Attachments:
Download 'mandelbulb.tar.gz' (3 KB)

On 12/13/2009 9:40 PM, CShake wrote:

 > ...

Interesting image... the grayish protrusions remind me a bit of 
ferrofluid under the influence of a strong magnet. Cool!

-- 
~Mike

Post a reply to this message