From: "Rob Wieringa" <robdotwieringaatphilipsdotcom>
Newsgroups: povray.general
Subject: bug in POV 3.6, possibly related to macro processing

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

Post a reply to this message

Rob Wieringa wrote:
> 
> I've written a rather complex POV script, with a lot of macros.
> I get "arbitrary" errors, [...]

The fact that the result changes when you comment out that macro is of 
course not good but apart from that the code is way too large to try 
tracking down the problem (it's not only in size but also the very ugly 
mixture of variables and parameters with diffferent scopes).  You will 
need to simplify it first.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> The fact that the result changes when you comment out that macro is of
> course not good but apart from that the code is way too large to try
> tracking down the problem (it's not only in size but also the very ugly
> mixture of variables and parameters with diffferent scopes).  You will
> need to simplify it first.
>
> Christoph
>
> --
> POV-Ray tutorials, include files, Sim-POV,
> HCR-Edit and more: http://www.tu-bs.de/~y0013390/
> Last updated 01 May. 2004 _____.//^>_*_<^/.______

Yes, I agree that the code is large and ugly. But I'm afraid that it is just
that complexity that causes the problems. Any attempt to simplify the code,
e.g. by adding globals in macros to the parameter list, expanding a macro,
or even adding a semicolon to an array declaration (I noticed that I didn't
provide those), changes the behaviour. At some points in the attempt to
simplify the code it simply hits an error condition, independent of the
presence of the first macro, so the demo effect is gone.

I'll try to do some more reduction, but really simple code you cannot
expect. All simple things work OK, as you might know.

Kind regards,
RobW

Post a reply to this message

Rob Wieringa wrote:
> 
> Yes, I agree that the code is large and ugly. But I'm afraid that it is just
> that complexity that causes the problems.

To be honest - if it is just this kind of obfuscation that causes 
problems it is not likely that anything will change about it.  Complex 
scripts with macros in general are not causing any trouble.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

"Rob Wieringa" <robdotwieringaatphilipsdotcom> wrote:

> Yes, I agree that the code is large and ugly. But I'm afraid that it is just
> that complexity that causes the problems. Any attempt to simplify the code,
> e.g. by adding globals in macros to the parameter list, expanding a macro,
> or even adding a semicolon to an array declaration (I noticed that I didn't
> provide those), changes the behaviour. At some points in the attempt to
> simplify the code it simply hits an error condition, independent of the
> presence of the first macro, so the demo effect is gone.

Have you considered doing most of the work of that script outside POV, say
in a language like Java or similar?

I too have a large and complex script that has developed interesting
problems in the move from 3.5 to 3.6 on Windows, including the locked-file
problem in the POVWIN editor, and tracking down the cause of the problem
has proved traumatic. I took it as a sign that I was trying to do too much
in POV for my SDL abilities, and am going to translate most of it to a
different language and output a simple POV file instead.

Post a reply to this message

"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