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

Andrea Ryan wrote:
> 
> That won't work if the object needs to be translated different distances
> along different axies.
> Brendan Ryan
> 
	Of course it will if you give vectors as parameters:

#macro Foo (Trans)
  ...
  translate Trans
#end

object {
  Foo (<1, 2, 3>)
}

		Jerome

-- 
*******************************
* Always listen to experts,   * Jérôme M. BERGER
* they'll tell you what can't * mailto:ber### [at] inamecom
* be done and why...          * http://www.enst.fr/~jberger
* Then do it.                 *
*******************************

Post a reply to this message

Yes it will.
Foo(<1,4,2>,<-6,2.3,1>,<4.2,7,-1>)
In this instance . is not needed at all, you can just use "translate Trans",
but it is especially useful when you need to do things like calculate vector
lengths and angles. And if you really wanted to, you could do this:
#macro Foo(Trans ... )
 #local TransX = Trans.x;
 #local TransY = Trans.y;
 #local TransZ = Trans.z;
 translate <TransX,TransY,TransZ>
 ...
#end

Andrea Ryan wrote:

> That won't work if the object needs to be translated different distances
> along different axies.
> Brendan Ryan
>
> Peter Popov wrote:
>
> > 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

Thanks. In one of my block macros, I cut the number of parameters from six
to two.
Brendan Ryan

Andrea Ryan wrote:

> 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

Andrea Ryan wrote:
> 
> 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

This is way off what you probably want, but here is a little description of what
I meant. It's from real life, by the way...

If you have a macro which needs heaps of parameters you can also put all those
parameters in one include file and pass the name of that include as parameter.
The inc-file would only have a series of declarations for each parameter-value
for your macro. This makes it easier to keep track of what you're doing in case
you're experimenting with different settings.
You could create one include with values for each parameter you set as default.
To make it more complicated you could put each declaration in a
#ifndef-statement so the macro will (only) use the default value for those
parameters you haven't defined elsewhere.
Do you still follow? Well, I have a hard time, but I have to since I work with a
model that works this way. I have dozens of data-include-files, each with their
own set of parameter-values, overriding the default-values from another file.
If you lose track you easily get conflicts with redeclarations.

By the way: I wouldn't want anyone else to have to work with this clutter of
includes of mine. You would probably declare me mad (or inefficient).

Remco

Post a reply to this message

Remco de Korte <rem### [at] xs4allnl> wrote
>
> If you have a macro which needs heaps of parameters you can also put all
those
> parameters in one include file and pass the name of that include as
parameter.
>

    There is the answer to -my- question! (Include or Macro? p.g 10/10/99)
This is -exactly- what I needed!

    Well, I could still use some sort of overloading....

Post a reply to this message

I seem to recall from a couple of years ago that one could not concat
together a texture name. Has this changed? or is there a way to pass part of
a texture name to a macro?

/// This doesn't work but I wish it would ///

#macro Tex(Name, Index)
sphere{0,1 texture{concat(Name, Index)}
#end

Tex(Brown, 1)

Post a reply to this message

On Fri, 15 Oct 1999 10:36:54 -0400, Bill the Galactic Hero wrote:
>I seem to recall from a couple of years ago that one could not concat
>together a texture name. Has this changed? or is there a way to pass part of
>a texture name to a macro?

Nope, you still can't do it.  However, you can use the file functions
to create an include file "on the fly" which you can then include.
It would be nice if you could "include" a string...

Post a reply to this message

Try this:

//---------------

#macro parse (string)
  #fopen file "parsetmp.inc" write
  #write (file, result)
  #fclose file
  #include "parsetmp.inc"
#end

#include "colors.inc"
#include "stones.inc"

sphere
{
  0, 1 
  texture { parse (concat("T_Stone",str(32*rand(seed(42)),0,0))) }
}

// still needs lights and camera :)
//--------------------

On Fri, 15 Oct 1999 10:36:54 -0400, "Bill the Galactic Hero"
<the### [at] earthlinknet> wrote:

>I seem to recall from a couple of years ago that one could not concat
>together a texture name. Has this changed? or is there a way to pass part of
>a texture name to a macro?
>
>/// This doesn't work but I wish it would ///
>
>#macro Tex(Name, Index)
>sphere{0,1 texture{concat(Name, Index)}
>#end
>
>Tex(Brown, 1)
>

Peter Popov
ICQ: 15002700

Post a reply to this message

I think you meant this:
#macro parse (string)
  #fopen file "parsetmp.inc" write
  #write (file, string)//<-----change "result" to "string"
  #fclose file
  #include "parsetmp.inc"
#end

This macro may be *very* handy. Thanks! :-)

Post a reply to this message

On Fri, 15 Oct 1999 18:47:23 -0500, Chris Huff
<Chr### [at] compuservecom> wrote:

>I think you meant this:
>#macro parse (string)
>  #fopen file "parsetmp.inc" write
>  #write (file, string)//<-----change "result" to "string"
>  #fclose file
>  #include "parsetmp.inc"
>#end
>
>This macro may be *very* handy. Thanks! :-)

Sorry about the typo. The original macro, which I used to make
previews of all textures in Stones.inc, had two parameters - a string
and a number, and a local string variable "result" which equalled
concat ( string, str(number,0,0)). Thank you for correcting the typo,
Chris!


Peter Popov
ICQ: 15002700

Post a reply to this message

Cool!
    Thanks! I got the typo correction too. Man! All you have to do around
here is ask the right question!

Peter Popov <pet### [at] usanet> wrote in message
news:V6sHOJmtyVsgp96vIByaBnfkd1tO@4ax.com...
> Try this:
>
> file://---------------
>
> #macro parse (string)
>   #fopen file "parsetmp.inc" write
>   #write (file, result)
>   #fclose file
>   #include "parsetmp.inc"
> #end
>
> #include "colors.inc"
> #include "stones.inc"
>
> sphere
> {
>   0, 1
>   texture { parse (concat("T_Stone",str(32*rand(seed(42)),0,0))) }
> }
>

Post a reply to this message