POV-Ray requires points in a polygon to be within
ZERO_TOLERANCE of
planarity, otherwise they are not drawn:

file polygon.cpp:

#define ZERO_TOLERANCE 1.0e-10
--------------------------------------
function Compute_Polygon:
   if (fabs(d) > ZERO_TOLERANCE)
    {
      Set_Flag(Polyg, DEGENERATE_FLAG);
     Warning(0, "Points in polygon are not co-planar.
Ignoring polygons.");
    }
--------------------------------------

In practice, this usually means that polygons with more than
three
corners have to be defined in a principal plane (one
coordinate =
zero).  Since I use general polygons in my software
(www.shapesoftware.com), POV-Ray often fails to draw them.

Actually, it does not appear that this degree of precision
is
necessary.  I changed the tolerance value to 0.0002 in the
above
instance, and have had no problems - all the polygons draw
OK.

I suggest that either a) the tolerance (in this one place)
be changed
to a more reasonable value, like 0.0002, or b) the user have
the
option of overriding the value.


Eric Dowty
dow### [at] shapesoftwarecom

Post a reply to this message

If you know your polygons aren't quite flat can't you just draw them as several
triangles?

I suspect increasing tolerance is a bad idea cause you'll start getting
artefacts under some circumstances. i.e. it worked fine for your purposes but it
might cause problems elsewhere.

Besides, surely triangles render faster because pov has good mesh optimisations?
--
Tek
http://www.evilsuperbrain.com


Eric Dowty <dow### [at] shapesoftwarecom> wrote in message
news:3e05fca2$1@news.povray.org...
> POV-Ray requires points in a polygon to be within
> ZERO_TOLERANCE of
> planarity, otherwise they are not drawn:
>
> file polygon.cpp:
>
> #define ZERO_TOLERANCE 1.0e-10
> --------------------------------------
> function Compute_Polygon:
>    if (fabs(d) > ZERO_TOLERANCE)
>     {
>       Set_Flag(Polyg, DEGENERATE_FLAG);
>      Warning(0, "Points in polygon are not co-planar.
> Ignoring polygons.");
>     }
> --------------------------------------
>
> In practice, this usually means that polygons with more than
> three
> corners have to be defined in a principal plane (one
> coordinate =
> zero).  Since I use general polygons in my software
> (www.shapesoftware.com), POV-Ray often fails to draw them.
>
> Actually, it does not appear that this degree of precision
> is
> necessary.  I changed the tolerance value to 0.0002 in the
> above
> instance, and have had no problems - all the polygons draw
> OK.
>
> I suggest that either a) the tolerance (in this one place)
> be changed
> to a more reasonable value, like 0.0002, or b) the user have
> the
> option of overriding the value.
>
>
> Eric Dowty
> dow### [at] shapesoftwarecom
>
>

Post a reply to this message

In article <3e05ff43$1@news.povray.org>, "Tek" <tek### [at] evilsuperbraincom> 
wrote:

> Besides, surely triangles render faster because pov has good mesh 
> optimisations?

Being well-optimized does not mean faster than everything else. The mesh 
optimizations are a huge benefit for large meshes, for very small ones 
they are mainly overhead, a simple union of triangles can be faster 
(though using "hierarchy off" could make the mesh faster again). For a 
polygon, the polygon primitive is the best primitive.

If the problem is just that numeric errors cause the points to be 
non-coplanar, it would probably be best to just project them to the 
right plane in POV. If a non-planar polygon is desired, the polygon 
object is just the wrong primitive.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

> If the problem is just that numeric errors cause the
points to be
> non-coplanar, it would probably be best to just project
them to the
> right plane in POV. If a non-planar polygon is desired,
the polygon
> object is just the wrong primitive.

> If you know your polygons aren't quite flat can't you just
draw them as several
> triangles?

I can get around this problem either by a) converting to
triangles or b) changing the tolerance in POV-Ray. So far, I
have not had any problem with either method.

Nevertheless, it is annoying to have to change methods and
write a new polygon-triangle conversion function, when this
appears to be unnecessary.  Again, I urge POV-Ray designers
to consider an optional variable tolerance, for the
following reasons.

