On 2009-12-21 18:40-0800 Alan W. Irwin wrote:
> There are additional -DFILL_INTERSECTION_POLYGON=ON issues for page 3 and
> above of example 25, but I feel I am finally beginning to get close to the
> end of this mini-project.
Now that I have the basic recursive algorithm working (as of revision
Hi Alan,
that is great - the new code has the advantage of not involving a large
number of cases and convoluted computations, even though it is still
not trivial (understatement ;)), so that it ought to be easier to
maintain. I have sketched a nice polygon and will implement in example
25 somewher
On 2009-12-16 08:45+0100 Arjen Markus wrote:
> - The implementation may benefit (become simpler) if you can guarantee
> that the polygons are oriented in the same way (both clockwise for
> instance).
Hi Arjen (on list reply to your comment):
I originally thought polygons with the same orientat
On 2009-12-18 08:42-0800 Alan W. Irwin wrote:
> Well, the end phase is now implemented correctly (as far as I know), but
> there are some really obvious issues with the fill results for
> -DUSE_FILL_INTERSECTION_POLYGON=ON.
I spoke a bit soon there. I was referring to results on my own disk whic
On 2009-12-18 09:32+0100 Arjen Markus wrote:
> Hi Alan,
>
> from the SVN message I see that you have succeeded. I am going to
> study the source code and I will extend/modify example x25 to
> include some more challenging polygons, like the ones we discussed.
Well, the end phase is now implemente
Hi Alan,
from the SVN message I see that you have succeeded. I am going to
study the source code and I will extend/modify example x25 to
include some more challenging polygons, like the ones we discussed.
Regards,
Arjen
On 2009-12-17 07:12, Alan W. Irwin wrote:
> Hi Arjen:
>
> I have now deci
Hi Arjen:
For your information, I have figured out the final end phase logic where the
polygon 2 split and polygon 1 are known not to intersect each other.
"pointinpolygon" is fairly useless for sorting out the possibilities because
it makes no distinction between the test point being definitely o
Hi Arjen:
I think it is time to take our off-list conversation about a replacement for
the code in plP_plfclp back to the list.
For the others here, Arjen fixed all the fill issues shown by example 25,
but neither Arjen nor I were positive that the code in plP_plfclp would work
for an arbitrary p
Hi Alan,
thanks for looking into the cause - I saw that two of
the windows are empty in example x25c (on MS Windows),
but if it is a matter of edges, this is probably easier
to find in the code than some other issues I could think
of. Fixing them is another matter of course.
Regards,
Arjen
>
>
On 2009-11-27 11:22+0100 Arjen Markus wrote:
> Hi Alan,
>
> I had rather hoped I would not have to revisit that code ;), but
> I think you are right. I will have to look into the code of the
> example more closely, to see if it does what I intended it to do
> and if that is the case, then there sh
Hi Alan,
I had rather hoped I would not have to revisit that code ;), but
I think you are right. I will have to look into the code of the
example more closely, to see if it does what I intended it to do
and if that is the case, then there should not be any empty subwindows.
The next step is to see
Hi Arjen:
The x and y window limits for the 7th subpage (lower left) of each page of
example 25 are -20 to +20. i.e.,
xextreme[6][0] = -20.0; xextreme[6][1] = 20.0; yextreme[6][0] = -20.0;
yextreme[6][1] = 20.0;
For that case and for the diamond and reverse diamond cases (page 1 and 2)
you are
12 matches
Mail list logo
