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
26 Sep 2024 17:46:12 EDT (-0400)
  Re: Cube fractals again: traditional method vs. K's union method (8 x JPG 800 x 600, 304 KB)  
From: GrimDude
Date: 20 May 2002 22:52:05
Message: <3ce9b655@news.povray.org>
The fifth iteration will create a huge hit on parse time, and render
time ten times that.

Applying textures to individual elements will slow it down even more.

Grim
"Yadgar" <yad### [at] tiscalinetde> wrote in message
news:3CE93452.5EF5F5E2@tiscalinet.de...
> 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)
>


------------------------------------------------------------------------
--------






------------------------------------------------------------------------
--------






------------------------------------------------------------------------
--------






------------------------------------------------------------------------
--------






------------------------------------------------------------------------
--------






------------------------------------------------------------------------
--------






------------------------------------------------------------------------
--------






------------------------------------------------------------------------
--------


Post a reply to this message

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