There is no question that the currect tolerance is
unrealistically strict from a mathematical point of view,
when using 8-byte floating-point numbers.  Even if one
starts out with objects that are absolutely planar
(tolerance zero), one or two manipulations (rotation,
intersections, etc.) before input into POV-Ray can result in
violation of the planarity test.  At the least this
tolerance should be increased by a factor of 10.

"non-planar" and "polygons aren't quite flat" are dependent
on the tolerance.  I know that my polygons are planar within
tolerance about 1.0e-04 (my internal tolerance).  Tolerance
of 1.0e-10 is also excessive with respect to resolution of
current raster devices and the human eye.  Should the
tolerance be based on arbitrary machine precision, or
real-world factors?  Other 3D packages such as OpenGL and
QuickDraw3D are able to draw polygons without requiring
planarity within e-10.

Eric Dowty
dow### [at] shapesoftwarecom

Post a reply to this message

In article <3e087565@news.povray.org> , "Eric Dowty" 
<dow### [at] shapesoftwarecom> wrote:

>  Other 3D packages such as OpenGL and
> QuickDraw3D are able to draw polygons without requiring
> planarity within e-10.

Since when is POV-Ray a scanline renderer?  As both APIs are implement such
that they turn the polygons into triangles for you they hardly suffer from
degenerate input data.  It is much different for ray-tracing and the
algorithm used to calculate the polygon intersection.  If your modification
works 99% of the time that does not mean it is a good idea, just a
workaround for the degenerate input data.  And fixing your data is really
easy!


    Thorsten


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Tek <tek### [at] evilsuperbraincom> wrote:
> If you know your polygons aren't quite flat can't you just draw them as several
> triangles?

  Tesselating a free polygon is a problem in itself. If his program does
not support that, and he has concave polygons, implementing a working
tesselation algorithm can be quite laborious.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> As both APIs are implement such
> that they turn the polygons into triangles for you they hardly suffer from
> degenerate input data.

  It's true that OpenGL tesselates to triangles any polygon given to it.
This avoids degeneration problems, but is actually a bad problem with
respect to texturing. I don't know if there's *any* way around this
problem in OpenGL or other (simple) scanline rendering methods.
  The problem is illustrated eg. here:
http://www.cs.tut.fi/~warp/images/uvproblem.gif

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:

> It's true that OpenGL tesselates to triangles any polygon given to it.
> This avoids degeneration problems, but is actually a bad problem with
> respect to texturing. I don't know if there's *any* way around this
> problem in OpenGL or other (simple) scanline rendering methods.
>   The problem is illustrated eg. here:
> http://www.cs.tut.fi/~warp/images/uvproblem.gif
> 

But isn't that a problem only if no perspective correction takes place?
Or did I interpret the image wrong?

Post a reply to this message

Johannes Dahlstrom <sad### [at] tkukoulufi> wrote:
> But isn't that a problem only if no perspective correction takes place?
> Or did I interpret the image wrong?

  What in the image makes you (and 90% of other people as well) think
that that image has something to do with perspective? I can't understand
it.
  There's no perspective nowhere in the drawings. It's purely 2D.

  And even if there would be perspective there (which there isn't), why
would lack of perspective correction cause the artifact depicted there?

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp wrote:

>   What in the image makes you (and 90% of other people as well) think
> that that image has something to do with perspective? I can't understand
> it.
>   There's no perspective nowhere in the drawings. It's purely 2D.

Oh well, so I misinterpreted the drawings. Anyway, IMHO that particular 
kind of transformation does imply a perspective; it provides an important 
visual cue, as is seen in various illusions, such as here:

http://www.optillusions.com/dp/files/1-36.gif

And, although it is of course possible to map a texture like that, I'm not 
sure how common or useful it is. 

>   And even if there would be perspective there (which there isn't), why
> would lack of perspective correction cause the artifact depicted there?

Well, a triangle texture mapper without perspective correction interpolates 
linearly both in screen space and in texture space, and produces the 
artifact. This obviously isn't how perspective works - to produce the 
correct output, the mapper needs to interpolate inlinearly based on the 
triangle vertices' z coordinates. The artifact can be clearly seen in some 
old games such as Tomb Raider 2 or I-War, when run with software rendering.

Post a reply to this message

Johannes Dahlstrom <sad### [at] tkukoulufi> wrote:
> Oh well, so I misinterpreted the drawings. Anyway, IMHO that particular 
> kind of transformation does imply a perspective; it provides an important 
> visual cue, as is seen in various illusions, such as here:

  I don't follow you. Which transformation are you talking about? Why
do you keep talking about perspective when there's no perspective involved
anywhere in the drawings?

  The problem is simple: Take a four-sided polygon which is not
rectangular (but eg. trapezoidal as in the illustration), apply
UV-coordinates to the vertices of this polygon so that they map a
rectangle on the texture, and feed this to the OpenGL API.
  What OpenGL does is to divide the polygon into two triangles. Then the
3D hardware draws these two triangles independently, causing the deformation
of the texture depicted in the illustration.

  There's no perspective anywhere. There are no transformations anywhere.

> And, although it is of course possible to map a texture like that, I'm not 
> sure how common or useful it is. 

  You seem to misunderstand the problem completely.
  Of course it's very common to build a surface using quadrilaterals
(ie. polygons of four sides). For example if you build a torus with
quadrilaterals, you'll get the depicted problem with the texturing
(at the top and bottom of the torus).

> Well, a triangle texture mapper without perspective correction interpolates 
> linearly both in screen space and in texture space, and produces the 
> artifact.

  What is "the artifact"?
  Yes, it produces *an* artifact, which is completely different from what
is depicted in my illustration.
  In fact, even if that polygon was _rectangular_ and drawn in perspective
and even if it was made _without_ perspective correction, there would be
no visible artifact due to the texture in question. There would be a visible
artifact if the texture had horizontal lines (in which case they would be
mapped at equal distances throughout the polygon instead of decreasing
distance due to perspective).

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp wrote:
>   What in the image makes you (and 90% of other people as well) think
> that that image has something to do with perspective? I can't understand
> it.

I'am guilty, too.

>   There's no perspective nowhere in the drawings. It's purely 2D.

Now I get it!
Never thought of this problem before...

Sebastian H.

Post a reply to this message

Warp wrote:

>   I don't follow you. Which transformation are you talking about? Why
> do you keep talking about perspective when there's no perspective involved
> anywhere in the drawings?

Sorry, bad choice of word from my part, "mapping" would have been more 
adequate. What I meant was that there are two ways to interpret your 
drawing: Either

A) there is a tilted rectangular quad, or

B) there is a non-tilted trapezoidal quad. 

It is simply impossible to know which is the correct way to interpret it 
from the drawing only, without some depth information. The converging 
lines, however, give a visual cue which would suggest the case A. Human 
brains simply are wired that way, and this phenomenom is utilized in the 
illusion I posted a link to in my previous message.


>   The problem is simple: Take a four-sided polygon which is not
> rectangular (but eg. trapezoidal as in the illustration), apply
> UV-coordinates to the vertices of this polygon so that they map a
> rectangle on the texture, and feed this to the OpenGL API.
>   What OpenGL does is to divide the polygon into two triangles. Then the
> 3D hardware draws these two triangles independently, causing the
> deformation of the texture depicted in the illustration.
> 
>   There's no perspective anywhere. There are no transformations anywhere.

But my point was that it is impossible to see it from the drawing. I did 
some experiments with OpenGL, and the results are here:

http://koti.mbnet.fi/~sharlin/with_pc.png 
http://koti.mbnet.fi/~sharlin/without_pc.png

Without perspective correction (the second image) and without resorting to 
the texts, can you tell case A from case B? I don't think so. The texture 
mapper doesn't make a difference between them, because it isn't conserned 
about depth information if it doesn't do perspective correction.


>   Of course it's very common to build a surface using quadrilaterals
> (ie. polygons of four sides). For example if you build a torus with
> quadrilaterals, you'll get the depicted problem with the texturing
> (at the top and bottom of the torus).

OK, I see that with such round shapes it can be a problem. My bad.


>   What is "the artifact"?
>   Yes, it produces *an* artifact, which is completely different from what
> is depicted in my illustration.

