|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The attached file gives a "too many nested variables error."
I posted an incomplete snippet of the code to p.b-t..
Have I hit a fundamental, theoretical limit to macros, or have I simply
buggy code?
The purpose of the code was to make a fractal blob. I now see how my code
doesn't do this properly, BUT I'm bothered that I either cannot have nested
macros or redefine them!
Post a reply to this message
Attachments:
Download 'fraccy03b.pov.txt' (2 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 17 May 2002 08:35:37 -0400, "Greg M. Johnson" <gregj:-)565### [at] aolcom>
wrote:
> The purpose of the code was to make a fractal blob. I now see how my code
> doesn't do this properly, BUT I'm bothered that I either cannot have nested
> macros or redefine them!
You can have nested macros. Just do it properlny. Note that parser stoped not
during declaration of nested macros but during execution. It hit limit of
nested. Note that creation of macros in loop has no sense becouse in every
loop definiton of macros is not executed.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3ce4f95f$1@news.povray.org>, "Greg M. Johnson" <gregj:-
)565### [at] aolcom> says...
> The purpose of the code was to make a fractal blob. I now see how my code
> doesn't do this properly, BUT I'm bothered that I either cannot have nested
> macros or redefine them!
I think the problem is that macros doesn't work the way as you think they
do. In fact your first declaration of set1() never gets called.
What you assume is: set1() is immediately replaced by the content of the
last definiton of that macro.
But: In fact this is only done later, when the macro containing the call
to set1() is called... but at this time you already redefined set1()
This means: your scene is equivalent to
#macro set2() set1() #end
#macro set1() set2() #end
set1()
-> infinite recursion.
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks for the attempts at explanations, but they either
i) go way over my head
or
ii) disappoint me in this extreme limitation of povray.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 17 May 2002 09:58:51 -0400, "Greg M. Johnson" <gregj:-)565### [at] aolcom>
wrote:
> ii) disappoint me in this extreme limitation of povray.
That's not specific limitation of POV-Ray. Most of languages limits nesting.
Usually recursion/nesting can be replaced with iterations so you can still
try...
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Can you give me a brief example of
"iterations" without "nesting", especially where I could control the # of
levels with a variable?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <aaaaeugdt980scno5nu0sv1l288qv4653a@4ax.com>, abx### [at] babilonorg
says...
> Usually recursion/nesting can be replaced with iterations so you can still
> try...
And also a recursion depth of 97 should be enough for everybody ;-)
Really, what he wanted to do should be perfectly possible with a
recursive macro.
I attached a modifikation of Greg's source that roughly does what I think
he wanted it to do. But it does use only simple spheres instead of blobs
components, because blobs can't be nested inside other blobs (but unions
of spheres can).
Lutz-Peter
Post a reply to this message
Attachments:
Download 'test3.pov.txt' (2 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Greg M. Johnson <gregj:-)565### [at] aolcom> wrote:
> Can you give me a brief example of
> "iterations" without "nesting", especially where I could control the # of
> levels with a variable?
Ever heard of #while-loops?
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |