So I’ve started to make some benchmark comparisons between the two after this
The first impressions are.. “it’s a hell, guys”
Minkowski sum/difference: Clipper2GH is clearly 6.3x faster. It has an option to keep open curves open, which the other has not. But mirrors the curves around XY plane (?). Clipper does not show this bug, and apparently there is no difference between Sum and Displaced Sum
Clipper2GH: it doesn’t automatically convert and accept the given Degree2 curves, they need to be explicitly converted. The sum is “in place” meaning that it phisically represents the envelope of one shape moved about the path. Clipper: it automatically accepts the given curves doing an implicit conversion, the result is out of place, like in Wikipedia’s example. Perhaps mathematically correct, but not so much intuitive and of practical use as is. Again no difference between the two results.
As said before, each has many differences, pro/cons, and bugs. This confirms my idea that still today there is no unique best implementation of Clipper and it is a shame.
It is still a problem, for me, to deal with this plugin which I truly need.
Other major bugs found:
1- offset does not deal well with branches having lists n>1 and Planes specified for each branch. It messes up the logic of branch-branch association
2-Minkowski sum: also messes up in the same condition, flips about the XY plane (why?) and flattens all results to an horizontal plane while the input was all in well defined inclined planes. It is a mess.
The plugin has been updated once this year, with no details about the updates, while its GIThub shows no updates since 3 years, and one issues posted by me still unanswered. And it is still using, probably, old versions of Clipper2 libraries.
Is there anyone willing to pick up the project from where it is and create a new branch resolving the most evident issues and create a clean, updated new release?
Because I can’t believe I am the only person in need of using Clipper2 libraries into Grasshopper.
What I just wanted to do in this case is to sweep those polygons along the given lines using Minkowski Sum, using the correct planes specified. I get instead the weird result highlighted in green
I understand the solutions you propose and I see I have rushed to some conclusions, sorry for that. Partially due to the lack of documentation (common to the majority of plugins) which often leads to misunderstandings.
From what I see, it just seems that the actual features/missing capabilities of the plugin are due to the lack of feedback. I will try to use the support email for that.
But there is one aspect I don’t agree in your soultion, and the current behaviour of other GH Components and the general data tree rules confirm my opinion
The inputs for the offset should not be grafted. The data tree rules work on a branch-branch association. If the inputs have the same branch count (and structure level) the components runs multiple times on every branch-branch association. In my case, there is an exact correspondance, the only peculiarity is that the curves input may have multiple elements on some branch.
The standard offset command, for instance, works just fine and provides a result which replicates the same structure of the input, aside from the addition of a new graft level to account for the multiple results. As you can see from the viewers, the tree structure is independent of the number of elements on each branch, and a component should act according to the tree structure, not to the branch’s content length. Am I wrong?