Erm, no. As you can see from the aforementioned images, without perspective 
correction the two cases have the exactly same artifact, caused by exactly 
same thing: linear interpolation in texture space. Perspective correction 
does what it's meant to do: renders the perspective correctly. If it 
wouldn't, most 3D games would look very very ugly.

Post a reply to this message

Johannes Dahlstrom <sad### [at] tkukoulufi> wrote:
> What I meant was that there are two ways to interpret your 
> drawing: Either

> A) there is a tilted rectangular quad, or

> B) there is a non-tilted trapezoidal quad. 

  I see.

  Do you have any idea how that drawing should be done so that it doesn't
cause confusion?

> Erm, no. As you can see from the aforementioned images, without perspective 
> correction the two cases have the exactly same artifact, caused by exactly 
> same thing: linear interpolation in texture space. Perspective correction 
> does what it's meant to do: renders the perspective correctly. If it 
> wouldn't, most 3D games would look very very ugly.

  But the artifact which I'm talking about has nothing to do with perspective
correction, and using perspective correction does not affect the artifact
in question: It will still be there regardless of PC.

  There actually exists an algorithm to handle this problem, but I have never
heard that any 3D hardware supports this algorithm. The principle of the
algorithm is to perform a more complicated texture mapping.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp wrote:
> 
> Johannes Dahlstrom <sad### [at] tkukoulufi> wrote:
> > What I meant was that there are two ways to interpret your
> > drawing: Either
> 
> > A) there is a tilted rectangular quad, or
> 
> > B) there is a non-tilted trapezoidal quad.
> 
>   I see.
> 
>   Do you have any idea how that drawing should be done so that it doesn't
> cause confusion?

I can think of at least three -

1. Title it as a trapezoid.
2. Make the top length a bit shorter.
3. Draw a thick lined rectangle around the illustration.

-- 
Ken Tyler

Post a reply to this message

Shouldn't the distance between the coordinates of the texture be in
proportion to the coordinates in the polygon?

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3e0f4330@news.povray.org...
> Johannes Dahlstrom <sad### [at] tkukoulufi> wrote:
> > What I meant was that there are two ways to interpret your
> > drawing: Either
>
> > A) there is a tilted rectangular quad, or
>
> > B) there is a non-tilted trapezoidal quad.
>
>   I see.
>
>   Do you have any idea how that drawing should be done so that it doesn't
> cause confusion?
>

Post a reply to this message

Mike White <mik### [at] mindspringcom> wrote:
> Shouldn't the distance between the coordinates of the texture be in
> proportion to the coordinates in the polygon?

  Why should it?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3e104469@news.povray.org...
> Mike White <mik### [at] mindspringcom> wrote:
> > Shouldn't the distance between the coordinates of the texture be in
> > proportion to the coordinates in the polygon?
>
>   Why should it?
>

Isn't the idea to just lay a bitmap across a face?

What you're asking OpenGL to do is reshape the bitmap, something I doubt it
was designed for.

Post a reply to this message

Mike White <mik### [at] mindspringcom> wrote:
> What you're asking OpenGL to do is reshape the bitmap, something I doubt it
> was designed for.

  Well, if you do it with a triangle, it works flawlessly. The texture
will be stretched correctly.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp wrote:

>   Do you have any idea how that drawing should be done so that it doesn't
> cause confusion?

You could put some evenly-spaced horizontal lines to the texture - they 
would make a difference between the two cases: In the case B the mapping 
wouldn't change their mutual distances, whereas in the case A it obviously 
would (the lines "farther away" would be closer to each other).

Post a reply to this message

Johannes Dahlstrom <sad### [at] tkukoulufi> wrote:
> You could put some evenly-spaced horizontal lines to the texture - they 
> would make a difference between the two cases: In the case B the mapping 
> wouldn't change their mutual distances, whereas in the case A it obviously 
> would (the lines "farther away" would be closer to each other).

  What are the cases A and B you are talking about?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:

>   What are the cases A and B you are talking about?
> 

I was referring (a bit unclearly) to my previous message - case B is what 
you want, ie. the trapezoidal, non-tilted quad, and case A is the one with 
perspective.

Post a reply to this message