Why can't we implement a Sierpinski pattern in povray?

As I understand povray, for some of the more mathematically complicated
thingies,  such as isosurfaces of complex equations and the bozo or
Mandelbrot patterns,  the complexity of the feature depends on the
density of rays hitting it.  For example, the computer doesn't have
stored the "entire" Mandelbrot set at all magnifications, but merely
calculates the pattern at the place where a traced ray hits the object.
Thus, there are few practical limits to zooming in (reducing camera
angle) to see smaller and smaller regions of the Mandelbrot pattern.  Am
I right so far?

It's pretty hard for me to construct a Sierpinski object beyond a half
dozen orders of scale. Isn't this just another mathematically
complicated thingy that povray can solve procedurally?

So why can't we put a Sierpinski pattern in povray?

Post a reply to this message

Greg M. Johnson <gre### [at] my-dejanewscom> wrote in message
news:37E2407B.F551ABC8@my-dejanews.com...
> Why can't we implement a Sierpinski pattern in povray?
>
> As I understand povray, for some of the more mathematically complicated
> thingies,  such as isosurfaces of complex equations and the bozo or
> Mandelbrot patterns,  the complexity of the feature depends on the
> density of rays hitting it.  For example, the computer doesn't have
> stored the "entire" Mandelbrot set at all magnifications, but merely
> calculates the pattern at the place where a traced ray hits the object.
> Thus, there are few practical limits to zooming in (reducing camera
> angle) to see smaller and smaller regions of the Mandelbrot pattern.  Am
> I right so far?
>
> It's pretty hard for me to construct a Sierpinski object beyond a half
> dozen orders of scale. Isn't this just another mathematically
> complicated thingy that povray can solve procedurally?
>
> So why can't we put a Sierpinski pattern in povray?

    Undoubtedly, it could be done. However, it could also be done as a macro
rather easily, and there are so many variuations on the Sierpinski theme
that a good macro, editable by the user, would be far more flexible.

    More to the point: how about a Julia set pattern? The Julia sets, being
more repetitious, are a better pattern for most purposes than the Mandelbrot
set. The periodic-function variants are even better for such a purpose.

    -Robert Dawson

Post a reply to this message

"Greg M. Johnson" wrote:

> So why can't we put a Sierpinski pattern in povray?

http://web2.airmail.net/~jfox/sierpcurve.htm

-- 
Ken Tyler

See my 1000+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html

Post a reply to this message

Robert Dawson wrote:

> Greg M. Johnson <gre### [at] my-dejanewscom> wrote in message
> news:37E2407B.F551ABC8@my-dejanews.com...
> > Why can't we implement a Sierpinski pattern in povray?
> >
> > As I understand povray, for some of the more mathematically complicated
> > thingies,  such as isosurfaces of complex equations and the bozo or
> > Mandelbrot patterns,  the complexity of the feature depends on the
> > density of rays hitting it.  For example, the computer doesn't have
> > stored the "entire" Mandelbrot set at all magnifications, but merely
> > calculates the pattern at the place where a traced ray hits the object.
> > Thus, there are few practical limits to zooming in (reducing camera
> > angle) to see smaller and smaller regions of the Mandelbrot pattern.  Am
> > I right so far?
> >
> > It's pretty hard for me to construct a Sierpinski object beyond a half
> > dozen orders of scale. Isn't this just another mathematically
> > complicated thingy that povray can solve procedurally?
> >
> > So why can't we put a Sierpinski pattern in povray?
>
>     Undoubtedly, it could be done. However, it could also be done as a macro
> rather easily, and there are so many variuations on the Sierpinski theme
> that a good macro, editable by the user, would be far more flexible.
>
>     More to the point: how about a Julia set pattern? The Julia sets, being
> more repetitious, are a better pattern for most purposes than the Mandelbrot
> set. The periodic-function variants are even better for such a purpose.
>
>     -Robert Dawson

Perhaps even a more generalized fractal pattern, something that would allow you
to define with some flexibility the way in which the fractal was generated.  I
think that this could have the potential to be very powerful.  It might,
however, also be very difficult to learn how to use properly.

