 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 5-4-2024 om 13:02 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degroot org> wrote:
>
>> Hmmm... doesn't seem to be as /simple/ as that... Have you tried this? I
>> am getting nowhere [drives me crazy indeed]
>
> OK, I think you misunderstood what needed to be done.
>
Yes, I probably did ;-)
> Change the outside material {} wrapper to texture {}
> REMOVE all of the texture {} statements inside, leaving only the texture names.
>
OK
> That all works - the only thing I couldn't get to work is the Crand, because the
> #local/#declare thing in macros is still messed up.
>
Yes, that is the problem I am also (still) unable to solve in a
satisfying way, and in fact I referred to that in my post. Still
wondering about what I assumed in my answer to Alain Martel. Is this
Crand() macro construction defective in the texture macro compared to
the material macro, or is something else happening...?
>
>
> #version 3.8;
> global_settings {assumed_gamma 1}
>
> camera {
> location <0, 0, -5>
> right x*image_width/image_height
> up y
> look_at <0, 0, 0>
> rotate y*clock*360
> }
>
> sky_sphere {pigment {rgb 1}}
>
> light_source {<100, 100, -500> rgb 1}
>
> #include "Granite_Texture.mcr"
>
> #declare Tex = Granite_21 ()
>
> sphere {0, 1 texture {Tex}}
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 5-4-2024 om 13:02 schreef Bald Eagle:
> > Thomas de Groot <tho### [at] degrootorg> wrote:
> >
> >> Hmmm... doesn't seem to be as /simple/ as that... Have you tried this? I
> >> am getting nowhere [drives me crazy indeed]
> >
> > OK, I think you misunderstood what needed to be done.
> >
> Yes, I probably did ;-)
>
> > Change the outside material {} wrapper to texture {}
> > REMOVE all of the texture {} statements inside, leaving only the texture names.
> >
> OK
>
> > That all works - the only thing I couldn't get to work is the Crand, because the
> > #local/#declare thing in macros is still messed up.
> >
> Yes, that is the problem I am also (still) unable to solve in a
> satisfying way, and in fact I referred to that in my post. Still
> wondering about what I assumed in my answer to Alain Martel. Is this
> Crand() macro construction defective in the texture macro compared to
> the material macro, or is something else happening...?
>
> >
> >
> > #version 3.8;
> > global_settings {assumed_gamma 1}
> >
> > camera {
> > location <0, 0, -5>
> > right x*image_width/image_height
> > up y
> > look_at <0, 0, 0>
> > rotate y*clock*360
> > }
> >
> > sky_sphere {pigment {rgb 1}}
> >
> > light_source {<100, 100, -500> rgb 1}
> >
> > #include "Granite_Texture.mcr"
> >
> > #declare Tex = Granite_21 ()
> >
> > sphere {0, 1 texture {Tex}}
>
> --
> Thomas
One suggestion for future versions of POV-Ray might be to allow a mode where you
can essentially dump the results of parsing the scene as SDL with all macros
fully resolved. That way you can see exactly what the parser is doing with your
macros and help find syntax problems in them.
Back in my C programming days we had some developers who were heavy users of
C-style macros, so it was very difficult to map syntax errors from the compiler
back to their original C code. Fortunately, the C compiler separated out the
macro processor, so you could just run that to see the resulting pure C code and
find and fix the errors.
-- Chris R
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Question to BE:
Why has there to be at the end of the macro /twice/ an - exactly
identical - declaration of M_Granite? if you take out (any) one of them,
you get a parse error: "Cannot pass uninitialized identifier to
non-optional LValue."
Otherwise, works fine indeed.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 5-4-2024 om 16:12 schreef Chris R:
> One suggestion for future versions of POV-Ray might be to allow a mode where you
> can essentially dump the results of parsing the scene as SDL with all macros
> fully resolved. That way you can see exactly what the parser is doing with your
> macros and help find syntax problems in them.
>
Yes, that would be important indeed.
> Back in my C programming days we had some developers who were heavy users of
> C-style macros, so it was very difficult to map syntax errors from the compiler
> back to their original C code. Fortunately, the C compiler separated out the
> macro processor, so you could just run that to see the resulting pure C code and
> find and fix the errors.
>
Something like that is missing in POV-Ray I guess. It is often very
difficult to understand or relate an error message to the proper error.
See for instance this latest message I submitted to BE in the post above.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degrootorg> wrote:
> Question to BE:
>
> Why has there to be at the end of the macro /twice/ an - exactly
> identical - declaration of M_Granite? if you take out (any) one of them,
> you get a parse error: "Cannot pass uninitialized identifier to
> non-optional LValue."
>
> Otherwise, works fine indeed.
>
> --
> Thomas
I dunno - in the 10 minutes that furiously scribbled out that code this morning,
I was wondering the same thing.
All I did was edit the macro I have stored in my TdG directory, so you musat
have put it there for a reason.
This is why I have kept saying that there is some phantom bug that has crept
into the codebase that no one has recognized or isolated.
It would be interesting to see if the same thing happens when using 3.7 or even
3.6.
I would like POV-Ray to state exactly WHICH uninitialized identifier it's
talking about, so we lowly users can find the problem.
Maybe add some ifdef() statements in there to debug things and see what gives.
- BE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 05/04/2024 om 17:49 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Question to BE:
>>
>> Why has there to be at the end of the macro /twice/ an - exactly
>> identical - declaration of M_Granite? if you take out (any) one of them,
>> you get a parse error: "Cannot pass uninitialized identifier to
>> non-optional LValue."
>>
>> Otherwise, works fine indeed.
>>
>> --
>> Thomas
>
> I dunno - in the 10 minutes that furiously scribbled out that code this morning,
> I was wondering the same thing.
> All I did was edit the macro I have stored in my TdG directory, so you musat
> have put it there for a reason.
>
Checked: In the original code there was/is only one instance... ;-)
> This is why I have kept saying that there is some phantom bug that has crept
> into the codebase that no one has recognized or isolated.
>
I wonder at that too...
> It would be interesting to see if the same thing happens when using 3.7 or even
> 3.6.
>
I can check with 3.7. I do not have 3.6 installed any more (and not
going to).
> I would like POV-Ray to state exactly WHICH uninitialized identifier it's
> talking about, so we lowly users can find the problem.
>
Aaah... My wish exactly! So frustrating!
> Maybe add some ifdef() statements in there to debug things and see what gives.
>
I shall do my best. Will take some time as there are other issues
surfacing with this texture-based macro...
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degrootorg> wrote:
> Question to BE:
>
> Why has there to be at the end of the macro /twice/ an - exactly
> identical - declaration of M_Granite? if you take out (any) one of them,
> you get a parse error: "Cannot pass uninitialized identifier to
> non-optional LValue."
>
> Otherwise, works fine indeed.
>
> --
> Thomas
Now THAT is weird.
I "commented one out" using
#if (0)
#declare M_Granite =
texture {
//interior {ior 1.6}
#if (Pol) //polished
#if (Type=off)
T1_GranitePol
#else
T1_GranitePol
T2_GranitePol
#end //Type
#else //frosted
#if (Type=off)
T1_GraniteFro
//Crand(0.25)
//Tcrand
#else
T1_GraniteFro
T2_GraniteFro
//Crand(0.25)
//Tcrand
#end //Type
#end //Pol
scale M_scale
rotate M_rotat
translate M_trans
} //material
#end
And that worked just fine.
But when I highlighted all of that and deleted it, then I got the same weird
error.
If I use /* */ to comment it out, I get the error also.
Makes NO sense, and it's deeply concerning, because how is anyone supposed to
code anything if fundamental #declare statements simply don't work?
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> > Question to BE:
> >
> > Why has there to be at the end of the macro /twice/ an - exactly
> > identical - declaration of M_Granite? if you take out (any) one of them,
> > you get a parse error: "Cannot pass uninitialized identifier to
> > non-optional LValue."
> >
> > Otherwise, works fine indeed.
> > Thomas
>
> Now THAT is weird.
>
[snip]
>
> Makes NO sense, and it's deeply concerning, because how is anyone supposed to
> code anything if fundamental #declare statements simply don't work?
>
As an odd test, I ran your granite_texture.mcr.txt file (from one of the
earlier posts here) just by itself, no other code. As-is, it seems to run fine
when I remove one of the duplicate macro copies. I tested all three of your
attempted removal methods:
#if(0)...
/*...*/
deleting the duplicate
They all work OK, and I can't seem to make it fail! So maybe the fatal error--
whatever is causing it-- is only when the code is actually *used* elsewhere? Or
possibly due to a subtle error in that scene code?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 7-4-2024 om 16:38 schreef Bald Eagle:
> Now THAT is weird.
>
OK. "Solved" that one I guess.
I noticed earlier in the code provided by Chris, that /inside/ the
(sub-) macros he used a semicolon to end a texture. The original code of
the granite macro did not have those and - iirc - they were not used as
such any more since... POV-Ray 3.5? 3.6?
Anyway, you can safely delete one of the two M_Granite textures,
provided that you add a semicolon at the end of the declaration (and
before invoking the texture obviously) like this:
#declare M_Granite =
texture {
//interior {ior 1.6}
#if (Pol) //polished
#if (Type=off)
T1_GranitePol
#else
T1_GranitePol
T2_GranitePol
#end //Type
#else //frosted
#if (Type=off)
T1_GraniteFro
Crand(0.25)
//Tcrand
#else
T1_GraniteFro
T2_GraniteFro
Crand(0.25)
//Tcrand
#end //Type
#end //Pol
scale M_scale
rotate M_rotat
translate M_trans
} //texture
;
M_Granite
So that seems to be solved although I do not understand /why/ or
/how/... :-(
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/8/24 03:55, Thomas de Groot wrote:
> I noticed earlier in the code provided by Chris, that /inside/ the
> (sub-) macros he used a semicolon to end a texture. The original code of
> the granite macro did not have those and - iirc - they were not used as
> such any more since... POV-Ray 3.5? 3.6?
>
> Anyway, you can safely delete one of the two M_Granite textures,
> provided that you add a semicolon at the end of the declaration (and
> before invoking the texture obviously)
Hi.
FWIW. With my current yuqk fork(a) running what Bill posted, without the
second declaration of a M_Granite texture ID or the added semicolon, I get:
File 'granite_texture_1.mcr' line 580:
Parse Error:
Cannot assign uninitialized identifier 'M_Granite'
to non-optional LValue of:
'Tex'.
This error sometimes comes about due a prior, situationally, missing
semicolon.
Fatal error in parser: Cannot parse input.
Render failed
There are issues in all the recent parser variations with respect to
sometimes necessary, but missing semicolons. The yuqk fork has addressed
a few of them in its version of the parser, but certainly not all.
The worst cause flaky behavior during parsing without any notice
something has gone wrong.
Bill P.
(a) - A version compiled to allow lower case identifiers. Plus, I needed
to add the noise generator to use as the last argument to f_noise3d().
The inbuilt functions in official releases of POV-Ray always use noise
generator 2.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
