I wonder why there is only a 4D Julia fractal in Povray, but no 4D
Mandelbrot object. (No, the Mandelbrot pattern is not the same.)

I found a website where someone "hacked" it via isosurface and a
recursive(!) function definition. Povray warns that that is not allowed,
but … it renders the scene properly, albeit veeeerrryyy slowly.

Here is the result (after >5h 30 min render time on my MacBook, due to
Anti-aliasing) which looks pretty awesome to me.

Is it planned to add a mandelbrot object primitive to Povray someday? It
should be much faster than the isosurface.

What do you think?

		Lars R.

Post a reply to this message

Attachments:
Download 'mandelbrot-3d.jpg' (91 KB)

Preview of image 'mandelbrot-3d.jpg'

Am 26.07.2017 um 04:42 schrieb Lars R.:

> Is it planned to add a mandelbrot object primitive to Povray someday? It
> should be much faster than the isosurface.

There is currently no such plan. That doesn't mean it wont't happen, but
the dev team's efforts are directed elsewhere, so somebody else would
probably have to pick up that glove.

Post a reply to this message

Le 26/07/2017 à 16:15, clipka a écrit :
> Am 26.07.2017 um 04:42 schrieb Lars R.:
> 
>> Is it planned to add a mandelbrot object primitive to Povray someday? It
>> should be much faster than the isosurface.
> 
> There is currently no such plan. That doesn't mean it wont't happen, but
> the dev team's efforts are directed elsewhere, so somebody else would
> probably have to pick up that glove.
> 
And it might help to provide the actual page(s) you used, as well as
some simple scene (with isosurface) to get a reference of parameters.

Mandelbrot & Julia are tricky beasts, there are a some interesting spots
surrounded by a lot of empty or trivial ranges. It's not like debugging
a cylinder.

Post a reply to this message

Okay, here is the 2nd scene I rendered in 9h 54min. :-o

I've added the povray scene file, too.

And I got the formula and the stub of the scene file from this website:

http://bugman123.com/Hypercomplex/

I copied the code from this chapter:

"Here is some inefficient code demonstrating how you can render this
isosurface in POV-Ray using recursive functions:
// runtime: 4.5 minutes
camera{location <-2.5,5,5> look_at <-0.5,0,0.25> up z sky z angle 25}
light_source{20*z,1}
#declare f=function(i,x,y,z,xc,yc,zc) {select(i>0 & x*x+y*y+z*z<4, 0,
sqrt(x*x+y*y+z*z),
f(i-1,(x*x-y*y)*(1-z*z/(x*x+y*y))+xc,2*x*y*(1-z*z/(x*x+y*y))+yc,-2*z*sqrt(x*x+y*y)+zc,xc,yc,zc))};
isosurface{function{f(24,x,y,z,x,y,z)} threshold 2 max_gradient 10
contained_by{sphere{<-0.5,0,0>,2}} pigment{rgb 1}}"


For the 2nd image I changed the iteration level down to 13, it is still
a quite "jagged" object. :-)

L.

Post a reply to this message

Attachments:
Download 'hi-res-mandelbrot3d.jpg' (117 KB) Download '3df.pov.txt' (1 KB)

Preview of image 'hi-res-mandelbrot3d.jpg'

I forgot to mention how I got attention to these types of fractals:

https://youtu.be/c-K4Lk98m38  "Fractal 3D - Mandelbrot Quaternion"

*.*

But with 10h render time per frame it is hopeless to do any animations
with it. :'-(

L.

Post a reply to this message

"Lars R." <rou### [at] gmxde> wrote:
> I forgot to mention how I got attention to these types of fractals:
>
> https://youtu.be/c-K4Lk98m38  "Fractal 3D - Mandelbrot Quaternion"
>
> *.*
>
> But with 10h render time per frame it is hopeless to do any animations
> with it. :'-(
>
> L.

Oh wow, on both counts! I always thought of Julia Fractal as driftwood or dead
tree stumps, and I sure didn't think Mandelbrot could be anything except 2D
slices.
Guess I don't get out much... or is that in?

Bob

Post a reply to this message

I'd probably make sure you're optimizing your speed as described in the docs on
isosurfaces (max gradient)

I'd keep the accuracy low for tests to boost the speed.
You may also consider buying something with 12 or more cores so that you can do
multithread renders and really cut down the render time.
You might even consider distributing renders on servers or something.

and also consider using:
http://www.econym.demon.co.uk/isotut/approx.htm



For best performance you should specify a value close to the real maximum
gradient.
evaluate POV-Ray can also dynamically adapt the used max_gradient. To activate
this technique you have to specify the evaluate keyword followed by three
parameters:
  P0: the minimum max_gradient in the estimation process,
  P1: an over-estimating factor. This means that the max_gradient is multiplied
