On 06/05/2018 09:11 AM, clipka wrote:
> Am 05.06.2018 um 14:20 schrieb William F Pokorny:
>> On 06/04/2018 12:27 PM, clipka wrote:
>>> Am 04.06.2018 um 17:30 schrieb Le_Forgeron:
>>>> Le 04/06/2018 à 04:29, Hedrondude a écrit :
>>>>
>> ....
>>>
>>
>> I'd like to suggest, if we are looking at polygon enhancements -
>> canonical point ordering for fill options etc, we consider staying
>> compatible with packages like:
>>
>> https://sourceforge.net/projects/polyclipping/
>>
>> even if not looking to support that package specifically - though it
>> would be my choice at present.
> 
> I'm pretty sure we are /not/ currently compatible with any such package,
> so it's not a matter of /staying/ compatible, but /making/ our code
> compatible.

I was thinking up front about point order or winding (cw,ccw) directions 
and what they 'usually' mean - hole or not in the non-POV-Ray world - 
though should have stated that more explicitly. I've not spent time in 
the polygon code, but for prism and text I don't believe our current cw, 
ccw ordering today carries any particular hole, not-hole meaning. We use 
even/odd curve crossing tests to determine insides. If we adopt 
something with respect to ccw/cw point ordering, aligning with the most 
common - or perhaps even standard - definition makes sense(1). To be 
more compatible with external tools if nothing else.

There are filling options in polyclipping I've not really looked over as 
it was not my own up front first interest. Unsure if those follow some 
'standard/usual' approach.

As said above the winding order idea touches prism and text objects too. 
The latter I know from some performance code work I've done doesn't 
today match match all defined font curve overlapping behaviors - because 
we're not working with set cw/ccw winding definitions.

(1) - cw/ccw determination in degenerate polygon (badly defined point 
lists) can be impossible. Usually some polygon check and cleanup pass is 
done on the point list beforehand.

> 
> Given that our established data structure and algorithm for polygons is
> fine enough to accomodate for Density Filling, I see no reason to adapt
> our polygon code to any 3rd party package.
> 

Agree this feature does not drive a requirement for any external library.

> Unless of course there is some feature we really can't live without
> (hard-coded into POV-Ray, mind you, as opposed to implemented as some
> SDL macros) yet can't implement ourselves, but right now I don't see
> anything like that on the horizon.
>

Post a reply to this message