"Christian Froeschlin" <chr### [at] chrfrde> wrote in message 
news:4a42abde$1@news.povray.org...
> Chris B wrote:
>
>> The main advantage with using variables in this way is that you can 
>> specify just the variables you need
>
> Yes, I reckoned you used that mechanism for more convenient
> default values. However, it's not quite true you only need to
> specify the variables you need: you also need to reset those
> which have been modified for some previous invocation of
> the macro, and you may not always be aware of those.
>

Any identifiers defined within the macro that shouldn't persist across macro 
calls should be defined using #local rather than #declare.

It's true that any global values that you set before calling the macro the 
first time will persist across macro calls (unless you undef them), but you 
should generally be aware of what those are, because you'll usually have set 
them explicitly yourself. For things like the cabinet height, the panel 
thickness, handle type etc. this is mostly a good thing, as you can set them 
once at the top of your scene file and then generate a whole set of cabinets 
conforming to the same style. You only need to adjust the width and other 
unit-specific attributes between macro calls (door handedness, whether 
there's a sink or hob in the worksurface etc.).

There are a few situations where the macro could set a default in one 
invocation that you don't want to carry across into the next invocation. 
Where I've published macros for use by others, I've usually therefore 
included an Undef macro that can be used to reset all of the variable 
settings for which there are default values declared. This gives you the 
option of using the POV-Ray #undef command to override just that one default 
value (if you know what it's called), or calling my Undef macro to reset 
everything before the next sequence of macro calls (to be on the safe side).

For example, the Rope macros include a Rope_Undef macro. You can call that 
macro between any two Rope macro calls to Undef all of the values, so that 
you can start afresh. If the same were done here you could have a kitchen 
showroom, generating 10 units for one kitchen exhibit, then calling the 
Cabinet_Undef macro before generating 10 units in a different style for the 
next kitchen exhibit.

P.S. The #ifndef statements are really very quick to add at the end of the 
development process. Using the Windows POV-Ray editors 'columnar' editing 
feature it just takes a few seconds more work. The Undef macro is also very 
quick to create as it's mostly just a copy of the #ifndef statements with 
#ifndef changed to #ifdef and #declare changed to #undef (and the values 
removed).


> That problem could be prevented by having two macros for
> each object, the first one just resetting the defaults:
>
> #macro Begin_Cabinet()
>   #declare WIDTH = 0.6
>   ...
> #end
>
> #macro End_Cabinet()
>   union
>   {
>     ...
>   }
> #end
>
> Begin_Cabinet()
> #declare WIDTH = 0.7
> End_Cabinet()
>
> It would also remove the need for all those #ifndef's.

This comes down a little to personal preference, but I'd argue that the 
#ifndef approach makes it a little easier to generate a complete set of 
cabinets in a consistent style.

The technique you've illustrated also seems to make it more difficult to 
handle what I could call 'dependant' defaults. For example, in the Rope 
macros, the strand thickness defaults to half the rope thickness for twisted 
ropes and one third the rope thickness for braided ropes (which have twice 
the number of strands). If you only set the type of rope after calling 
Begin_Rope you don't have enough info to be able to set the default strand 
thickness within Begin_Rope.


Regards,
Chris B.

Post a reply to this message