Hi,

I noticed that a macro I made only works if I call another macro with
'mymacro(pos+0)' but not if I call it with 'mymacro(pos)' without the
+0. I think I understand why this is, but is it a good way of coding to
add the +0 ? Or is there a better way ?

Thanks,
Elias Pschernig

Post a reply to this message

> I noticed that a macro I made only works if I call another macro with
> 'mymacro(pos+0)' but not if I call it with 'mymacro(pos)' without the
> +0. I think I understand why this is, but is it a good way of coding to
> add the +0 ? Or is there a better way ?

I am far from expert, but sounds... curious. Weird. Never encountered
anything like that myself. If you post the source, I might be able to help
you better. My best _guess_ is that there is some automatic vector
expansion going on, and by making it explicit in the macro you could avoid
the weirdness. Btw: what version of POV are you using?

 -- Nikodemus Siivola

Post a reply to this message

> I am far from expert, but sounds... curious. Weird. Never encountered
> anything like that myself. If you post the source, I might be able to
help
> you better. My best _guess_ is that there is some automatic vector
> expansion going on, and by making it explicit in the macro you could
avoid
> the weirdness. Btw: what version of POV are you using?

Here is the source. The problem is, without the +0, the value of the pos
vector gets changed. What i'm looking for is probably a way to change
the parameter type or something like that.

I've read the documentation (so I understand f.e. the difference between
%rec and $rec), but I didn't find anything about how to change the
parameters type.

#version unofficial MegaPov 0.7;

%rec = 0;

#macro tree(pos, dir, scl)
   $rec = rec + 1;
   cylinder { pos pos + dir * scl .1 * scl }
   %pos = pos + dir * scl;
   #if(rec < 10)
      %ldir = vaxis_rotate(dir, z, 30);
      %rdir = vaxis_rotate(dir, z, -30);
      tree(pos+0, ldir, scl*0.9) // If i don't write the '+0', it goes
wrong
      tree(pos+0, rdir, scl*0.9)
   #end
   $rec = rec - 1;
#end

tree(-4*y, <0,1,0>, 1)

Post a reply to this message

> I've read the documentation (so I understand f.e. the difference between
> %rec and $rec), but I didn't find anything about how to change the
> parameters type.

Ah, your macro enters a territory badly covered by the docs: creating a
local variable with the name of a parameter... Dunno why it behaves the way
it does, or why the +0 helps, though. At least it is not because of the
MegaPOV: I tried it in 3.1g and it did the exact same thing. An easy thing
to fix, though. Just use

    #local new_pos = ...

and later

    tree(new_pos...

Yours,

  - Nikodemus Siivola

Post a reply to this message

> Ah, your macro enters a territory badly covered by the docs: creating 
a
> local variable with the name of a parameter... Dunno why it behaves 
the way
> it does, or why the +0 helps, though. At least it is not because of 
the
> MegaPOV: I tried it in 3.1g and it did the exact same thing. An easy 
thing
> to fix, though. Just use
> 
>     #local new_pos = ...
> 
> and later
> 
>     tree(new_pos...
> 

Thanks, I will use that. I wanted to avoid a new variable at first, but 
it's a lot better than the +0.

Elias Pschernig

Post a reply to this message

"Elias Pschernig" <eli### [at] aonat> wrote:

>Thanks, I will use that. I wanted to avoid a new variable at first, but
it's a lot
>better than the +0.

Why did you want to avaid a new variable, though? (And you actually werent
avoiding any - #local always creates a new variable.) For elegance? Because
of the memory requirements? A single new vector variable has a neglible
cost in a recursive macro or anywhere else, for that matter.

Just curious,

  -- Nikodemus

Post a reply to this message

> Why did you want to avaid a new variable, though? (And you actually
> werent avoiding any - #local always creates a new variable.) For
> elegance? Because of the memory requirements? A single new vector
> variable has a neglible cost in a recursive macro or anywhere else,
> for that matter.

I was avoiding one line of code for every parameter. And i'm going to
need lots of parameters, as there doesn't seem to be a
'record/struct/class' construction in POV :)

Instead of using the code below:

// pseudo code
#macro example(pos)
   #while
      example(pos)
      #local pos = pos + y
   #end
#end

I'm using now, as you suggested:

#macro example(pos)
   #local var_pos = pos // this is what i have to do additionally
   #while
      example(var_pos)
      #local var_pos = var_pos + y // because this should change the
                                   // local value only
   #end
#end

And it works exactly as I want it to :)

Thanks again for your reply,

Elias Pschernig

Post a reply to this message

"Elias Pschernig" <eli### [at] aonat> wrote in message
news:3b0832ce$1@news.povray.org...

> I was avoiding one line of code for every parameter. And i'm going to
> need lots of parameters, as there doesn't seem to be a
> 'record/struct/class' construction in POV :)

There are the arrays, though...

> #macro example(pos)
>    #local var_pos = pos // this is what i have to do additionally
>    #while
>       example(var_pos)
>       #local var_pos = var_pos + y // because this should change the
>                                    // local value only
>    #end
> #end

Some notes:
- As per docs, you should use #declare var_pos... within the loop to
redefine the local variable.
- Even tough the docs don't properly cover what happens when you use #local
to redefine local variables within loop, it seems to work equivalently to
the above. Note though, that MegaPOV seems have trouble with #undef after
doing this. 3.1g works seems to treat #local for the purpose of redefining
local variables just as it does #declare. I suspect that it may result in
strangeness as well. ;)

 -- Nikodemus

Post a reply to this message

> Some notes:
> - As per docs, you should use #declare var_pos... within the loop to
> redefine the local variable.

Yes, you're right, else I get an error message about an undefined
variable.

> - Even tough the docs don't properly cover what happens when you use
#local
> to redefine local variables within loop, it seems to work equivalently
to
> the above. Note though, that MegaPOV seems have trouble with #undef
after
> doing this. 3.1g works seems to treat #local for the purpose of
redefining

I'm not planning on using #undef anywhere I think.

> local variables just as it does #declare. I suspect that it may result
in
> strangeness as well. ;)

I will post here about every strangeness I will come across with POV
code ;)

Elias Pschernig

Post a reply to this message