"Rob Wieringa" <robdotwieringaatphilipsdotcom> wrote in message
news:web.40eabddff0d40578bc37c6b0@news.povray.org...
> I've written a rather complex POV script, with a lot of macros.
> I get "arbitrary" errors, in the sense that the value of one of the
> variables is messed up, and an error test is hit. The example runs OK
as-is,
> but when I comment out the first macro (which isn't used in the reduced
> example), the behaviour changes, and the error is hit.
> Sometimes files become locked, and cannot be changed anymore, so I have to
> close POV. Any idea what's happening?
>
> I run POV 3.6 on Windows XP, PentiumIII, 256 MB RAM.
>
> I'll post the attachment to povray.binaries.scene-files

I just ran your script under 3.5 and 3.6 and confirm the behaviour is
different.  In fact, even your "as-is" example file which supposedly renders
without errors, renders a wrong graphic output in 3.6.  Take a look at the
top-middle of your output image, and you'll see a face that appears
"flipped" with a black hole next to it.  You can see in the graphic it just
doesn't look right in the rest of the pattern.  That doesn't appear in the
3.5 render.

It's as though variable pointers are getting out of whack in Povray.  The
float values in your array elements KL[0], KL[1], KL[2], KL[3], KL[4] change
depending on how many and what type of declarations are put in at the top of
the scene file.  I haven't tried figuring out how you set their values
though.

But, when uncommented only one line at any time, each one of these #declares
placed right at the beginning of the scene file caused differing and
repeatable values in the array of floats:

#macro MatRho4() #end
#declare Ohcrap = 1;
#declare Woohoo = <1,1,1>;
#declare Whatsit = "Yadda"
#declare Spong = sphere {0, 1 }
#declare Prang = sphere {0, 1 pigment {rgb 1}}

Even trying to see what's happening internally by adding a #debug concat
line like the following one in the Penta() macro changed the condition of
the float values in the array and even interacted with the above #declares
to produce yet different results again to the first set.

//#debug concat (str (KL[0],3,0), str (KL[1],3,0), str (KL[2],3,0), str
(KL[3],3,0), str (KL[4],3,0), "\n")

Everything seems to interfere with everything else.

Brian

Post a reply to this message