|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |