>   Since fractals seem to be the theme nowadays, here's my shot at it.
> 
>   There's quite a developement history behind this image.
> 
>   The basic idea was this: What if you take a julia fractal and then
> extrude it (a bit like a prism), but while you extrude it, change
> the complex number from which the julia is being calculated? That is,
> different layers of the prism are composed of julia fractals with
> slightly modified values.
> 
>   Allright, so take the julia fractal for example for <0.353, 0.288>
> and extrude it by half a unit so that at the other end it is the
> julia for <0.353+0.25, 0.288>. 10 iterations should be ok.

Sounds rather like FractInt's "Julibrot" type. Lots of normal 2D Julia 
sets, layered one on top of the other to create a 3D form. (Or, but it 
another way, taking the 4D space defined by the set of all possible z0 
and c and taking a 3D slice out of it.)

http://spanky.fractint.org/www/fractint/juliabrot_type.html

>   How exactly to implement this was in no way trivial.
> 
>   My first thought was to make an isosurface using the julia fractal
> pattern as a function. So far so good, but pattern functions can't take
> parameters, so it can't be done like that.
> 
>   So I had to actually make the julia fractal function, in other words
> a recursive function myself (it's slower, of course, but works).
> 
>   I got the isosurface to work, but it had one problem: Not accurate
> enough. The surface was full of noise. I had to lower the accuracy
> by two orders of magnitude in order to get a smooth surface, but at
> the cost of a ridiculously high max_gradient (over 20000). Not good.
> 
>   So I settled on a compromise: accuracy 1e-4, max_gradient 2000.
> It still had some noise, but not as much. Bearable.
> 
>   However, it was still not good: After 1.5 hours of rendering the
> final version and when only about 10% was ready (and it was only
> slowing down) I decided that it's ridiculously slow.
> 
>   So back to the thinking board.

I had similar problems with my cubic Mandelbrot slices. I found that 
inserting max(fn(...), 8) ment I could lower the max_gradient 
*significantly* with no change to the image. In effect, the function is 
steepest at the point most distant from the surface. (It's not 
shallowest at the surface - slightly inside it actually. But it gets 
steeper as you move away.)

Champing the top of the function to a small maximum value means that big 
areas of empty space get sampled at the minimum density (because the 
max_gradiant tells POV-Ray it would take ages for the function to decay 
far enough to reach zero). Or at least, that's my theory......

I also tried taking the logarithm - but that afforded no notable change 
in speed. I hypothesise that the extra time to compute the logarithm 
destroys any benefit in less sampling of the function.

The other thing I've tried before is spliting space into a zillion tiny 
cubes, and using some parse-time stuff to figure out which of those 
cubes actually have some surface inside them. Then I have POV-Ray only 
bother rendering those. Of course, this isn't quick either... (And prone 
to cubes being "missed". I think I had a bug somewhere!)

Post a reply to this message