This is definitely some powerful stuff. I was finally able to get it going and created pockets from shapes that wouldn't be possible otherwise. Very cool.realthunder wrote:- Yes, of course. Path::FeatureShape is a quick demo of Path.fromShapes script function. I am waiting for the Path developer's response here.chrisb wrote:Impressive.
I currently have two questions:
- Do you plan an integration with the concept of jobs and the tool selection as they exists now?
- In the other post you said, that circles can only be approximated, does this mean that no G2 or G3 commands are created in GCode?
- The path generation uses the same libarea as the existing Path scripts. So, you will get all the G2 and G3 move as usual. What libarea does is to discretize all curves into line segments, do some processing, and fit back with arcs. The fitting of course is not perfect, but you can control the accuracy by tuning various parameters I exposed here.
Since chrisb immediately asked the question about integrating this into the rest of Path, let's talk about that. I'm of two minds about it and not sure about the best way to proceed.
I still feel pretty strongly that this isn't an end-user tool. It's a 'swiss army knife' for making paths but as a general-purpose tool it isn't optimized for any one task. It's absolutely chock-full of options and parameters that aren't self-explanatory or intuitive. (Reorient?, clip-fill? explode? coplanar?, open mode? join type?, thicken? to name just a few). That's not a criticism, it's just an observation. If we put a tool like this in the main workflow, we're going to have a lot of confused casual users showing up in the forum needing help and complaining. When I look at tools like Fusion 360, I see tons of options and settings that are similar to these but they are presented in an integrated and seamless way. The options that are important to pocketing appear in the pocketing context and are not present when the user is profiling.
Up until now, the user-facing functionality in Path has all been done in Python. The basic unit of work is the 'operation' and the context of the operation is the 'job'. Operations generally work on features of a base object (ie Faces, Profiles, holes, etc) I would suggest that what realthunder has built is more fundamental and needs to be integrated into the end user tools. For example, the pocket operation needs to be rebuilt to use the Path.Area strategies. In other words, I think it's a mistake to create a new tool that creates pockets in a different way rather than improve the existing pocket tool. The same thing is true for profiling, etc.
I said I was of two minds. My other thought is that we NEED a swiss army tool in Path. Advanced 'power users' will need to create unusual kinds of paths and having a general purpose tool is great. Even more importantly, the developers working on those end-user tools need something like this to explore the libarea options. So I think FeatureArea/PathShape should be further developed as a general purpose tool but NOT left on the main toolbar. Maybe we should add something like an 'advanced' menu item or an optional toolbar that is disabled by default. Basically hide the super-powerful tools from the novice users.
Another option would be something like a 'wizard' that takes the user through a set of dialogs to configure all the deep magic. I have no idea how such a thing would be built and I'm not really a fan of 'wizards' but some people like them.
Either way, I think we should merge as soon as possible and start figuring out how to make the UI / workflow as intuitive and simple as possible.
Realthunder, please don't 'lone wolf' this development. Path is a team effort and there's people who are good at UI/UX issues that can help.