by the P1 parameter.
  P2: an attenuation parameter (1 or less)
In this case POV-Ray starts with the max_gradient value P0 and dynamically
changes it during the render using P1 and P2. In the evaluation process, the P1
and P2 parameters are used in quadratic functions. This means that
over-estimation increases more rapidly with higher values and attenuation more
rapidly with lower values. Also with dynamic max_gradient, there can be
artefacts and holes.
If you are unsure what values to use, start a render without evaluate to get a
value for max_gradient. Now you can use it with evaluate like this:
P0 : found max_gradient * min_factor
'min_factor' being a float between 0 and 1 to reduce the max_gradient to a
'minimum max_gradient'. The ideal value for P0 would be the average of the found
max_gradients, but we do not have access to that information.
A good starting point is 0.6 for the min_factor
P1 : sqrt(found max_gradient/(found max_gradient * min_factor))
'min_factor' being the same as used in P0 this will give an over-estimation
factor of more than 1, based on your minimum max_gradient and the found
max_gradient.
P2 : 1 or less
0.7 is a good starting point.
When there are artifacts / holes in the isosurface, increase the min_factor and
/ or P2 a bit. Example: when the first run gives a found max_gradient of 356,
start with
  #declare Min_factor= 0.6;
  isosurface {
     ...
     evaluate 356*Min_factor,  sqrt(356/(356*Min_factor)),  0.7
     //evaluate 213.6, 1.29, 0.7
     ...
   }
This method is only an approximation of what happens internally, but it gives
faster rendering speeds with the majority of isosurfaces.

Post a reply to this message

Am 27.07.2017 um 13:59 schrieb Bald Eagle:
> I'd probably make sure you're optimizing your speed as described in the docs on
> isosurfaces (max gradient)

Captain Obvious? Is it you?

Beleave me, the max_gradient is >9000, and povray complains when I set a
lower value. That's why I switched to the "evaluate" method, as
described on the Povray website that you copied unecessarily.

The render time differences are neglible.

> I'd keep the accuracy low for tests to boost the speed.

Unfortunately neither you nor the Povray website gave me usable hints
which values might be sensible or how the "accuracy" value influences
the visual output of the rendering at all. :-(

> You may also consider buying something with 12 or more cores so that you can do
> multithread renders and really cut down the render time.

If you give me the money we can talk about that, sure.

> You might even consider distributing renders on servers or something.

Do you have a ready-to-use software for that? (for Linux & Mac)

L.

Post a reply to this message

hi,

On 28/07/2017 08:58, Lars R. wrote:
> Am 27.07.2017 um 13:59 schrieb Bald Eagle:
>> You might even consider distributing renders on servers or something.
> 
> Do you have a ready-to-use software for that? (for Linux & Mac)


have a look at http://www.southampton.ac.uk/~sjc/raspberrypi/ as an
example.  I'm pretty sure that you can use machines other than
Raspberries to work as nodes.  from there it'd be just a couple of shell
scripts to orchestrate the distributed render.

hth, jr.

Post a reply to this message

"Lars R." <rou### [at] gmxde> wrote:

> Captain Obvious? Is it you?

You have --- unmasked me.   :O
Now that my true identity is known, I will probably have to resort to getting a
job on Hotels.Com or something...

> Unfortunately neither you nor the Povray website gave me usable hints
> which values might be sensible or how the "accuracy" value influences
> the visual output of the rendering at all. :-(

I've played with it a little in the past, and it seems mostly to affect the
smoothness of the surface.  I'm not sure what the actual mechanism is, but I
find it a useful fiction to envision it as a sort of subdivision of the curve -
large values are rough/blocky, and small values are very smooth.


> If you give me the money we can talk about that, sure.

I only suggest it since I see what gets offered for sale on Ebay, etc. and got
my friend just such a machine for a few hundred dollars.  Might not be a
worthwhile investment for static renders, but for a challenging animation, I
figured it was worth suggesting for serious consideration.
After seeing the speed increase on his machine, I myself may go that route in
the near future.

> > You might even consider distributing renders on servers or something.
>
> Do you have a ready-to-use software for that? (for Linux & Mac)

I had the impression that it wasn't that hard to do, and that as far back as a
decade or more ago, people were doing that with POV-Ray.  I just thought I'd
bring it up as a possibility, figured someone else might be able to give you
details for the implementation, and that it might be a viable solution whether I
personally know the details of how to actually do it or not.

Obviously Dick Balaska has been doing it, I have seen people offer services to
upload a .pov file to the web and have it be rendered and the graphic file be
sent back, and I figured that with all of this cloud computing, maybe there was
some analogous mechanism by which "The Cloud" could do the heavy lifting.

Sorry I didn't have a magic bullet for you.

Post a reply to this message