Nico wrote:
> 
> I get sources from povray site and compiled them on Mandrake 9.1 so it's 
> not really The official version but I did not tweak it either (just 
> compile it).
> Strangely enough, I do not get the bug using windows and windows 
> official binaries so it's certainly related to my compilation environment.

Please specify which compiler you are using (gcc version).  You should 
also try compiling without optimization.  If this is a bug it almost 
certainly is one of gcc and not of POV-Ray.

The obvious fix is of course to use the official binary.

Christoph

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

Post a reply to this message

I just tested the official linux binary and I still got the bug.

Hardware is:
Dell Precision 360

System is:
Mandrake Linux release 9.2 (FiveStar) for i586
Kernel 2.4.22-10mdkenterprise on an i686

Nico


Christoph Hormann wrote:
> Nico wrote:
> 
>>
>> I get sources from povray site and compiled them on Mandrake 9.1 so 
>> it's not really The official version but I did not tweak it either 
>> (just compile it).
>> Strangely enough, I do not get the bug using windows and windows 
>> official binaries so it's certainly related to my compilation 
>> environment.
> 
> 
> Please specify which compiler you are using (gcc version).  You should 
> also try compiling without optimization.  If this is a bug it almost 
> certainly is one of gcc and not of POV-Ray.
> 
> The obvious fix is of course to use the official binary.
> 
> Christoph
>

Post a reply to this message

I agree that it would make more sense to use a simple flat mesh.

Nico

Mael wrote:
> Using such a box is quite strange IMHO (but there might be a reason for it
> ?)..
> Try replacing it with a simple mesh with two triangles, something like
> 
>  mesh {
>      triangle { <0,0,0>, <1,0,0>, <1,1,0> }
>      triangle { <0,0,0>, <0,1,0>, <1,1,0> }
> 
> (not tested)
> 
> M
> 
>

Post a reply to this message

Nico wrote:
> 
> 
> I just tested the official linux binary and I still got the bug.
> 

Seems so, but as said compiling without optimization could solve the 
problem.  It does not occur in any of the versions i use, neither 3.5 
nor the current development version.

Christoph

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

Post a reply to this message

Nico wrote:
> 
> I agree that it would make more sense to use a simple flat mesh.
> 

just for the record: a zero height box is perfectly legal (if it was not 
it would be no problem for POV-ray to issue a parse error).  I think a 
box will also be somewhat faster than a mesh (although this is of course 
quite irrelevant here).

Christoph

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

Post a reply to this message

> Seems so, but as said compiling without optimization could solve the
 > problem.  It does not occur in any of the versions i use, neither 3.5
 > nor the current development version.
 >
 > Christoph


Ok, I got it wrong. I thought you were saying I should use the official 
version which I wrongly assumed was not optimized...

I will try to recompile without optimization as you suggested and see 
what happens. Does anyone else around got the problem when rendering 
"screen.pov" (from scenes/incdemo/screen.pov) ?

Nico

Post a reply to this message

Nico <rou### [at] loriafr> wrote:

> But when I render the screen.pov example file I get the attached image.

I get the same image in a MingW (gcc 3.2) compile. 
recompiling without -ffastmath fixes this.

Minimal scene that will show the bug:

//#declare epsilon = 0.000000000000001; // this works
#declare epsilon = 0;                   // this not
box {
 0, <1,1,epsilon>
 pigment {color rgb 0}
 translate <-0.5,-0.5,0>+2*z
 scale 0.02
}
background{color rgb 1}

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:

> just for the record: a zero height box is perfectly legal (if it was not 
> it would be no problem for POV-ray to issue a parse error).

But that doesn't mean that there isn't a problem with them in POV.
For example on infinitely thin boxes you get the interior_texture 
on the "outside".

Lutz-Peter

Post a reply to this message

So finally, is it a bug or not ? It's like at least that the official 
binary version for linux produces the "bug". So, even if it's slower, 
why not changing the zero thickness box to a square mesh or a very thin 
box that won't produce the weird behavior ?

Nico

Lutz-Peter Hooge wrote:
> Nico <rou### [at] loriafr> wrote:
> 
> 
>>But when I render the screen.pov example file I get the attached image.
> 
> 
> I get the same image in a MingW (gcc 3.2) compile. 
> recompiling without -ffastmath fixes this.
> 
> Minimal scene that will show the bug:
> 
> //#declare epsilon = 0.000000000000001; // this works
> #declare epsilon = 0;                   // this not
> box {
>  0, <1,1,epsilon>
>  pigment {color rgb 0}
>  translate <-0.5,-0.5,0>+2*z
>  scale 0.02
> }
> background{color rgb 1}

Post a reply to this message

Nico wrote:
> 
> So finally, is it a bug or not ? It's like at least that the official 
> binary version for linux produces the "bug". So, even if it's slower, 
> why not changing the zero thickness box to a square mesh or a very thin 
> box that won't produce the weird behavior ?
> 
> Nico

screen.pov renders fine on Linux for me. I'm running a self-compiled
version of POV-Ray 3.50c on Gentoo Linux. I compiled it using GCC
3.2. I had removed the -ffast-math flag a while back (via an
ebuild modification) because it was causing the dispersion bug
mentioned in this newgroup around March of this year. Perhaps the
official binary was compiled with GCC and the -ffast-math flag?
At any rate this seems like more of a GCC problem than a POV-Ray
problem.

-Roz

> Lutz-Peter Hooge wrote:
> 
>> Nico <rou### [at] loriafr> wrote:
>>
>>
>>> But when I render the screen.pov example file I get the attached image.
>>
>>
>>
>> I get the same image in a MingW (gcc 3.2) compile. recompiling without 
>> -ffastmath fixes this.
>>
>> Minimal scene that will show the bug:
>>
>> //#declare epsilon = 0.000000000000001; // this works
>> #declare epsilon = 0;                   // this not
>> box {
>>  0, <1,1,epsilon>
>>  pigment {color rgb 0}
>>  translate <-0.5,-0.5,0>+2*z
>>  scale 0.02
>> }
>> background{color rgb 1}
> 
>

Post a reply to this message