Hi

I have the following macros:

#macro CON_SMD_MOLEX_53261_GRND(n)
union{
     #local pin =
     union{
         box{<-0.18,-0.35,0><0.18,0.35,3.6> translate<0,1.375,0>}
         box{<-0.18,0.8,0><0.18,1.375,-0.3> }
         box{<-0.18,0.0,-0.3><0.18,1.375,-1.0> }
     }

     //Pins
     union{
         #local i = 0;
         #while(i<n)
             object{pin translate<-(n-1)*1.25/2+i*1.25,0,0>}
             #local i = i + 1;
         #end
         texture{col_silver}
     }

     //Plastikkoerper
     union{
         difference{
             box{<-(4.25+(n-2)*1.25)/2,0,0.01>
                 <(4.25+(n-2)*1.25)/2,3.4,4.2>}
             box{<-(3.05+(n-2)*1.25)/2,0.6,0.8>
                 <(3.05+(n-2)*1.25)/2,3.0,4.3>}
             box{<-(4.3+(n-2)*1.25)/2,2.99,3.2>
                 <(4.3+(n-2)*1.25)/2,3.41,4.3>}
             box{<-(2.5+(n-2)*1.25)/2,2.99,2.8>
                 <(2.5+(n-2)*1.25)/2,3.41,4.3>}

             #local i = 0;
             #while(i<n+2)
                 box{<-0.3,2.8,0> <0.3,3.41,0.6>
                     translate<-(n+1)*1.25/2+i*1.25,0,0>}
                 #local i = i + 1;
             #end
         }
         texture{pigment{Gray30}}
     }
}
#end

#macro CON_SMD_MOLEX_53261_2()
object{CON_SMD_MOLEX_53261_GRND(2)}
#end
#macro CON_SMD_MOLEX_53261_3()
object{CON_SMD_MOLEX_53261_GRND(3)}
#end
#macro CON_SMD_MOLEX_53261_4()
object{CON_SMD_MOLEX_53261_GRND(4)}
#end

POVRay parses the file containing this macro (and others befor and 
behind it) When I call that macro POVRay says

Parse Error: Expected 'object', undeclared identifier 
'CON_SMD_MOLEX_53261_4' found instead.

Any ideas?

-- 

mat### [at] matweide
http://www.matwei.de

Post a reply to this message

I had no problems running the macro as it was under POV-Ray 3.6 for Mac OS
9.x, although there were a few issues that I noticed with the general
construction.

First of all it is un-necessary to encapsulate the contents of your macro in
a union, and I found no problems in dispensing with the outer union block.

Second, It is, in my opinion, redundant to encapsulate your macro calls in
their own macros when they can be called easier by themselves and it takes
up less space doing so.

Third, it is also un-necessary to place your macro calls inside an object
block unless you are going to trasform them in some way (f.ex. translate,
rotate or scale)

Other than that I simply added some stuff so that I could view the scene.

Regards,

ADB

#include "colors.inc"
#include "metals.inc"

camera {
 location <5.0, 4.0, -10.0>
 look_at 0
 }

light_source { <5.0, 15.0, -20.0> rgb 1 }

#default { pigment { White } finish { ambient 0.4 diffuse 0.6 } }

#macro CON_SMD_MOLEX_53261_GRND(n)

#local pin =
 union{
  box{<-0.18,-0.35,0><0.18,0.35,3.6> translate<0,1.375,0>}
  box{<-0.18,0.8,0><0.18,1.375,-0.3> }
  box{<-0.18,0.0,-0.3><0.18,1.375,-1.0> }
  }

     //Pins
 union{
         #local i = 0;
         #while(i<n)
             object{pin translate<-(n-1)*1.25/2+i*1.25,0,0>}
             #local i = i + 1;
         #end
         pigment { P_Silver3 }
  }

     //Plastikkoerper
 union{
  difference{
   box{<-(4.25+(n-2)*1.25)/2,0,0.01> <(4.25+(n-2)*1.25)/2,3.4,4.2>}
   box{<-(3.05+(n-2)*1.25)/2,0.6,0.8> <(3.05+(n-2)*1.25)/2,3.0,4.3>}
   box{<-(4.3+(n-2)*1.25)/2,2.99,3.2> <(4.3+(n-2)*1.25)/2,3.41,4.3>}
   box{<-(2.5+(n-2)*1.25)/2,2.99,2.8> <(2.5+(n-2)*1.25)/2,3.41,4.3>}
  #local i = 0;
  #while(i<n+2)
   box{<-0.3,2.8,0> <0.3,3.41,0.6> translate<-(n+1)*1.25/2+i*1.25,0,0>}
  #local i = i + 1;
  #end
   }
   texture{pigment{Gray30}}
  }

#end


CON_SMD_MOLEX_53261_GRND(2)
CON_SMD_MOLEX_53261_GRND(3)
CON_SMD_MOLEX_53261_GRND(4)

Post a reply to this message

Anthony D. Baye schrieb:
> I had no problems running the macro as it was under POV-Ray 3.6 for Mac OS
> 9.x, although there were a few issues that I noticed with the general
> construction.
> 
> First of all it is un-necessary to encapsulate the contents of your macro in
> a union, and I found no problems in dispensing with the outer union block.

