This is for Sam:

Using the proximity macro fastProx3() I get a parse error: ".... line 344: 
Parse Error: Cannot assign uninitialized identifier."

This corresponds to the code: #local pf=eval_pigment(fpt,<Xv,Yv,Zv>);  in 
the resample() macro.

No errors using fastProx() or fastProx2().

I am sure you know what went wrong (or what I do wrong for that matter).

My code line for this reads:
fastProx3(FinalBuilding, min_extent(FinalBuilding), 
max_extent(FinalBuilding), <10, 10, 10>, 2, 20, <2, 2, 2>)

-- 
All the best,

Thomas

Post a reply to this message

"Thomas de Groot" <tDOTdegroot@interDOTnlANOTHERDOTnet> wrote:
> This is for Sam:
>
> Using the proximity macro fastProx3() I get a parse error: ".... line 344:
> Parse Error: Cannot assign uninitialized identifier."
>
> This corresponds to the code: #local pf=eval_pigment(fpt,<Xv,Yv,Zv>);  in
> the resample() macro.
>
> No errors using fastProx() or fastProx2().
>
> I am sure you know what went wrong (or what I do wrong for that matter).
>
> My code line for this reads:
> fastProx3(FinalBuilding, min_extent(FinalBuilding),
> max_extent(FinalBuilding), <10, 10, 10>, 2, 20, <2, 2, 2>)
>
> --
> All the best,
>
> Thomas

This probably won't help you much but I had the exact same error for fast sss2
in fastprox.inc, yet using Blend2Pov so your problem and workaround could be
totally different:
My problem was that I was referring to "Final Building" before it was really
defined regarding the order in which things are parsed.
So what I did was call the macro inside the object block (Povmat text file in
blend2Pov)Also I needed the lpos variable (light position) so I made sure its
definition was done before the call too.

Post a reply to this message

Thomas de Groot wrote:
> This is for Sam:
> 
> Using the proximity macro fastProx3() I get a parse error: ".... line 344: 
> Parse Error: Cannot assign uninitialized identifier."

Is that in line 344 of my code or yours?

> I am sure you know what went wrong (or what I do wrong for that matter).

No, I have no clue. I typed up this test and it parsed and rendered just 
fine in both 3.6 and 3.7b:

#include"fast_prox02.inc"

#declare FinalBuilding=
union{
  box{-1,1 scale<4,2,2>}
  box{-1,1 scale<2,4,2>}
  box{-1,1 scale<2,2,4>}
}

object{
  FinalBuilding
  pigment{
   fastProx3(
    FinalBuilding,
    min_extent(FinalBuilding),
    max_extent(FinalBuilding),
    <2, 2, 2>, 4, 20, <1, 1, 1>*8
   )
   color_map{[.25 rgb 0][1 rgb 1]}
  }
}

Run that code to see if you still have problems. I'll try to keeping 
helping until it works for you, if you wish.

Happy Povving :)

Sam

Post a reply to this message

Sam, Thank you for your answer.

I got the clue when I saw that the error referred to eval_pigment, and the I 
realized I had not included functions.inc!!!!

Aaaaarrrgh........ [hides deep below ground in full shame]

Thomas

Post a reply to this message

Thomas de Groot wrote:
> Sam, Thank you for your answer.
> 
> I got the clue when I saw that the error referred to eval_pigment, and the I 
> realized I had not included functions.inc!!!!
> 
> Aaaaarrrgh........ [hides deep below ground in full shame]

It sounds like the fault is mine; I forgot to mention the functions.inc 
requirement...

Post a reply to this message

> It sounds like the fault is mine; I forgot to mention the functions.inc 
> requirement...

#ifndef (Functions_Inc_Temp) #include "functions.inc" #end

That way you don't need to remember the dependencies.

Post a reply to this message

Tim Attwood wrote:
>> It sounds like the fault is mine; I forgot to mention the 
>> functions.inc requirement...
> 
> #ifndef (Functions_Inc_Temp) #include "functions.inc" #end
> 
> That way you don't need to remember the dependencies.

Thanks!

Post a reply to this message

Tim Attwood schrieb:
> #ifndef (Functions_Inc_Temp) #include "functions.inc" #end

Why not include it unconditionally?

You don't lose much parsing time, and the functions.inc code is 
/designed/ to be robust against multiple inclusion.

Post a reply to this message