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