Post a reply to this message

Kevin Wampler <kev### [at] tapestrytucsonazus> wrote in message
news:37E6FCDD.1178C254@tapestry.tucson.az.us...
>
> Perhaps even a more generalized fractal pattern, something that would
allow you
> to define with some flexibility the way in which the fractal was
generated.  I
> think that this could have the potential to be very powerful.  It might,
> however, also be very difficult to learn how to use properly.

Could be useful.  And "difficult to learn how to use properly" didn't stop
media and radiosity from being included in the program.  8-)

rc

Post a reply to this message

Robert Chaffe <rch### [at] compaqnet> wrote in message
news:37e70bb2@news.povray.org...
> Kevin Wampler <kev### [at] tapestrytucsonazus> wrote in message
> news:37E6FCDD.1178C254@tapestry.tucson.az.us...
> >
> > Perhaps even a more generalized fractal pattern, something that would
> allow you
> > to define with some flexibility the way in which the fractal was
> generated.  I
> > think that this could have the potential to be very powerful.  It might,
> > however, also be very difficult to learn how to use properly.
>
> Could be useful.  And "difficult to learn how to use properly" didn't stop
> media and radiosity from being included in the program.  8-)
>
> rc
>
>
>
How about "Fractint for povray" with the fractal engine from fractint
incorporated into pov.
Of course the fractinit team would have to agree?
Collaboration perhaps?

PB

Post a reply to this message

Paul Brown wrote in message <37e7c109@news.povray.org>...
>
>Robert Chaffe <rch### [at] compaqnet> wrote in message
>news:37e70bb2@news.povray.org...
>> Kevin Wampler <kev### [at] tapestrytucsonazus> wrote in message
>> news:37E6FCDD.1178C254@tapestry.tucson.az.us...
>> >
>> > Perhaps even a more generalized fractal pattern, something that would
>> allow you
>> > to define with some flexibility the way in which the fractal was
>> generated.  I
>> > think that this could have the potential to be very powerful.  It
might,
>> > however, also be very difficult to learn how to use properly.
>>
>> Could be useful.  And "difficult to learn how to use properly" didn't
stop
>> media and radiosity from being included in the program.  8-)
>>
>> rc
>>
>>
>>
>How about "Fractint for povray" with the fractal engine from fractint
>incorporated into pov.
>Of course the fractinit team would have to agree?
>Collaboration perhaps?


Wouldn't work.  If you look at *all* the Fractint source code, you will see
how incredibly optimized for the IBM PC it is.  Editing it to be portable
would be a nightmare.

Mark

Post a reply to this message

On Tue, 21 Sep 1999 18:35:34 +0100, "Paul Brown"
<pau### [at] pabcomfreeservecouk> wrote:

>How about "Fractint for povray" with the fractal engine from fractint
>incorporated into pov.
>Of course the fractinit team would have to agree?
>Collaboration perhaps?
>
>PB

FractInt takes the second part of its image from the fact that it uses
highly optimised integer routines written partially in 80x86
assembler. This makes its source quite unusable for intergation into
POV. Besides, the only fractals that could work as a procedural
pattern are the M and J sets (and probably the Julibrot) and all their
derivatives. All others, such as Lorenz, Pickover, Hopalong etc. use
some kind of recursive differential equations in 2D or 3D that just
can not be backtraced.

On the other hand, the basic M- and J-sets are quite simple to
implement. Using other functions such as cosh or cube is also
possible, as in the julia object. The hardest to code, but most useful
part will be a formula parser, but that part has already been done in
the isosurface patch.

It does seem like a piece of cake but of course it isn't that simple,
as in any coding task. Yet, anyone up for a challenge? :)


Peter Popov
ICQ: 15002700

Post a reply to this message

