References:

https://github.com/POV-Ray/povray/issues/467
"[BUG] doesn't give an error if a polygon is not 2D #467"

https://news.povray.org/povray.general/thread/%3Cweb.674a4c31296bdfa2e3cbe740b3ec8729%40news.povray.org%3E/
"polygon not visible"

While looking into a fix for the above issues in addition to extensions 
to the existing polygon object functionality, I found additional bugs 
and issues.

1) The automatic polygon closing feature creates confusing results as 
often as it helps. It only works somewhat well for single loops of 
points not yet closed.

2) In POV-Ray v3.0, the polygon object was re-written, substantially 
upgrading its capabilities. Some guessing here, but it looks like the 
effort started with an approach using a general projection of 3D polygon 
points onto the x-y plane. Though there has long been the restriction 
that the z values all be the same, the general code is still in there - 
and it doesn't always create a valid initial transform / 
inverse-transform 'transform structure'. In my testing it seems to 
always work where the loops are all triangles - which is a fair 
hint/guess as to what went wrong.

There are many rendering ameliorations which will lead to the bad 
transforms going unnoticed. In adding certain features to yuqk's polygon 
object I circumvented ALL of them. Users will mostly see things working. 
  Especially when working on the polygon as a single object in 
isolation. That said, I expect the bad transform the cause of some flaky 
results over the years.

Today, the only 3D flexibility is where all z coordinates being the same 
can indicate an offset along the z axis for the x-y plane - and this is 
the transform structure which should be created. For the inverse 
transform this a matrix:

   <1, 0, 0, 0>
   <0, 1, 0, 0>
   <0, 0, 1, 0>
   <0, 0, -z, 1>

and the transform matrix is:

   <1, 0, 0, 0>
   <0, 1, 0, 0>
   <0, 0, 1, 0>
   <0, 0, +z, 1>

The upcoming R17 (v0.6.11.0) of the yuqk fork hard codes these!

3) The 'transform structure' created by the v3.0 code has also been used 
to flip direction of the normal based upon point order. However, bugs 
aside, the transform creating code typically looks only at the first 
four points of the first loop. This is not enough to reliably determine 
the polygon's point loops rotation direction.

The standard method for this is a polygon area measuring algorithm often 
called the shoelace formula. Release R17 of yuqk moves to this method 
for setting the normal z direction.

4) There are a handful of checks in the code for the validity of polygon 
point description. Most all since v3.7 were quietly marking the polygon 
as an invalid shape which caused it to disappear. In the yuqk fork these 
checks now all generate parse time errors on such failures.

However, there is a fairly large set of possible degenerate polygon 
point descriptions for which there has never been any checking - and for 
which adding checking is a chunks of work. This remains a TODO item in 
the yuqk fork.

Bill P.

Post a reply to this message