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

Attachments:
Download 'boxes0027.jpg' (39 KB) Download 'boxes0021.jpg' (31 KB) Download 'boxes0022a.jpg' (44 KB) Download 'boxes0023.jpg' (42 KB) Download 'boxes0024a.jpg' (42 KB) Download 'boxes0025.jpg' (39 KB) Download 'boxes0026a.jpg' (44 KB) Download 'boxes0020.jpg' (28 KB)

Preview of image 'boxes0027.jpg'

Preview of image 'boxes0021.jpg'

Preview of image 'boxes0022a.jpg'

Preview of image 'boxes0023.jpg'

Preview of image 'boxes0024a.jpg'

Preview of image 'boxes0025.jpg'

Preview of image 'boxes0026a.jpg'

Preview of image 'boxes0020.jpg'

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'

Thanks for an informative and useful posting.

Cheers!

Chip Shults
My robotics, space and CGI web page - http://home.cfl.rr.com/aichip

Post a reply to this message

Cool stuff! May I suggest you try your hand at a programming language to
output to pov files? I think you could save some rendering time if everthing
is calculated beforehand.

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]

--
~ Samuel Benge

sbe### [at] caltelcom

Post a reply to this message

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

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

Wow, it looks really cool, could you post the source please?

Thanks,

Mike

"Tim Nikias" <tim### [at] gmxde> wrote in message
news: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

High!

Tim Nikias schrieb:

> Nice and interesting images.
>
> Your nesting problem... I don't get the problem.

See the posted code for both algorithms in p.b.s-f. ...

>
>
> 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.

No, it isn't... as your superellipsoids don't intersect anywhere, unlike in my
scene, where always one out of eight cubes is
hidden inside the cube of the previous iteration! But on the other hand, even
when I programmed an exeption for this one
cube (i. e. not to render it at all), I still got this mean "Too many nested
objects" when trying to render more than four
iterations deep!

I also programmed a scene with spheres who did not intersect at all - and then
it was no problem to render, let's say five
iterations...

>   ------------------------------------------------------------------------
>  [Image]

You clearly ran me out... this cries for revenge!

See you in Khyberspace!

Now playing: I love the Night [The Ecstasy of Flight] (Chris de Burgh)

Post a reply to this message

Hey Yadgar
I adapted Tim Nikias' macro to your fractal, and it worked for every level i
tried it for.
I then ran a few timed tests just to see which method worked the best.
It turns out that all 3 ran for the same length of time.
The only glitch was the too many nested objects problem with your method.
Of all 3 methods, Tim's is by far the easiest to read write and maintain.

Thanks to you both, this has been quite enlightening.

K
PS
sorry for the reply to your email (oops)

"Yadgar" <yad### [at] tiscalinetde> wrote in message
news:3CEE9A5B.9E04DA73@tiscalinet.de...
> High!
>
> Tim Nikias schrieb:
>
> > Nice and interesting images.
> >
> > Your nesting problem... I don't get the problem.
>
> See the posted code for both algorithms in p.b.s-f. ...
>
> >
> >
> > 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.
>
> No, it isn't... as your superellipsoids don't intersect anywhere, unlike
in my
> scene, where always one out of eight cubes is
> hidden inside the cube of the previous iteration! But on the other hand,
even
> when I programmed an exeption for this one
> cube (i. e. not to render it at all), I still got this mean "Too many
nested
> objects" when trying to render more than four
> iterations deep!
>
> I also programmed a scene with spheres who did not intersect at all - and
then
> it was no problem to render, let's say five
> iterations...
>
>
  ------------------------------------------------------------------------
> >  [Image]
>
> You clearly ran me out... this cries for revenge!
>
> See you in Khyberspace!
>
> Now playing: I love the Night [The Ecstasy of Flight] (Chris de Burgh)
>

Post a reply to this message