search

SebKuzminsky / pycam

Other
339 stars 99 forks source link

Python bindings for the clipper library #26

Open njh opened 7 years ago

njh commented 7 years ago

From the old MediaWiki WantedFeatures page

PyCAM uses some polygon-related code (e.g. for offsetting). The Clipper library fulfills all our needs, but its packaging is quite cumbersome. Anyway: it seems to be the only geometry library with a sane and usable license.

Tasks:

sumpfralle commented 7 years ago

Since the clipper library is available in Debian there should be no problem with the packaging, from my point of view. Regarding item (3) of your list: personally I would not like to bundle a library copy within pycam. A description of the requirements should be sufficient for potential packagers. Besides this I like your task list.

SebKuzminsky commented 7 years ago

I agree we should avoid forking external software into the pycam repo.

I'm focusing on the debian packaging of pycam, and there it's easy to pull in external libraries and other dependencies at install-time.

SebKuzminsky commented 6 years ago

Clipper/libpolyclipping looks good in many ways, however it has a limitation that I don't like: it apparently only handles straight lines, not arcs.

We could work around this by replacing arcs with linear splines, either on import or just before handing the polygon to libpolyclipping. But since we're evaluating our options, I think this is a point against libpolyclipping.

loluengo commented 5 years ago

Has anyone tried https://github.com/fonttools/pyclipper for this issue?

sumpfralle commented 5 years ago

Has anyone tried https://github.com/fonttools/pyclipper for this issue?

Indeed this is the base of the Debian package mentioned above. I just ticked this checkbox for the task list in order to avoid future confusion.

If anyone is willing to try to replace the current (horrible) polygon offsetting code with a function call to the clipper library, I would be happy and merge it. This change should not be overwhelmingly hard, I think. There was just no one to do it, up to now.

ebo commented 5 years ago

On Sep 24 2018 5:37 AM, Lars Kruse wrote:

Has anyone tried https://github.com/fonttools/pyclipper for this issue?

Indeed this is the base of the Debian package mentioned above. I just ticked this checkbox for the task list in order to avoid future confusion.

If anyone is willing to try to replace the current (horrible) polygon offsetting code with a function call to the clipper library, I would be happy and merge it. This change should not be overwhelmingly hard, I think. There was just no one to do it, up to now.

You might also want to research other options as well like python's Polygon (which provide bindings to gpc -- General Polygon Clipping Library by Alan Murta), and possibly others. It well may be that pyclipper is the best, but I do not know for sure what the costs/benifits might be with each library.

Hmmm.. just checked on something -- gpc is a lot more restrictive than we would want to go with, but here are some alternatives -- shapely, geos, cgal, pythonocc, and probably others as well.

Whatever you decide to use, do trace down the licenses and make sure there are no issues. Pyclipper is released under MIT, but the underlying library is released under Boost's license.

EBo --

sumpfralle commented 5 years ago

Regarding your suggestions: (gpc, shapely, geos, cgal, pythonocc): I added a separate issue (#128) for shapely, since its python bindings are packaged for Debian. If you think, other items from your list could be equally (or even more) suitable, then please open another issue and link it in the "summary" ticket (#114) for polygon offsetting.

Whatever you decide to use, do trace down the licenses and make sure there are no issues.

Indeed, this is important! Personally I usually just check, whether the package is packaged by Debian in the main archive. (for maintainability as well as for license compliance)

Pyclipper is released under MIT, but the underlying library is released under Boost's license.

Would you see a potential issue here? (with pycam being released under GPL3+)

ebo commented 5 years ago

On Sep 24 2018 7:18 AM, Lars Kruse wrote:

Regarding your suggestions: (gpc, shapely, geos, cgal, pythonocc): I added a separate issue (#128) for shapely, since its python bindings are packaged for Debian. If you think, other items from your list could be equally (or even more) suitable, then please open another issue and link it in the "summary" ticket (#114) for polygon offsetting.

ok. I may be looking into some of this for a work related issue, but it will be months if ever I get to this.

Whatever you decide to use, do trace down the licenses and make sure there are no issues.

Indeed, this is important! Personally I usually just check, whether the package is packaged by Debian in the main archive. (for maintainability as well as for license compliance)

maintainability is also a good point.

Pyclipper is released under MIT, but the underlying library is released under Boost's license.

Would you see a potential issue here? (with pycam being released under GPL3+)

To be honest I am not sure. I would simply suggest that if pyclipper is a serious candidate that GNU should be contacted to make sure that there are no problems with the chain of licenses. I simply do not know if they are truly compatible with GPL3+, and that is the point -- I would hate to depend on something and then have to deal with the headaches later.

sumpfralle commented 5 years ago

I simply do not know if they are truly compatible with GPL3+, and that is the point -- I would hate to depend on something and then have to deal with the headaches later.

Since you have no specific problems in mind, I am quite confident (based on my understanding of licenses), that there are no issues, since we are just depending (not mixing).

ebo commented 5 years ago

On Sep 24 2018 3:29 PM, Lars Kruse wrote:

I simply do not know if they are truly compatible with GPL3+, and that is the point -- I would hate to depend on something and then have to deal with the headaches later.

Since you have no specific problems in mind, I am quite confident (based on my understanding of licenses), that there are no issues, since we are just depending (not mixing).

Fair enough. I was just hoping to point out a due diligence point when people start looking forward for replacement libraries. I have seen this step missed and it wast a lot of time later.

If you do go with shapely, there might be some odd but fruitful imaging techniques that come out of the GIS and Earth Sciences world. I would have to cogetate on that a bit to explain the intuition, but keep in mind that shapely is used in GIS world all the time for calculating overlaps, distances, areas...

sumpfralle commented 5 years ago

If you do go with shapely, there might be some odd but fruitful imaging techniques that come out of the GIS and Earth Sciences world.

Just guessing: how about projecting a 2D engraving onto an arbitrary 3D object? :)

ebo commented 5 years ago

On Sep 24 2018 5:57 PM, Lars Kruse wrote:

If you do go with shapely, there might be some odd but fruitful imaging techniques that come out of the GIS and Earth Sciences world.

Just guessing: how about projecting a 2D engraving onto an arbitrary 3D object? :)

