I did a little test rendering with a scene containing about 53 meg (peak
memory used) of mostly meshes & spheres dotted along splines... (many
splines.)

There are 3 versions of the main scene file used:  The original on the p3
laptop, and a 2nd version which has no functional changes but many of the
original's non-functional lines like "#declare dummy_var = -1;" modified
with different float values to get it to work on the core2duo machine. (See
note)  The 3rd version is identical to the 2nd except for the name so that I
could render two instances at once.  All #includes are identical.

All are 800x600 +a0.3, none using 64bit versions:
   TIME   Ver          Proc
A) 51:28  3.6          pentium 3m 1ghz  (no real surprise here)
B) 6:35   3.7 b18      E6700 @3.2
C) 5:38   3.6          E6700 @3.2
D) 6:38   3.7 b18      E6700 @3.2 re-rendered
E) 6:06   3.7 b18 sse2 E6700 @3.2
F) 5:07   3.7 b18 sse2 E6700 @3.2 with +bm2
G)16:19   3.7 b18 sse2 P4 3.6 w/HT (prescott) with +bm2
H)13:32   3.6          P4 3.6 w/HT (prescott)

The following two renders were "something.pov" and "Copy of something.pov"
started in two separate instances of 3.6 within 2 seconds of each other.:

I) 5:26   3.6          E6700 @3.2
J) 6:20   3.6          E6700 @3.2

Done again:
I) 6:33   3.6          E6700 @3.2
J) 5:49   3.6          E6700 @3.2


A two-instance rendering with 3.7:
K)13:01   3.7 b18 sse2 E6700 @3.2 with +bm2
L)13:05   3.7 b18 sse2 E6700 @3.2 with +bm2

My overall conclusion is that I have one of those scenes which 3.7 doesn't
handle as quickly as 3.6.  It's interesting how much more striking the
difference between 3.6 & 3.7 is on the core2 than the prescott.  I haven't
tried 3.7 on the p3.



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.

Post a reply to this message

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

Post a reply to this message

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