POV-Ray : Newsgroups : povray.binaries.images : Cube fractals again: traditional method vs. K's union method (8 x JPG 800 x 600, 304 KB) : Re: Cube fractals again: traditional method vs. K's union method (8 x JPG 800 x 600, 304 KB) Server Time
15 Aug 2024 16:28:45 EDT (-0400)
  Re: Cube fractals again: traditional method vs. K's union method (8 x JPG 800 x 600, 304 KB)  
From: Tim Nikias
Date: 20 May 2002 14:21:16
Message: <3CE93E77.5BD31E8A@gmx.de>
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


Post a reply to this message


Attachments:
Download 'recurse3.jpg' (79 KB)

Preview of image 'recurse3.jpg'
recurse3.jpg


 

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