Arbitrary, no. Onto a sphere or elipsoid yes.

valeriob01 commented 5 years ago

2D engraving projected on a cylinder it becomes 3D ?

ebo commented 5 years ago

On Sep 25 2018 7:31 AM, valeriob01 wrote:

2D engraving projected on a cylinder it becomes 3D ?

Hmmm... not sure. I would have to think about it. In the GIS world maps and things are scalar fields (meaning x/y mapping with z heights).
This is inherently 2.5D -- no undercuts/overlaps, etc. So a 2.5D engraving projected on a sphere should be 3D, but GIS support tools would never look at the world in that way. For that you want either a CAD or Animation tool suite. Maybe what we should go to is a 3 or 4-D CAD representation (where offset lines are surfaces and/or volumes). It has been years since I lived in that world, and not sure what tools would provide the functionality. We could start a conversation about the mathematical background common to these perspectives, and what pycam could use, but that is a DEEP well best discussed over your favorite beverage.

valeriob01 commented 5 years ago

But in the G-Code world it requires 4 motors, XYZ and A axes, so yes, it is 4D.

ebo commented 5 years ago

On Sep 25 2018 12:36 PM, valeriob01 wrote:

But in the G-Code world it requires 4 motors, XYZ and A axes, so yes, it is 4D.

Well, if we wanted to look at it that way we could consider it 6-D (x/y/z row pitch yaw), BUT... if we can do it in 3, then we can map to the the machine dimensions.

valeriob01 commented 5 years ago

The machine dimensions correspond to the axes, more axes more dimensions. If you consider it 6D, the machine should be more like a robotic arm with 6 axes. I'm not sure you can reduce the number of dimensions with good CNC results.

ebo commented 5 years ago

I was referring to the dimensionality of the physical space, not the dimensionality of the motion space. Sorry I was not clear on that, and sorry for not being more careful. I will give some thought about the translation from 3D physical objects into individual axis/joint space (1D + time), but that is I think a common translation problem.

What I think started this possible misunderstanding was my allusion to there are lots of tools to manipulate geometric objects. GIS and map making tools see the world as inherently 2D, CAD systems see the world in 3D, and animation tools see the world as inherently 3D+ time. While one would think that the basic interface would stack, and I think they could be made to do so, the reality is that by the time you get all the way to 4D (animation) that the tools make it almost impossible to label things the way map makes want/need to manipulate the world. On the opposite spectum, you would be amazed on the monkeypuzzle people go through in the GIS world to represent 3D objects, or worse yet, use their output in animations.

For CNC work, we are smack in the middle of 3D CAD territory. As far as I know all of the libraries we have talked about up to this point are dealing with 2D surfaces (after slicing the 3D part), and the physical movement of the end of the tool corresponds to the contact points in the mapped 2D space. What I was trying to point out is that maybe we can find some libraries to do the offset surfaces volumetrically.

Uggg... I feel that I am being as clear as mud, and I have to rush off to get some things at the store and work...

On Sep 25 2018 10:37 PM, valeriob01 wrote:

The machine dimensions correspond to the axes, more axes more dimensions. If you consider it 6D, the machine should be more like a robotic arm with 6 axes. I'm not sure you can reduce the number of dimensions with good CNC results.

valeriob01 commented 5 years ago

Why not ?

https://yt-project.org/

ebo commented 5 years ago

On Sep 26 2018 5:40 AM, valeriob01 wrote:

Why not ?

https://yt-project.org/

Thank you for the pointer. I had never seen that before. Skimming the documents I do not see ready made examples demonstrating the functionality that is needed as I understand it. That said, looking a little into the details it is likely that it has the actual functionality required. Are you experienced with YT? If so, maybe we can come up with a couple of simple examples to try to process.

EBo --

valeriob01 commented 5 years ago

I just found it. Was unknown to me before.

ebo commented 5 years ago

On Sep 26 2018 5:49 AM, EBo wrote:

On Sep 26 2018 5:40 AM, valeriob01 wrote:

Why not ?

https://yt-project.org/

Thank you for the pointer. I had never seen that before. Skimming the documents I do not see ready made examples demonstrating the functionality that is needed as I understand it. That said, looking a little into the details it is likely that it has the actual functionality required. Are you experienced with YT? If so, maybe we can come up with a couple of simple examples to try to process.

after punching send I realized that there might be one issue with YT -- all the examples I see are voxel (3D array) based and not vector based.
I could be wrong there, but nothing is obvious. So if we went with YT we might have to maintain large volumetric arrays representing the material.

It is doable, but memory intensive. As a note, decades ago I once hacked together a simple path planner for milling traces in a surface mount PCB used for RADAR. The trace widths and lengths were generated by a model, and then the modeled actual traces left after machining were fed back into the model to see how it was predicted to behave with that exact circuit with the expected milled copper. It worked, but modeling the material at 0.000025" resolution took a bit of memory.

I am probably missing something, but I am begging to think that YT might not work. THat said it looks like a cool package, and I will try to break out some time to review it for work.

EBo --

valeriob01 commented 5 years ago

It isn't the only lib around, its just the first one that showed up in a google search.

ebo commented 5 years ago

On Sep 26 2018 8:11 AM, valeriob01 wrote:

It isn't the only lib around, its just the first one that showed up in a google search.

understood.