I originally ran into this problem running 3.5 RC6 on W2K, but 3.1g
exhibits the same problem.  When I run the scene below, I get a parse
error, "no matching } in texture, # found instead."  Here's a sample
file that causes the parse error:

#include "colors.inc"

#macro fooTexture()
 texture {
  pigment { Red }
 }
 texture {
 #if (0)
  pigment { Blue }
 #else
  pigment { Green }
 #end //if(0)
 }
#end//macro fooTexture()

#declare foo_texture = fooTexture()

Any #-whatever within the 2nd layer texture causes this error.  Try
replacing the #if  .. #else .. #end  with  #declare causeParseError = 
1;

The strange thing is that if I put #if's in the Red layer, it parses
fine.  OK, then you get "error: No objects in scene".  :-)

Any idea what causes this problem?  I know about the note in section
6.7.6, "Layered Textures", but that has to do with macros inside
layered textures.  This is the other way around, layered textures
inside a macro.  I don't see any syntax ambiguities.

Help?

-Scott

Post a reply to this message

Attachments:
Download 'iso-8859-1' (4 KB)

Scott Wasson wrote:
>  texture {
>  #if (0)
>   pigment { Blue }
>  #else
>   pigment { Green }
>  #end //if(0)
>  }
> Any #-whatever within the 2nd layer texture causes this error.  Try
> replacing the #if  .. #else .. #end  with  #declare causeParseError = 1;

If POV SDL is like C, might need to have #if flush with
left margin, instead of indenting it.

-- 
Tim Cook
http://empyrean.scifi-fantasy.com
mirror: http://personal.lig.bellsouth.net/lig/z/9/z993126

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

On Tue, 18 Jun 2002 17:40:06 -0500, Timothy R. Cook wrote:

> If POV SDL is like C, might need to have #if flush with left margin,
> instead of indenting it.

Neither C nor POV-Script care about indentation, you must be thinking
about something else.


-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: <chr### [at] tagpovrayorg>
WWW: http://homepage.mac.com/chrishuff/

Post a reply to this message

On Tue, 18 Jun 2002 17:26:10 -0500, Scott Wasson wrote:

> Any idea what causes this problem?  I know about the note in section
> 6.7.6, "Layered Textures", but that has to do with macros inside layered
> textures.  This is the other way around, layered textures inside a
> macro.  I don't see any syntax ambiguities.

This is strange, I've never encountered it before...maybe it is just a
result of the layered texture definition being in a macro, so the parser
doesn't expect that construction.

It might work if you declared the layered texture as a local variable:

#macro()
    #local localTex =
    texture {}
    texture {}

But I don't know how you would return the texture..."texture {localTex}"
would get picked up as a third layer, I think you would have to return
"localTex" and wrap the macro call in a texture {} block. Assuming this
trick actually helps...

Hopefully, a future version of POV-Ray will have an improved syntax for
defining layered textures...


-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: <chr### [at] tagpovrayorg>
WWW: http://homepage.mac.com/chrishuff/

Post a reply to this message

Thanks, but SDL ignores whitespace.

Has anyone tried my example and reproduced the problem?

-Scott

"Timothy R. Cook" <z99### [at] bellsouthnet> wrote in message
news:3D0### [at] bellsouthnet...
> Scott Wasson wrote:
> >  texture {
> >  #if (0)
> >   pigment { Blue }
> >  #else
> >   pigment { Green }
> >  #end //if(0)
> >  }
> > Any #-whatever within the 2nd layer texture causes this error.  Try
> > replacing the #if  .. #else .. #end  with  #declare causeParseError = 1;
>
> If POV SDL is like C, might need to have #if flush with
> left margin, instead of indenting it.
>
> --
> Tim Cook
> http://empyrean.scifi-fantasy.com
> mirror: http://personal.lig.bellsouth.net/lig/z/9/z993126
>
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.12
> GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
> N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
> PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
> D++(---) G(++) e*>++ h+ !r--- !y--
> ------END GEEK CODE BLOCK------
>

Post a reply to this message

On Wed, 19 Jun 2002 09:59:42 -0400, "Scott Wasson" <swa### [at] townispcom>
wrote:
> Thanks, but SDL ignores whitespace.
> Has anyone tried my example and reproduced the problem?

Yes, I tried it but I still think it could be feature.
Consider such example

//START
  #macro fooTexture()
    texture { pigment { rgb y } }
    #if (Condition)
      #declare TMP=texture{ pigment{ rgb x } }
    #end
    texture{ pigment { rgb z } }
  #end
  #declare foo_texture = fooTexture()
//END

Tell me (without parsing) what should be last line of the macro - second leyer
of the first texture or second leyer of texture TMP ? Perhaps to avoid such
cases parser forbids any # which can leads to such situation. As Warp said You
in beta-test group SDL could be changed in this part and it is one of our
wishes for 4. Similiar limitation appear in case of such simple script:

//START
  #if(#if(yes)yes#end)#end
//END

ABX

Post a reply to this message

news:2151hu4iabm314mvp8sb0bi1i3inn3ghdq@4ax.com...
> Consider such example
>
>1 //START
>2  #macro fooTexture()
>3   texture { pigment { rgb y } }
>4     #if (Condition)
>5       #declare TMP=texture{ pigment{ rgb x } }
>6     #end
>7     texture{ pigment { rgb z } }
>8   #end
>9   #declare foo_texture = fooTexture()
>10 //END

Conditional directives are nesting.  Therefore the #end on line 6 closes the
#if on line 4, and the #end on line 8 closes the #macro on line 2.  What am
I missing?

-Scott

Post a reply to this message

On Wed, 19 Jun 2002 11:33:03 -0400, "Scott Wasson" <swa### [at] townispcom>
wrote:
> Conditional directives are nesting.  Therefore the #end on line 6 closes the
> #if on line 4

Yes, it closes #if and only #if, not SDL. Consider this example:

//START
  #declare O=
    #if(Condition)
      sphere{ y 1 rotate x*30
    #else
      box{ -1 1 translate z
    #end
    pigment{ rgb 1}
  }
//END

Should it report missed "}" in sphere or box ? It is valid statement and no
doubts what is result of this script - there is no such thing like layered
object.

ABX

Post a reply to this message

Checked this out and found wrapping it in material {} makes it okay. So it
must be something in the program code that can't handle this properly
otherwise, as was already said before. The layered texture by itself just
sits there without definite boundaries for the parser, I guess. I've never
looked at the program code for it but that's what people always say and it
makes perfect sense.

bob h

Post a reply to this message

Depending on whether Condition is True or False, your example can be
rewritten as:

 //START
   #declare O=
     // Condition = True
       sphere{ y 1 rotate x*30
    /* #else
       box{ -1 1 translate z
     #end
    */
     pigment{ rgb 1}
   }
 //END

and for Condition=False:

//START
   #declare O=
     /* #if(Condition=False)
       sphere{ y 1 rotate x*30
     #else
    */
       box{ -1 1 translate z
     //#end
     pigment{ rgb 1}
   }
 //END

It's clear from these two examples that the first encounters a parsing error
in the sphere, and the second in the box.  Your example behaves exactly the
same way, except the code that is "commented out" is done dynamically by
Condition.  Again, the error will appear in either the sphere or the box
depending on whether Condition is True or False respectively.

-Scott

Post a reply to this message