 |
|
|
|
|
|
| |
| |
|
|
From: Nico
Subject: Wood texture (108k) and possible "screen.inc" bug.
Date: 12 Dec 2003 08:13:46
Message: <3fd9bf0a@news.povray.org>
|
|
|
| |
| |
|
|
Hi,
I did some experiments on procedural wood texture and here is the
resulting image (I used glass from Jaime Vives Piqueres website).
I got problem ("coincident surface like" bug) when I tried to
incorporate some information onto the image using "screen.inc" and
particularly the Screen_Plane macro. Here is the original macro:
#macro Screen_Plane (Texture, Scaling, BLCorner, TRCorner)
box {
<-0.000001,-0.000001,0>, <+1.000001,+1.000001,0>
...
This is basically a box with no thickness. Is that intended or is my
file somehow out of date ?
Anyway, I had to slightly modify it to get clean color bands:
#macro Screen_Plane (Texture, Scaling, BLCorner, TRCorner)
box {
<-0.000001,-0.000001,0>, <+1.000001,+1.000001,0.000001>
...
I can post image sources if anyone interested.
Nico
Post a reply to this message
Attachments:
Download 'glass.jpg' (106 KB)
Preview of image 'glass.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nico wrote:
>
> #macro Screen_Plane (Texture, Scaling, BLCorner, TRCorner)
> box {
> <-0.000001,-0.000001,0>, <+1.000001,+1.000001,0>
> ...
>
> This is basically a box with no thickness. Is that intended or is my
> file somehow out of date ?
This is intended and works without problems. If you make the thickness
non-zero you will have two 'planes'.
>
> I can post image sources if anyone interested.
The wood would be interesting.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
Very nice wood ! I love those warm colors ..
(sorry never used screen.inc so i can't help)
M
Post a reply to this message
|
|
| |
| |
|
|
From: Severi Salminen
Subject: Re: Wood texture (108k) and possible "screen.inc" bug.
Date: 12 Dec 2003 10:12:38
Message: <3fd9dae6@news.povray.org>
|
|
|
| |
| |
|
|
> I can post image sources if anyone interested.
I'd like to see the source for your good looking wood material.
Severi Salminen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
But when I render the screen.pov example file I get the attached image.
I used povray 3.5 under linux with following command:
povray +Iscreen.pov +w640 +h480 +P
I posted the sources for wood to povray.text.scene-files
Nico
Christoph Hormann wrote:
> Nico wrote:
>
>>
>> #macro Screen_Plane (Texture, Scaling, BLCorner, TRCorner)
>> box {
>> <-0.000001,-0.000001,0>, <+1.000001,+1.000001,0>
>> ...
>>
>> This is basically a box with no thickness. Is that intended or is my
>> file somehow out of date ?
>
>
> This is intended and works without problems. If you make the thickness
> non-zero you will have two 'planes'.
>
>>
>> I can post image sources if anyone interested.
>
>
> The wood would be interesting.
>
> Christoph
>
Post a reply to this message
Attachments:
Download 'screen.jpg' (57 KB)
Preview of image 'screen.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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:
>
> But when I render the screen.pov example file I get the attached image.
> I used povray 3.5 under linux with following command:
> povray +Iscreen.pov +w640 +h480 +P
Do you use the official version? I don't get this effect here.
> I posted the sources for wood to povray.text.scene-files
Thanks.
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 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.
Does anyonbe else got the bug under linux ?
Nico
Christoph Hormann wrote:
> Nico wrote:
>
>>
>> But when I render the screen.pov example file I get the attached image.
>> I used povray 3.5 under linux with following command:
>> povray +Iscreen.pov +w640 +h480 +P
>
>
> Do you use the official version? I don't get this effect here.
>
>> I posted the sources for wood to povray.text.scene-files
>
>
> Thanks.
>
> Christoph
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] loria fr> 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
|
|
| |
| |
|
|
|
|
| |