OK. But that shouldnt be the problem.

> Second, It is, in my opinion, redundant to encapsulate your macro calls in
> their own macros when they can be called easier by themselves and it takes
> up less space doing so.

The macro is part of a much bigger system:
http://web2.callisto.twam.info/eng/index.php?page1=eagle3d

So it is necessary to do it that way.

> Third, it is also un-necessary to place your macro calls inside an object
> block unless you are going to trasform them in some way (f.ex. translate,
> rotate or scale)

I do so to place the parts on the PCB.

> Other than that I simply added some stuff so that I could view the scene.

Thats strange. I can also use the macro within a test scene (forget to 
mention it) But if I call it from the main file (the macro is in a 
include file which is included by a top level include file) it isn't found.

-- 

mat### [at] matweide
http://www.matwei.de

Post a reply to this message

> Thats strange. I can also use the macro within a test scene (forget to
> mention it) But if I call it from the main file (the macro is in a
> include file which is included by a top level include file) it isn't
found.

Have you checked for the obvious problems, like mispellings of the macro
name, or failing to #include files such that the macro really is defined
before it's called?

Put #debug "\n\nMacro defined\n\n" right after the macro definition and see
if the text is displayed before the error occurs.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

An issue I have hit a few times is that the SDL interpreter seems to have
trouble with macro definitions after the first inside say a layered texture.
Something like this:

#declare A_MACRO = {...}

#declare A_LAYERED_TEXTURE = {
texture { .... A_MACRO .... }
texture { .... A_MACRO .... }   // This macro substitution is not handled
}

does not work and I am in the habit of coding instead:

#declare A_MACRO {...}

#declare A_LAYERED_TEXTURE_1 = {... A_MACRO ... }
#declare A_LAYERED_TEXTURE_2 = {... A_MACRO ... }
#declare A_LAYERED_TEXTURE = {
texture { A_LAYERED_TEXTURE_1 }
texture { A_LAYERED_TEXTURE_2 }
}

which works fine.

Post a reply to this message

In article <41bd01dd$1@news.povray.org> , "William Pokorny" 
<pok### [at] attglobalnet> wrote:

> An issue I have hit a few times is that the SDL interpreter seems to have
> trouble with macro definitions after the first inside say a layered texture.
> Something like this:
>
> #declare A_MACRO = {...}

This is not a macro, it is a declaration!

The limitations and pitfalls of layered texture declarations are explained
in the manual.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Slime schrieb:

> Put #debug "\n\nMacro defined\n\n" right after the macro definition and see
> if the text is displayed before the error occurs.

That was the point brougt the solution. I was a bit (or more than a bit 
:) stupid. The macro is defined in a file called connector.inc. That 
file is in directory which is added to the POVRay library path via an 
INI File. Now I had (unintentionally) a older version of this file 
(without that macro) in the same directory as the POV file calling that 
macro. So that (older) file was found first and used. Doh!

Thanks for your time and sorry.


-- 

mat### [at] matweide
http://www.matwei.de

Post a reply to this message

Hi Thorsten,
Indeed in my rush to aid Matthias I wrote #declare... instead of #macro....

The documentation of course says you cannot use #macro definitions in
layered textures, but like many rules in life it is in fact not a hard a
fast one. Using macros in layered textures has been a very useful way for me
to create versions of the standard POV-Ray texture include files that
support both my older assumed_gamma of 2.2 scenes and my new assumed_gamma
of 1.0 scenes.

I adopted this approach based upon a recommendation Ive made about a year
ago as a way to cope with the fact the shipped textures do not work well if
you try and use the recommended assumed_gamma  of 1...  I had been running
with an assumed_gamma of 2.2 for YEARs because it was all that seemed to
work with shipped textures.

To any who might also have been confused by this quirk of the standard
includes - get to where you ALWAYS use an assumed_gamma of 1. Adjustments to
textures are easier and simply make more sense. The resultant images have a
better fidelity that could probably be measured if I wanted to bother, but
it is obvious.

Unfortunately, the supplied textures and any others you might have created
so they look good on your non-apple system - without adjustment - and to
work with the supplied textures will need to be adapted to run with an
assumed_gamma of 1. A painful change, but well worth it.The illegal use of
macros happens to make adapting easier.

I know it is hard sometimes for you Thorsten and the other POV-Ray experts
to deal with us fools - but keep after us and eventually we'll get it!

Thanks again for catching my error.
Bill

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:41bd5c64$1@news.povray.org...
> In article <41bd01dd$1@news.povray.org> , "William Pokorny"
> <pok### [at] attglobalnet> wrote:
>
> > An issue I have hit a few times is that the SDL interpreter seems to
have
> > trouble with macro definitions after the first inside say a layered
texture.
> > Something like this:
> >
> > #declare A_MACRO = {...}
>
> This is not a macro, it is a declaration!
>
> The limitations and pitfalls of layered texture declarations are explained
> in the manual.
>
>     Thorsten
>
> ____________________________________________________
> Thorsten Froehlich, Duisburg, Germany
> e-mail: tho### [at] trfde
>
> Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message