Hm, neat. It's like the Borg have developed a better hierarchy

Tim Nikias wrote:

> Nice and interesting images.
>
> Your nesting problem... I don't get the problem.
>
> I did something similiar to this a while ago, I've attached the outcome...
>
> All I did was to write a macro, which divides a cube into a 3x3 Grid.
> It places a superellipsoid in the corners and then calls itself
> again with the middle-section as new cubes.
> So, recursively, the cube is divided, superellipsoids are placed, and
> we move in further and further.
> It's a pretty simple macro, but I guess something like that, along with
> some more #if-#else-#end, would do the job. Random-Stream may be
> used freely etc, just the implementation requires a little thought.
>
> I'm not sure how you did your images, what you are actually willing
> to achieve, so maybe my approach is not suitable to your project.
>
> Just my 2 cents worth...
>
> Yadgar wrote:
>
> > High!
> >
> > Several weeks ago, I posted here on a problem with primitive fractal
> > scenes. Back then, I used to build them by nesting
> > loops corresponding to their tree-like structure. But (at least with the
> > cube fractal) whenever I did this more than 4 iterations
> > deep, I got that nasty "Too many nested objects" error.
> >
> > Then the ominous K appeared on the scene... he posted an alternative
> > solution in p.b.s-f capitalizing on PoV-Ray's implicit
> > creation of objects:
> >
> > #declare cubes=
> > union
> > {
> >    object { cube}
> >    object { cube ...}
> >    object  { cube ... }
> > }
> >
> > #declare cubes=
> > union
> > {
> >     object { cube }
> >     object { cubes ... }
> >     object { cubes ... }
> > }
> >
> > and so on... each definition of "cubes" is scaled and translated in the
> > following re-definition.
> >
> > I then started to use this technique, it worked very well, but of course
> > there is the problem, that, unlike with nested loops, I'll
> > never be able to modify each single cube individually, for example by
> > using rand(). Nevertheless, K's method yielded some
> > very interesting results, which I would like to show here.
> >
> > But as realistic trees need branches and twigs which are individually
> > modifyable, I still asked myself if there are other ways to
> > get rid of the "too many nested objects" error - I just can't imagine
> > that all the many more or less sophisticated tree macros
> > use not more than 4 iterations! One way I myself found indeed - to put
> > the whole nested loop structure together in a merge
> > statement instead of a union - but then calculation becomes dead slow,
> > around 1 line every 10 minutes or so, not to mention
> > radiosity...
> >
> > A propos radiosity: can anyone give me a hint how to avoid those ugly
> > blotchy artifacts?
> >
> > See you in Khyberspace!
> >
> > Yadgar
> >
> > Now playing: Out of World (Feltman Trommelt)
> >
> >   ------------------------------------------------------------------------
> >  [Image]  [Image]  [Image]  [Image]  [Image]  [Image]  [Image]  [Image]
>
> --
> Tim Nikias
> Homepage: http://www.digitaltwilight.de/no_lights/index.html
> Email: Tim### [at] gmxde
>
>   ------------------------------------------------------------------------
>  [Image]

--
~ Samuel Benge

sbe### [at] caltelcom

Post a reply to this message