filled non-convex polygon disappears when rotated

[Paul Hahn]

I have a weird problem that seems specific to using fl_begin/end_polygon() with fl_vertex() to draw a non-convex polygon (i.e., a filled "+" marker). With zero degrees rotation, the polygon appears. But application of a rotation angle not a multiple of 90 degrees results in nothing visible.

In contrast, when using fl_begin/end_loop() with fl_vertex() to draw the outline for the same polygon, the polygon (boundary) appears reliably, no matter what the rotation angle.

When I repeat the experiment with other kinds of (convex) filled and rotated polygons, there are no problems.

This is the first time I have tried to use fl_begin/end_polygon(). I am motivated by the need to do rotations on the filled polygon. I figure I am doing something wrong but I do not know what. I have tried to double-check that I do not have some kind of problems with the vertices -- seems OK.

I have attached a file to demonstrate the problem. If anyone is patient enough to check into this and help, I would really appreciate it.

[Paul Hahn]

I forgot to mention I am using FLTK bleeding edge 1.4. My platform is CentOS 6 Linux on Intel Xeon machine, g++ version 5.1. I have not tested for the problem on any other FLTK version or platform.

[imm]

Paul,

On the basis of not having tried, or even looked at, your code (I'm on my phone today...) my initial reaction is to check the winding order of your polygon.

I can't remember if fltk winds clockwise or anticlockwise, but I know I've been caught by that in the past, since that defines whether right or left of the line is "inside" the polygon for filling.

--
Ian
From my Fairphone FP3
   

[imm]

Actually... Thinking about this again... I wonder if you need to use fl_begin_complex_polygon & etc. rather than just fl_begin_polygon for concave shapes?

ISTR that is maybe the case, as I think that's where the winding order comes into play.

It's been a while since I've tried this!

[Paul Hahn]

On Saturday, October 24, 2020 at 9:24:24 AM UTC-5 Ian MacArthur wrote:

Actually... Thinking about this again... I wonder if you need to use fl_begin_complex_polygon & etc. rather than just fl_begin_polygon for concave shapes?

OK I just tried fl_begin/end_complex_polygon and it WORKS! Thanks!

 

ISTR that is maybe the case, as I think that's where the winding order comes into play.

It's been a while since I've tried this!

 

BTW my winding order is CCW. I can also go back and try CW winding order with the fl_begin/end_polygon and see if that works.

Probably I missed something in the doco about needing to use fl_begin/end_complex_polygon for this (rotated, concave, CCW) situation. But the interesting thing is that fl_begin/end_polygon did in fact work for this when the rotation angle was zero(???)

[Paul Hahn]

Yep, you are right -- the doco mentions fl_begin/end_polygon works for CONVEX polygons, and fl_begin/end_complex_polygon works for CONCAVE polygons (also). I apologize for not paying attention to this initially. BTW winding order is addressed in a note for fl_begin/end_complex_polygon, but for fl_begin/end_polygon (convex case), I see no mention of a constraint for CCW vs. CW traversal.

[Ian MacArthur]

On 24 Oct 2020, at 16:29, Paul Hahn wrote:
>
> Yep, you are right -- the doco mentions fl_begin/end_polygon works for CONVEX polygons, and fl_begin/end_complex_polygon works for CONCAVE polygons (also). I apologize for not paying attention to this initially.

Well, so long as it is working now, that’s all good.

> BTW winding order is addressed in a note for fl_begin/end_complex_polygon, but for fl_begin/end_polygon (convex case), I see no mention of a constraint for CCW vs. CW traversal.

I don’t know the specific implementation in fltk, but for a figure that is “known" to be convex you can reliably infer “inside” and “outside” of the polygon without that, so that may be the way it works. And why you need to use “complex_polygon” for the concave figures, of course.

As to why the “+” polygon works in the orthogonal cases, I imagine that’s just an edge case... probably...!