Robert Dawson wrote:
> 
> Greg M. Johnson <gre### [at] my-dejanewscom> wrote in message
> news:37E2407B.F551ABC8@my-dejanews.com...
> > Why can't we implement a Sierpinski pattern in povray?
> >
> > As I understand povray, for some of the more mathematically
> > complicated thingies,  such as isosurfaces of complex equations and
> > the bozo or Mandelbrot patterns,  the complexity of the feature
> > depends on the density of rays hitting it.  For example, the
> > computer doesn't have stored the "entire" Mandelbrot set at all
> > magnifications, but merely calculates the pattern at the place where
> > a traced ray hits the object. Thus, there are few practical limits
> > to zooming in (reducing camera  angle) to see smaller and smaller
> > regions of the Mandelbrot pattern.  Am I right so far?

Yup.

> > It's pretty hard for me to construct a Sierpinski object beyond a
> > half dozen orders of scale. Isn't this just another mathematically
> > complicated thingy that povray can solve procedurally?
> >
> > So why can't we put a Sierpinski pattern in povray?
> 
>     Undoubtedly, it could be done. However, it could also be done as a
> macro rather easily, and there are so many variuations on the
> Sierpinski theme that a good macro, editable by the user, would be far
> more flexible.

The only problem with the macro is that unless the object created is a
single mesh object, all of the objects created will take up memory.

If an object is defined with recursion in it, it allows the user to
sacrifice speed for the sake of memory.  This would allow the user to
plop a couple hundred extremely well-detailed trees into his scene.
They might not render very quickly, but going into the Swap File Tar
Pit tends to put the kibosh on rendering speed as well.  As things are,
the user who is memory-conscious can create a tree that fits into one
mesh, and make a bunch of copies of it, rotating and scaling them to
make them look different.  Three of my Rusty animations have trees,
and there are actually three different ones, scaled and rotated to give
as much variety as possible.

Regards,
John
-- 
ICQ: 46085459

Post a reply to this message

Peter Popov wrote:
> 
> On Tue, 21 Sep 1999 18:35:34 +0100, "Paul Brown"
> <pau### [at] pabcomfreeservecouk> wrote:
> 
> >How about "Fractint for povray" with the fractal engine from fractint
> >incorporated into pov.
> >Of course the fractinit team would have to agree?
> >Collaboration perhaps?
> >
> >PB
> 
> FractInt takes the second part of its image from the fact that it uses
> highly optimised integer routines written partially in 80x86
> assembler. This makes its source quite unusable for intergation into
> POV. Besides, the only fractals that could work as a procedural
> pattern are the M and J sets (and probably the Julibrot) and all their
> derivatives. All others, such as Lorenz, Pickover, Hopalong etc. use
> some kind of recursive differential equations in 2D or 3D that just
> can not be backtraced.
> 
> On the other hand, the basic M- and J-sets are quite simple to
> implement. Using other functions such as cosh or cube is also
> possible, as in the julia object. The hardest to code, but most useful
> part will be a formula parser, but that part has already been done in
> the isosurface patch.
> 
> It does seem like a piece of cake but of course it isn't that simple,
> as in any coding task. Yet, anyone up for a challenge? :)

I was thinking of a fractal object that would look something like this:

fractal {
  max_recursion_level MAX_RECURSION_LEVEL
  fractal { transform & other object modifiers }
  bottom { }
  object { transform } // other objects
  // the normal bunch of modifiers
}

The inner fractal block specifies that a copy of the fractal is to
appear, with the transforms and material that the user might specify
attached.

The bottom{} block specifies objects that appear only at the deepest
levels of recursion.

Other objects specified appear at every recursion level.

For a crude tree, the user might specify this:

fractal {
  max_recursion_level 4
  fractal { scale .3 rotate <30,  0,0> translate y }
  fractal { scale .3 rotate <30,120,0> translate y }
  fractal { scale .3 rotate <30,240,0> translate y }
  bottom { sphere { 0,.25 pigment { rgb <0,.5,0> } } }
  cylinder { 0,y,.15 pigment { rgb <.5,.25,0> } }
}

Which would produce a tree, each branch sprouting three smaller ones,
until at the ends there were leaves.

Including the main trunk, there would be 122 branches and
81 "leaves."

Now this still leaves a lot to be desired, because a natural-looking
tree requires a goodly degree of randomness.  I haven't given much
thought to the syntax.

Regards,
John
-- 
ICQ: 46085459

Post a reply to this message