 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I was studying, the other day, and was struck by a sudden impulse. Can POV,
I wondered, handle recursion? So I wrote the following simple scene:
/*
Persistence of Vision Ray Tracer Scene Description File
File: Recursion.pov
Vers: 3.6
Desc: A simple recursive macro
Date: 03/14/07
Auth: Anthony D. Baye
*/
#include "kolors.inc"
#include "glass.inc"
#include "stones.inc"
#include "metals.inc"
#declare ft = 12 ;
#default { pigment { White } finish { ambient 0.3 diffuse 0.5 } }
camera {
location <2.0, 3.0, -5.0>
look_at 0.0
}
light_source { <15.0, 35.0, -75.0> color rgb 1 }
#macro String_Of_Beads(n)
#if(n >= 0)
String_Of_Beads(n-1)
#end
#local move = (0.25+(0.375*n));
sphere { <cos(radians(9*n)), sin(radians(9*n)), move>, 0.125
texture { T_Stone28 }
finish { reflection { 0.05, 0.1 fresnel on } ambient 0.3 diffuse 0.5
conserve_energy }
}
cylinder { <cos(radians(9*n)), sin(radians(9*n)), move>
<cos(radians(9*(n+1))), sin(radians(9*(n+1))), (0.25+(0.375*(n+1)))>
0.015625 texture { T_Silver_5A }}
#end
String_Of_Beads(96)
It actually works, but with any values higher than 96, the parse fails,
and gives the message: "Too many nested symbol tables" whatever that
means. (I'm not familiar with the source code.)
I was wondering, however, is this an inherent limitation, or an imposed
limitation? And might it be possible to adapt the parser to allow advanced
recursion?
Just some thoughts.
Regards,
ADB
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Anthony D. Baye wrote:
> It actually works, but with any values higher than 96, the parse fails,
> and gives the message: "Too many nested symbol tables" whatever that
> means. (I'm not familiar with the source code.)
>
> I was wondering, however, is this an inherent limitation, or an imposed
> limitation? And might it be possible to adapt the parser to allow advanced
> recursion?
It should be a simple matter of changing a few variables or array sizes
in the source code, but I'm one to use POV rather than change it, so I
couldn't tell you where. You could ask in the programming group about
that :)
SDL is easily powerful enough to handle recursion, and many people here
regularly use recursive macros for scene generation.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Anthony D. Baye" <Sha### [at] spamnomore hotmailcom> wrote:
> I was studying, the other day, and was struck by a sudden impulse. Can POV,
> I wondered, handle recursion? So I wrote the following simple scene:
>
> /*
> Persistence of Vision Ray Tracer Scene Description File
> File: Recursion.pov
> Vers: 3.6
> Desc: A simple recursive macro
> Date: 03/14/07
> Auth: Anthony D. Baye
> */
>
> #include "kolors.inc"
> #include "glass.inc"
> #include "stones.inc"
> #include "metals.inc"
>
> #declare ft = 12 ;
>
> #default { pigment { White } finish { ambient 0.3 diffuse 0.5 } }
>
> camera {
> location <2.0, 3.0, -5.0>
> look_at 0.0
> }
>
> light_source { <15.0, 35.0, -75.0> color rgb 1 }
>
> #macro String_Of_Beads(n)
>
> #if(n >= 0)
> String_Of_Beads(n-1)
> #end
>
> #local move = (0.25+(0.375*n));
>
> sphere { <cos(radians(9*n)), sin(radians(9*n)), move>, 0.125
> texture { T_Stone28 }
> finish { reflection { 0.05, 0.1 fresnel on } ambient 0.3 diffuse 0.5
> conserve_energy }
> }
> cylinder { <cos(radians(9*n)), sin(radians(9*n)), move>
> <cos(radians(9*(n+1))), sin(radians(9*(n+1))), (0.25+(0.375*(n+1)))>
> 0.015625 texture { T_Silver_5A }}
>
> #end
>
> String_Of_Beads(96)
>
> It actually works, but with any values higher than 96, the parse fails,
> and gives the message: "Too many nested symbol tables" whatever that
> means. (I'm not familiar with the source code.)
>
> I was wondering, however, is this an inherent limitation, or an imposed
> limitation? And might it be possible to adapt the parser to allow advanced
> recursion?
>
> Just some thoughts.
>
> Regards,
>
> ADB
I don't see the interst of recursion in that particular case. A loop would
have made the same. Recursion depth of at least 96 is enough for whatever I
could think of. If this internal limitation is not enough for what you want,
you should change the structure of your code or your approach. But it is
often very difficult to code what you have in mind, whatever your skill and
experience are (I have none of them, lol)!!!
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bruno Cabasson" <bru### [at] alcatelaleniaspacefr> wrote:
> I don't see the interst of recursion in that particular case. A loop would
> have made the same. Recursion depth of at least 96 is enough for whatever I
> could think of. If this internal limitation is not enough for what you want,
> you should change the structure of your code or your approach. But it is
> often very difficult to code what you have in mind, whatever your skill and
> experience are (I have none of them, lol)!!!
>
> Bruno
I don't know if it's the same in POV, but it stands to reason. In
programming, at least for complex cases, recursion can be MUCH faster than
a standard loop. It's true that for this case, a standard loop would have
been sufficient, but I was trying to prove a concept, and a complex case
wouldn't have parsed.
Regards,
ADB
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Anthony D. Baye wrote:
> In programming, at least for complex cases, recursion can
> be MUCH faster than a standard loop.
Recursion is a simple and elegant way to implement some algorithms,
and the most natural way to think about some problems, but I don't
know where you got the notion that it is faster. At best, it will
have similar performance to its unrolled iterative version.
Furthermore, recursion is only really useful when each step recurses
into multiple branches of execution. Even if you only have a branch
factor of 2, a recursion level of 96 ends up in 2^96 leafs, which
is a rather large number. So, this should not be a practical limit ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Anthony D. Baye wrote:
<snip>
> I was wondering, however, is this an inherent limitation, or an imposed
> limitation? And might it be possible to adapt the parser to allow advanced
> recursion?
I've run into that, too, but as others have already pointed out using a
loop together with a stack will allow you as much recursion depth as you
can provide memory (and parse time :) for. You can use a simple array as
a stack. Considering how POV parses macros right now it might be even
faster.
HTH,
Florian
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
