Jim Charter <jrc### [at] msncom> wrote:
> Charles C wrote:
>
> >
> > Note: There seems to be something in both 3.6 & 3.7 beta which kicks in an
> > error "Parse Error: Identifier expected, incomplete function call or spline
> > call found instead."  The line in question may look something like #local
> > Spline_A = Array_of_Splines[Ctr]; or be a line calling a macro using a
> > spline identifier as one of the parameters.  It will work many times over
> > in a loop, but may fail at some repeatable time during the overall parsing.
> > Repeatable IF it's on the same machine.  Adding something like #local
> > dummy_var = 97981316123; either inside or outside the loop seems to affect
> > whether the render will get through parsing.  I'm always happy to see the
> > Render Cleanup Warning about the experimental status of splines because
> > that means it's made it through.
> >
> >
> Yes. That is the error that drove me crazy with my spider web images.
> And I was also using both the techniques you mention, passing a spline
> to a macro, and storing spline definitions as arrays.  And as you say,
> the stoppage would appear capriciously, though always at the same place
> until I changed something about the code, adding a #debug for instance,
> or changing the seed value for the random number generation.
> Furthermore, since I was trying to make different variations of webs I
> was running the scene file from an ini file repeatedly by using the
> animation feature so as to begin with a different random seed each time
> (based on the clock value). The scene would parse fine through many
> repetitions before finally failing.  I was not able to produce the error
> in isolation by using just the macro call or the array storage.
> Further, my current version uses both these techniques in combination
> and I have run it through several hundred iterations with a stoppage.
> But if I add further complexity, a second set of splines stored as an
> array, for instance, then the error recurs.
>
> I suspect it is something about the splines-stored-as-arrays that is the
> problem because of the fact that adding random lines of script will
> sometimes "solve" it or cause the stoppage to happen in a different
> place.  I also had this problem when I was doing my POVCOMP entry.  My
> solution then, if I remember correctly, was to write the multiple spline
> definitions to include files then call them in dynamically.
>
> I use MegaPov 1.1 which is based on POV-Ray 3.6.1


I think I posted something about this a few months ago too & I think I
remember saying I was glad at least I'm not alone. :-)  I have to put down
a correction - I think it doesn't apply to 3.7.  Also, where I said
"Repeatable IF it's on the same machine," I had made a mistake also... It
had to do with the fact that I had a lot of SDL generated-files on one
machine and not on the other.  My scene was smart enough to re-generate
them but that puts more code in front of the iffy-areas and that of course
changes whether it'll make it through those iffy-areas or not.  If those
files had been available, the conditions would have been the same and I
wouldn't have found myself tweeking non-funtional code.

Anyway, when it can take half an hour, an hour, or more of playing with
non-funtional code for every modification of funtional code, I think what
I'm working on is to the point where I can't continue on it in a practical
way without a fix.

I guess I'm just addicted to splines - using too many of them ;)

Charles

Post a reply to this message