On Aug 15, 2016, at 1:32 PM, Juan Pablo Carbajal < address@hidden> wrote:
On Mon, Aug 15, 2016 at 8:57 PM, John Swensen < address@hidden> wrote:
On Aug 15, 2016, at 11:31 AM, PhilipNienhuis <address@hidden> wrote:
John,
It wasn't my intention to blame anyone :-) I just made the observation
that apparently some duplicate work has been done due to less than optimal
communications. From my side setting insufficient priority (due to lack of
time) is also to "blame"; probably the same goes for JuanPi. Well, that is
how it goes with volunteer projects.
However, the not-to-be-ignored upside of that is that we now have choice; we
can select the best solutions/implementations or make a combination of the
best ones.
I agree with what you wrote about polytri - AFAICS Matlab also suggests to
use poly2fv rather than polycut. I just "made" polycut.m because I already
had a similar implementation lying around. Initially I didn't even know
about the existence of polycut in TMW's mapping toolbox, I just found that
the use of branch cuts was one way of properly drawing of (nested) polygons
with holes and initially my sub-function for that job was called
"optimize_branch_cuts" (it is in shapedraw.m in the mapping package).
A remaining question for me is how to interpolate clipped Z-values. In my
work I often have "3D"-planes (e.g., polygons of semi-3D tiles of geological
strata) that I want to visualize in 3D views. I know that clipperlib can do
it using callbacks.
In a more general sense, unlike Matlab's mapping toolbox I'd like all
polygon functions in the mapping package to be able to handle semi-3D
polygons (i.e.,polygons with different Z-values for each vertex). Most of
what I have made already does so.
OK, as far as I'm concerned to be continued later this week,
Philip
--
View this message in context: http://octave.1599824.n4.nabble.com/GSoC-16-Boolean-Operations-on-Polygons-Merge-Code-to-geometry-Package-tp4679083p4679230.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.
I think that the Z-values for the vertices might be pretty simple with the Boost.Geometry solution. We can define the point model in any manner we want internally for use by the Boost algorithms. This could easily be adapted to include a Z-value. However, what you would probably need to give us is a specified algorithm for how to determine the Z-value of the output vertices of an operation, based on the Z-values of the inputs.
For example, if you are doing a difference between two polygons A and B as A-B, can you assume that all the vertices of A have the same Z-value and all the vertices of B have the same Z-value? Should the output of the A-B operation have the Z-values of A, the Z-valuse of B, or the average of the Z-values of A and B? I think that once the logic of how resultant Z-values are determined that the implementation should be pretty straightforward, even if it is don’t as a “post” step after the Boost.Geometry polygon operation.
The nice thing about using the Z-values is that we can just modify the various functions we have made (polyjoin, polysplit, poly2fv, polybool) so that they have an optional third parameter and will only include Z-values in the output if it included Z-values for the input.
John
Hi all, I think there is no sad thing about redundant functions. We should sort out whether we remove some of them or we make a frontend function to select them according to user's needs. Is poly2tri hosted somewhere (upstream)? if yes, then it is better to provide instructions to install it rather than to repack it inside geometry. Let see how fast we can merge all this neat work.
Unfortunately there are no packages for poly2tri in any of the major distributions. The project code was originally developed on code.google.com, which is now defunct. The original author transferred the repository to his Github account at https://github.com/greenm01. There haven’t been any updates in a couple of years on the main repository and a few on a branch at https://github.com/jhasse/poly2tri/commits/master that doesn’t some const parameter modifications, which I assume might allow the compile to optimize a little bit more.
We had included the source in the repository because it is only 12 files, but if you think we should pull it from Github as part of the build process, that is fine also.
Amr is working right now on making the configure check the version of Boost.Geometry that is available. His repository currently has the necessary Boost header files (Geometry is a header-only library) in his repository. He is working to just use the system Boost. The reason we are checking the Boost.Geometry version is: a) If the version is < 1.60, then the self-intersection correction is not supported b) If the version is > 1.60, we then will check if the dissolve algorithm is included in the library (currently not available in 1.60 or 1.61, but planned for some future release) c) If the version is > 1.60 and the dissolve algorithm isn’t in the system Boost.Geometry, include the dissolve.h and dissolver.h files that are part of the package. These have been extracted from the Boost.Geometry repository (but are not part of the release tarballs). I guess they don’t think the dissolve algorithm is robust enough yet, but we haven’t seen any problems in all our test cases.
John S. |