Is it a good idea to include transformations in macros like:

#macro MakeBall (translatex, translatey, translatez, scalex, scaley,
scalez, radius)
sphere { <translatex, translatey, translatez>,radius
scale <scalex, scaley, scalez>
texture {...}
}
#end

or let others add object statements and transformations?
Brendan Ryan

Post a reply to this message

Andrea Ryan wrote:
> 
>     Is it a good idea to include transformations in macros like:
> 
> #macro MakeBall (translatex, translatey, translatez, scalex, scaley,
> scalez, radius)
> sphere { <translatex, translatey, translatez>,radius
> scale <scalex, scaley, scalez>
> texture {...}
> }
> #end
> 
> or let others add object statements and transformations?
> Brendan Ryan

Really it's a question of what you want the macro to do. I have even gone
so far as to add color vectors for pigments into the macro statement. Is
it effecient to do so ? I don't know and don't care as long as it does
what I wan't it to.

-- 
Ken Tyler -  1100+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Translate and scale seem like a good idea to put in the macro as it
makes for shorter code; you don't need the full words translate and
scale on every line using the macro. But, like Ken said, it all depends
what the macro is intended for. In my tree macro I have a parameter for
an array of three pigments, so that the pigment of each individual leaf
can be varied, also I send the actual leaf object definition. This seems
like a lot of data to send to a macro, but it's everything needed to
make the tree. For most other macros, though, you wouldn't want to send
a pigment, because leaving it outside gives more freedom in the
texturing and makes for less macro parameters.

Andrea Ryan wrote:

>     Is it a good idea to include transformations in macros like:
>
> #macro MakeBall (translatex, translatey, translatez, scalex, scaley,
> scalez, radius)
> sphere { <translatex, translatey, translatez>,radius
> scale <scalex, scaley, scalez>
> texture {...}
> }
> #end
>
> or let others add object statements and transformations?
> Brendan Ryan

Post a reply to this message

Thanks, I'll leave the translate and scale statements in my block
macros.
Brendan Ryan

Andrea Ryan wrote:

>     Is it a good idea to include transformations in macros like:
>
> #macro MakeBall (translatex, translatey, translatez, scalex, scaley,
> scalez, radius)
> sphere { <translatex, translatey, translatez>,radius
> scale <scalex, scaley, scalez>
> texture {...}
> }
> #end
>
> or let others add object statements and transformations?
> Brendan Ryan

Post a reply to this message

Andrea Ryan wrote:
> 
>     Is it a good idea to include transformations in macros like:
> 
> #macro MakeBall (translatex, translatey, translatez, scalex, scaley,
> scalez, radius)
> sphere { <translatex, translatey, translatez>,radius
> scale <scalex, scaley, scalez>
> texture {...}
> }
> #end
> 
> or let others add object statements and transformations?
> Brendan Ryan

There's a limit to the amount of parameters a macro can handle (I soon found
out).
It's also not easier to work with a macro that only needs a few essential
parameters.
For instance, if a macro just declares an object you can easily scale, rotate or
translate it outside that macro by including it in an object statement, leaving
the essentials to the actual macro-declaration. To turn things round: you can
add the most redundant parameters to a macro and it will still work (in the
example of the object-macro you could add parameters declaring ground_fog,
sky_sphere etc. - of course these might also be meaningful to the macro).

If you _need_ a lot of parameters it's also an idea to pass those in an
include-file.
You could use a template-include with default values... eeh... oh well, this is
not what you asked, never mind.

Remco

Post a reply to this message

On Wed, 13 Oct 1999 21:33:56 -0400, Andrea Ryan <ary### [at] global2000net>
wrote:

>    Is it a good idea to include transformations in macros like:
<code>
>or let others add object statements and transformations?
>Brendan Ryan

You should take advantage of the dot "." operator. For example:

#macro Foo (Trans, Rot, Scale) // These are all vectors
  #local TransZ = Trans.z;
  ...
#end

This way you'll pass the macro three times less parameters.


Peter Popov
ICQ: 15002700

Post a reply to this message

The only problem that I can see here is that when you don't want to
translate or scale, you still have to give the parameters to it.
  This hopefully will be corrected in the next version when default values
for parameters will be added...

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Where can I find information on these temple include files? I want default values.
Brendan Ryan

Remco de Korte wrote:

> Andrea Ryan wrote:
> >
> >     Is it a good idea to include transformations in macros like:
> >
> > #macro MakeBall (translatex, translatey, translatez, scalex, scaley,
> > scalez, radius)
> > sphere { <translatex, translatey, translatez>,radius
> > scale <scalex, scaley, scalez>
> > texture {...}
> > }
> > #end
> >
> > or let others add object statements and transformations?
> > Brendan Ryan
>
> There's a limit to the amount of parameters a macro can handle (I soon found
> out).
> It's also not easier to work with a macro that only needs a few essential
> parameters.
> For instance, if a macro just declares an object you can easily scale, rotate or
> translate it outside that macro by including it in an object statement, leaving
> the essentials to the actual macro-declaration. To turn things round: you can
> add the most redundant parameters to a macro and it will still work (in the
> example of the object-macro you could add parameters declaring ground_fog,
> sky_sphere etc. - of course these might also be meaningful to the macro).
>
> If you _need_ a lot of parameters it's also an idea to pass those in an
> include-file.
> You could use a template-include with default values... eeh... oh well, this is
> not what you asked, never mind.
>
> Remco

Post a reply to this message

I was going to say this yesterday but my connection problems were even
worse than usual.
Yes, vectors are extremely useful macro parameters. I would just like to
point out that in this specific case the dot operator is not needed at
all, though yes, it is very useful at cutting down parameters when
individual components are needed. I ran out of parameters on my tree
macro, using vectors, so now I'm even passing it arrays!
#macro Foo(Trans)
translate Trans
#end

Peter Popov wrote:

> On Wed, 13 Oct 1999 21:33:56 -0400, Andrea Ryan <ary### [at] global2000net>
> wrote:
>
> >    Is it a good idea to include transformations in macros like:
> <code>
> >or let others add object statements and transformations?
> >Brendan Ryan
>
> You should take advantage of the dot "." operator. For example:
>
> #macro Foo (Trans, Rot, Scale) // These are all vectors
>   #local TransZ = Trans.z;
>   ...
> #end
>
> This way you'll pass the macro three times less parameters.
>
> Peter Popov
> ICQ: 15002700

Post a reply to this message

That won't work if the object needs to be translated different distances
along different axies.
Brendan Ryan

Peter Popov wrote:

> On Wed, 13 Oct 1999 21:33:56 -0400, Andrea Ryan <ary### [at] global2000net>
> wrote:
>
> >    Is it a good idea to include transformations in macros like:
> <code>
> >or let others add object statements and transformations?
> >Brendan Ryan
>
> You should take advantage of the dot "." operator. For example:
>
> #macro Foo (Trans, Rot, Scale) // These are all vectors
>   #local TransZ = Trans.z;
>   ...
> #end
>
> This way you'll pass the macro three times less parameters.
>
> Peter Popov
> ICQ: 15002700

Post a reply to this message