POV-Ray : Newsgroups : povray.general : julia_fractal Server Time
23 Apr 2024 18:51:51 EDT (-0400)
  julia_fractal (Message 1 to 4 of 4)  
From: nested
Subject: julia_fractal
Date: 2 Nov 1999 10:06:17
Message: <381efde9@news.povray.org>
hi, i expect this has been addressed before, but i've looked around and
haven't seen it anywhere.  i'm using povray 3.1g on a windows 98 machine.
amd k6-2 366 mhz, 32 meg ram..  I've been rendering mostly quaternion julia
fractals since i got povray, and i've encountered an unpredictable bug.
sometimes a fractal will look like part of it is clipped.  this could be a
planar slice or a sort of unpredictable scoring.  when i've tried, rotating
the fractal will get rid of it.  the error in the scene i included leaves
the affected part of the fractal in what i assume is the proper shape, but
it looks like static.  the error does not appear if this specific fractal is
viewed head on.  however, i've seen it occur with no 3d rotation and a non
default 4d normal.  in this case, if the camera is rotated around the
fractal instead, or if the fractal is expressed as the intersection between
the fractal and a larger sphere and is then rotated, the error still occurs.
i was shooting in the dark for solutions.
  does anyone know if there are any patches that fix this, or if there are
any quick and dirty ways to get around it in pov?  has this bug been brought
up before?  i want to make animations that involve rotation, so this could
be hard to workaround, and sometimes, i prefer a certain angle just because
it looks better, and can't get it.  i think pov is incredibly powerful, and
can't get enough of how easy it is to create with
it.  with all of that promise, this is a little frustrating.

here's the code.

camera{
  location <0,0,-2.3>
}

light_source{
  <0,0,-2.3>
  color rgb 1
}

julia_fractal{ 
  <-1.154166666666666, -0.25, 0, 0>
  max_iteration 10 
  quaternion
  sqr   
  precision 2000
  pigment{rgb <1,.3,.3>}
  rotate<0,80,0>
} 

thanks.
Michael.


Post a reply to this message

From: Peter Popov
Subject: Re: julia_fractal
Date: 2 Nov 1999 15:32:28
Message: <=yEfOFqk2A9ILLBsj92bE2FnI31t@4ax.com>
The camera or the end of the direction vector is inside the bounding
sphere of the fractal. Modify your camera statement to:

camera { location -5*z angle 30 }

and it works. Also, precision 2000 is overkill, I have rarely needed
more than 100. Be warned that at iteration levels above 6 you should
expect a lot of fractal dust. Lastly, I suggest giving the julia a
no_shadow statement for test renders because you can make out the
shape better this way and it's also faster.

Enjoy!

BTW have you been able to grasp how the different parameters, more
precisely the two vectors, affect the shape of the fractal?


Peter Popov
ICQ: 15002700


Post a reply to this message

From: nested
Subject: Re: julia_fractal
Date: 3 Nov 1999 09:59:06
Message: <38204dba@news.povray.org>
>The camera or the end of the direction vector is inside the bounding
>sphere of the fractal. Modify your camera statement to:
>
>camera { location -5*z angle 30 }

well, my reply got lengthy, so i'm putting the the modified scene at the
top.  i moved the camera farther back than (i would think) any bouding
sphere would go, and brought the light back too, just in case.  it still
gives me strange noise on my machine.


camera{
  location -20*z
  angle 6
}

light_source{
  <-5,0,-20>
  color rgb 1.3
}

julia_fractal{ 
  <-1.154166666666666, -0.25, 0, 0>
  max_iteration 10 
  quaternion
  sqr   
  precision 100
  pigment{rgb <1,.3,.3>}
  rotate<0,80,0>
}




>Also, precision 2000 is overkill, I have rarely needed
>more than 100.

  i was rendering this one zoomed in at 20 iterations before so i needed the accuracy
then; i didn't bother to change the precision because it doesn't seem to affect
perfomance - i toned it down in the scene i included this time though.  you'd be
amazed how a low accuracy looks if the set animated.  it may seem just fine in a
still, but the striation is painfully obvious once it starts to move.

> Be warned that at iteration levels above 6 you should
>expect a lot of fractal dust.

i tend to avoid those, i like the way a more contiguous shape looks.

>Lastly, I suggest giving the julia a
>no_shadow statement for test renders because you can make out the
>shape better this way and it's also faster.
>
>Enjoy!
>

thanks, i'll keep that in mind. - some of my test renders are deathly slow.  keep this
with shadows though, it makes the error easier to see.  (also why i offset the light
source.)

>BTW have you been able to grasp how the different parameters, more
>precisely the two vectors, affect the shape of the fractal?
>

  a bit - if you keep the second two values in the parameter vector at zero, the first
two give you 2d julia sets at z=0 (povspace) which are the same as regular old 2d
julia sets with the same 2 parameters.  i don't have
 a very good general feel for how changing a parameter will affect the
shape - but i found a program called quat that helps a lot.  it's a
standalone quaternion generator.  the one thing you have to remember is that
to convert the parameters over to povray, you have to use the negative of
the 1st and 3rd parameters in quat.  it's at
http://wwwcip.rus.uni-stuttgart.de/~phy11733/quat_e.html
  i've only messed with the 4d normal vector once, so i don't really have a
feel for it at all.

  does anyone know why the fourth component of the 4d normal can't be zero?

Michael


Post a reply to this message

From: Gerald K  Dobiasovsky
Subject: Re: julia_fractal
Date: 8 Nov 1999 22:14:29
Message: <38279195@news.povray.org>
nested <nes### [at] hotmailcom> wrote:

[snip]

>   does anyone know why the fourth component of the 4d normal can't be
zero?
>
> Michael


It's completely analogous to 3d with a plane positioned somewhere
and two coordinates (i.e. x and y) of a point on the plane given,
looking for the value of the third (z).

Distance of slice from origin:                 D

Normal to the slice in 4-space:               N = < Nx, Ny, Nz, Nw >
(is of unit length after parsing)

Point on surface of  fractal in 4-space:    P = < x, y, z, w >
(x, y, z are known; w is unknown)


For the point in 4d to be an element of the slice subspace
the vectors have to satisfy the equation:

P*N = D   --->   x*Nx + y*Ny + z*Nz + w*Nw = D,

and

w = (D - x*Nx - y*Ny - z*Nz) / Nw

That's why Nw can't be zero...

Sorry for the late answer ( I hope it's not overlooked )

Gerald
ger### [at] aonat


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.