POV-Ray : Newsgroups : povray.general : For fun: FEATURE REQUEST: Sierpinski pattern. : Re: For fun: FEATURE REQUEST: Sierpinski pattern. Server Time
11 Aug 2024 03:28:10 EDT (-0400)
  Re: For fun: FEATURE REQUEST: Sierpinski pattern.  
From: John VanSickle
Date: 22 Sep 1999 22:47:12
Message: <37E9982E.1E06CF40@erols.com>
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

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