#4828 PartDesign: inverse for pocket

Post here if you have re-based and finalised code to integrate into master, which was discussed, agreed to and tested in other forums. You can also submit your PR directly on github.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: #4828 PartDesign: inverse for pocket

Post by adrianinsaval »

jonasb provided a good example just above... when the profile for the pocket is not a sketch it's not such a trivial matter. But in general, just because you personally don't need something does not mean it's not worth having.
wsteffe
Posts: 461
Joined: Thu Aug 21, 2014 8:17 pm

Re: #4828 PartDesign: inverse for pocket

Post by wsteffe »

adrianinsaval wrote: Wed Mar 22, 2023 12:23 pm just because you personally don't need something does not mean it's not worth having
I didn't say I don't want it. Just asked to better understand the need.

Anyway I think that to implement it you have to copy the given sketch into a new temporary sketch. Then you have to add an outer rectangle defined as a two dimensional bounding box of sketch+projected base feature +margin. The temporary sketch is used for a normal pocket and deleted after this operation.

But I do not know if this solution can be made safe regarding TPN.
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: #4828 PartDesign: inverse for pocket

Post by adrianinsaval »

TNP does not play a role here beyond what it already does for the current pocket operation, a bounding box would be calculated referencing the entire base feature and profile not some topology element.
racemaniac
Posts: 52
Joined: Sat Nov 30, 2019 7:45 am

Re: #4828 PartDesign: inverse for pocket

Post by racemaniac »

I stumbled on this discussion since i was also hoping for this feature, and nice to see it's being worked on.

I now see the suggestion isn't doing an intersection, but doing a cut with the 'reverse' of the sketch (and i saw the examples why, makes sense to me :) ).

For implementation, the current idea is to generate something around the sketch that's also beyond the bounding box of the object you'll be working on, and i was wondering if splitting the object at the plane where your operation ends, and beyond that plane keep the original object, before that plane do the intersection, and the resulting object is the union of both parts. Wouldn't that be an easier implementation?
user1234
Veteran
Posts: 3339
Joined: Mon Jul 11, 2016 5:08 pm

Re: #4828 PartDesign: inverse for pocket

Post by user1234 »

racemaniac wrote: Thu Mar 23, 2023 1:17 pm For implementation, the current idea is to generate something around the sketch that's also beyond the bounding box of the object you'll be working on, and i was wondering if splitting the object at the plane where your operation ends, and beyond that plane keep the original object, before that plane do the intersection, and the resulting object is the union of both parts.
This is exacly what i also suggest, and this as option in a common operation (for all PD operations).


Greetings
user1234
racemaniac
Posts: 52
Joined: Sat Nov 30, 2019 7:45 am

Re: #4828 PartDesign: inverse for pocket

Post by racemaniac »

user1234 wrote: Thu Mar 23, 2023 4:51 pm
racemaniac wrote: Thu Mar 23, 2023 1:17 pm For implementation, the current idea is to generate something around the sketch that's also beyond the bounding box of the object you'll be working on, and i was wondering if splitting the object at the plane where your operation ends, and beyond that plane keep the original object, before that plane do the intersection, and the resulting object is the union of both parts.
This is exacly what i also suggest, and this as option in a common operation (for all PD operations).


Greetings
user1234
Yeah, that was also part what i was hoping for, make one button for the operation, and then select how you want to apply it (pad/pocket/intersect), would seriously reduce the amount of buttons in the toolbar, i'm working on a 4k screen with 100% scaling and my toolbars are still too full XD
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: #4828 PartDesign: inverse for pocket

Post by adrianinsaval »

racemaniac wrote: Thu Mar 23, 2023 1:17 pm Wouldn't that be an easier implementation?
most likely not as it implies more operations and could be more computationally intensive
racemaniac
Posts: 52
Joined: Sat Nov 30, 2019 7:45 am

Re: #4828 PartDesign: inverse for pocket

Post by racemaniac »

adrianinsaval wrote: Thu Mar 23, 2023 5:15 pm
racemaniac wrote: Thu Mar 23, 2023 1:17 pm Wouldn't that be an easier implementation?
most likely not as it implies more operations and could be more computationally intensive
Conflating performance & ease of implementation is a bit confusing.

It might indeed be slower (as it's indeed more operations), but just chaining a few functionalities that are very simple & are proven to work sounds easier to implement than modifiying the sketch in some complicated way that also involves the 3d geometry you want to apply it to (and that may have to be regenerated when previous steps get altered). So it may not be the optimal implementation, but i would think it would be easier to get right.
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: #4828 PartDesign: inverse for pocket

Post by adrianinsaval »

I don't see why it would be easier but I'll consider it as second options if it turns out it's hard to add an extra wire
user1234
Veteran
Posts: 3339
Joined: Mon Jul 11, 2016 5:08 pm

Re: #4828 PartDesign: inverse for pocket

Post by user1234 »

adrianinsaval wrote: Thu Mar 23, 2023 5:15 pm most likely not as it implies more operations and could be more computationally intensive
Is it really that compute intesive?

Example on a linear (Pocket/Pad) direction operation:

- on the end of the (partly) common a split, the unedited side is tool A, the other side tool B
- the padded shape of the (partly) common is tool C
- then a boolean common of tool B and tool C --> tool D
- boolean add of tool A and tool D --> finish

(maybe also tool D can be the tool, which can be used for pattern operation)

So it is only a split, a common and a add. I find that is not that much, also in relative to multiple patterns.

Greetings
user1234
Post Reply