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

-- 
*******************************

* 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