![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Please see the attached code. Take special note on line 62. If you
remove it or comment it, the parser gives an error. I have no idea
why, but it seems like a parser bug.
Peter Popov
ICQ: 15002700
Post a reply to this message
Attachments:
Download 'glass.pov.txt' (5 KB)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darn. I thought I fixed that. That's what I get for playing with the parser
without knowing what I'm doing. I'll work on it and get back to you soon.
-Nathan
Peter Popov wrote:
>
> Please see the attached code. Take special note on line 62. If you
> remove it or comment it, the parser gives an error. I have no idea
> why, but it seems like a parser bug.
>
> Peter Popov
> ICQ: 15002700
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Ok. I think I fixed it now. I'm going to wait to upload the new version,
though. If other people run into problems, I'll upload this fix, but I
want to check it out more first, since I'm not sure exactly how this part
of the parser works yet.
-Nathan
Peter Popov wrote:
>
> Please see the attached code. Take special note on line 62. If you
> remove it or comment it, the parser gives an error. I have no idea
> why, but it seems like a parser bug.
>
> Peter Popov
> ICQ: 15002700
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <37650b3a.4662718@news.povray.org> , pet### [at] usa net (Peter
Popov) wrote:
> Please see the attached code. Take special note on line 62. If you
> remove it or comment it, the parser gives an error. I have no idea
> why, but it seems like a parser bug.
>
>
> Peter Popov
> ICQ: 15002700
>
>#declare T_Wood34 =
>texture { T_Wood32 }
>texture {
> pigment {
> onion
> turbulence 0.2125
> colour_map {
> [0.225 colour rgbt <1.000000, 0.53333, 0.11767, 0.4875>]
> [0.350 colour rgbt <0.662750, 0.28617, 0.00001, 0.7250>]
> [0.500 colour rgbt <1.000100, 0.53333, 0.11765, 0.5745>]
> [0.625 colour rgbt <0.662775, 0.28627, 0.00005, 0.6875>]
> [0.750 colour rgbt <1.000200, 0.53333, 0.11755, 0.5275>]
> [0.875 colour rgbt <0.662755, 0.28629, 0.00001, 0.3795>]
> [1.000 colour rgbt <1.000000, 0.53333, 0.11665, 0.6165>]
> }
> scale <0.225, 0.20, 1.15>
> }
> }
Interesting, I didn't know that this was (ever) supposed to work at all (I
didn't miss the note of that exception the POV-Ray Docs, did I?). I
would say the parser is right...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: Tho### [at] csi com
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
That's how you do layered textures. And this parser keeps looking harder
and harder to fix. :-( ...and it looked so easy at first.
-Nathan
Thorsten Froehlich wrote:
> Interesting, I didn't know that this was (ever) supposed to work at all (I
> didn't miss the note of that exception the POV-Ray Docs, did I?). I
> would say the parser is right...
>
> Thorsten
>
> ____________________________________________________
> Thorsten Froehlich, Duisburg, Germany
> e-mail: Tho### [at] csi com
>
> Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3766F4D6.DFC19439@Kopp.com> , Nathan Kopp <Nat### [at] Kopp com>
wrote:
> That's how you do layered textures. And this parser keeps looking harder
> and harder to fix. :-( ...and it looked so easy at first.
Yes, layered textures _inside_ object declarations, but if I read this right
#declare T_Wood34 =
texture { T_Wood32 }
texture { ... }
should (or will) only declare
#declare T_Wood34 =
texture { T_Wood32 }
and I suppose that the parser complains about the second texture { ... } if
the #if .. #end isn't there. I would suggest to declare each of the
textures and then use each of them in the object which still gives a layered
texture.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: Tho### [at] csi com
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Thorsten Froehlich wrote:
>
> In article <3766F4D6.DFC19439@Kopp.com> , Nathan Kopp <Nat### [at] Kopp com>
> wrote:
>
> > That's how you do layered textures. And this parser keeps looking harder
> > and harder to fix. :-( ...and it looked so easy at first.
>
> Yes, layered textures _inside_ object declarations, but if I read this right
>
> #declare T_Wood34 =
> texture { T_Wood32 }
> texture { ... }
>
> should (or will) only declare
>
> #declare T_Wood34 =
> texture { T_Wood32 }
>
> and I suppose that the parser complains about the second texture { ... } if
> the #if .. #end isn't there. I would suggest to declare each of the
> textures and then use each of them in the object which still gives a layered
> texture.
>
> Thorsten
>
> ____________________________________________________
> Thorsten Froehlich, Duisburg, Germany
> e-mail: Tho### [at] csi com
>
> Visit POV-Ray on the web: http://mac.povray.org
Dating back at least as far as Pov v2.2 it has been valid to declare
textures as previously illustrated i.e.
#declare T1 =
texture { ... }
texture { ... }
object { thing texture { T1 }}
I have designed and used so many layered textures this way I can verify it's
legitimacy.
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Wed, 16 Jun 1999 16:35:20 +0200, Thorsten Froehlich wrote:
>In article <3766F4D6.DFC19439@Kopp.com> , Nathan Kopp <Nat### [at] Kopp com>
>wrote:
>
>> That's how you do layered textures. And this parser keeps looking harder
>> and harder to fix. :-( ...and it looked so easy at first.
>
>Yes, layered textures _inside_ object declarations, but if I read this right
>
>#declare T_Wood34 =
>texture { T_Wood32 }
>texture { ... }
>
>should (or will) only declare
>
>#declare T_Wood34 =
>texture { T_Wood32 }
From the documentation, the section on layered textures:
---------------
Layered textures may be declared. For example
#declare Layered_Examp =
texture {T1}
texture {T2}
texture {T3}
---------------
In fact, there are places you can't use a layered texture directly
but you may use a declared one. From the same page in the docs:
---------------
If you wish to use a layered texture in a block pattern, such as
checker, hexagon, or brick, or in a material_map, you must declare
it first and then reference it inside a single texture statement.
---------------
And here's the code from the parser, from parse.c in the function
Parse_RValue. The interior EXPECT loop takes care of any remaining
texture definitions after the first one, linking them to form a
layered texture.
---------------
CASE (TEXTURE_TOKEN)
Parse_Begin ();
Local_Texture = Parse_Texture ();
Parse_End ();
Temp_Texture=NULL;
Link_Textures(&Temp_Texture, Local_Texture);
Ok_To_Declare = FALSE;
EXPECT
CASE (TEXTURE_TOKEN)
Parse_Begin ();
Local_Texture = Parse_Texture ();
Parse_End ();
Link_Textures(&Temp_Texture, Local_Texture);
END_CASE
OTHERWISE
UNGET
EXIT
END_CASE
END_EXPECT
*NumberPtr = TEXTURE_ID_TOKEN;
Test_Redefine(Previous,NumberPtr,*DataPtr);
*DataPtr = (void *)Temp_Texture;
Ok_To_Declare = TRUE;
EXIT
END_CASE
---------------
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3767bb49@news.povray.org> , par### [at] fwi com (Ron Parker) wrote:
> From the documentation, the section on layered textures:
>
> ---------------
> Layered textures may be declared. For example
>
> #declare Layered_Examp =
> texture {T1}
> texture {T2}
> texture {T3}
> ---------------
>
> In fact, there are places you can't use a layered texture directly
> but you may use a declared one. From the same page in the docs:
>
> ---------------
> If you wish to use a layered texture in a block pattern, such as
> checker, hexagon, or brick, or in a material_map, you must declare
> it first and then reference it inside a single texture statement.
> ---------------
Aha, so I really missed that :-) Well, I don't use layered textures very
often...
> And here's the code from the parser, from parse.c in the function
> Parse_RValue. The interior EXPECT loop takes care of any remaining
> texture definitions after the first one, linking them to form a
> layered texture.
Makes sense. Thank you for the clarification.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: Tho### [at] csi com
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
I'm uploading the new patch now. Hopefully this one will really fix the
bugs. I put back the original #declare code, so all #declares should
have no problem. No guarantees with my new parser stuff (the $ and %
shortcuts) though.
-Nathan
Peter Popov wrote:
>
> Please see the attached code. Take special note on line 62. If you
> remove it or comment it, the parser gives an error. I have no idea
> why, but it seems like a parser bug.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |