PR #3794 - pad in any direction

Merged, abandoned or rejected pull requests are moved here to clear the main Pull Requests forum.
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: PR #3794 - pad in any direction

Post by uwestoehr »

Jee-Bee wrote: Tue Aug 11, 2020 4:15 pm May i ask why not using sherical coordinate system and not a vector.
Because a sketch can be in any plane. It is very hard to understated a vector of e.g. (30°, 60°, 1) in spherical coordinates for a sketch whose plane has he normal vector of e.g. (1, 0.5, -0.33).
Cartesian vectors has at least the advantage that you could help your brain a bit bay saying (1, 0.5, -0.33) is the direction 1 cm in x, 0.5 cm in y and - 1/3 cm in z.
I guess this is also the reason why FC uses Cartesian vectors in Part and PartDesign.
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: PR #3794 - pad in any direction

Post by wmayer »

However, I also have question: For the custom vector I used QDoubleSpinBox but one cannot bind expressions to this. I first tried Gui::PrefDoubleSpinBox, but this does not allow expression bindings as well. Then I tried Gui::PrefQuantitySpinBox but since a vector component has no unit, I don't know if I can use it but simply set the unit to an empty string.
What do you recommend me here?
5. I use simply an empty unit
This is one option. An alternative is using Gui::DoubleSpinBox which extends a QDoubleSpinBox with expressions. However, in the designer plugin it was missing. I have added it with git commit 93bb9646c
Concerning 3. I understand you now. The pad length should also be matched if skewed. However, at a quick look I could not find out how I could assure this.
The geometrical meaning of my suggestion is called a shearing which is an equal-volume transformation. To make this working you must pass a modified value of "L" to generatePrism.
In the current master we compute dir like this:

Code: Select all

gp_Dir dir(SketchVector.x,SketchVector.y,SketchVector.z);
and in your PR it's computed this way:

Code: Select all

gp_Dir dir(paddingDirection.x, paddingDirection.y, paddingDirection.z);
Since the length of a gp_Dir is 1 you can compute the modified L:

Code: Select all

double factor = dir * gp_Dir(SketchVector.x,SketchVector.y,SketchVector.z);
L = L / factor
Theoretically it can happen that factor becomes 0 but geometrically this means the pad height is 0 and thus must not be allowed (because it's a degenerated volume). So, you should make sure that the z value of the custom direction is != 0 -- this makes the check for the null vector obsolete again.
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: PR #3794 - pad in any direction

Post by uwestoehr »

wmayer wrote: Wed Aug 12, 2020 9:41 am This is one option. An alternative is using Gui::DoubleSpinBox which extends a QDoubleSpinBox with expressions. However, in the designer plugin it was missing. I have added it with git commit 93bb9646c
Many thanks! Yes, I missed this widget. I used it now in the updated PR.

The geometrical meaning of my suggestion is called a shearing which is an equal-volume transformation. To make this working you must pass a modified value of "L" to generatePrism.
Thank you. This is now in and also these changes:

- fixed an UI issue (comparison that variable equals 0 sometimes failed because of precision)
- give feedback when the vector is orthogonal to the normal vector
- fixed the issue that the user-defined number of decimals were not respected
- don't automatically set skewEdits while modifying it. A typical use case if to start e.g. with 0.1 and click three times to get -0.2. Then you don't want to suddenly get another value because there was for few millisecond a null vector.

So from my point of view the feature is ready to go in.
Last edited by uwestoehr on Sun Aug 16, 2020 12:48 am, edited 1 time in total.
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: PR #3794 - pad in any direction

Post by uwestoehr »

wmayer wrote: Wed Aug 12, 2020 9:41 am An alternative is using Gui::DoubleSpinBox which extends a QDoubleSpinBox with expressions. However, in the designer plugin it was missing. I have added it with git commit 93bb9646c
Now the Travis builds on Linux fail, while there is no problem on Windows:
https://travis-ci.org/github/FreeCAD/Fr ... /718170570
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: PR #3794 - pad in any direction

Post by adrianinsaval »

Could we define the direction with a datum line?
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: PR #3794 - pad in any direction

Post by uwestoehr »

adrianinsaval wrote: Wed Aug 19, 2020 2:43 am Could we define the direction with a datum line?
Yes, because an existing datum line shows you already its direction in the Data tab. In future one could add the feature to select a datum line or edge to get the direction from it. But step by step, meaning at first the feature has to go in, then I am sure there will be further feedback and then we can discuss further features like the direct edge/line selection.

p.s. I am in vacation thus mostly offline the next 2 weeks.
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: PR #3794 - pad in any direction

Post by uwestoehr »

Meanwhile on GitHub the user DeepSOIC made some valuable comments.
I updated the PR according to his advises:

- instead of "skew" use the term "direction" because it is about the padding direction
- the direction is now a vector property so one can also ow pass directly a vector via Python or the Data tab:
screenshot of the Data tab
screenshot of the Data tab
FreeCAD_E4drIKGaQT.png (6.01 KiB) Viewed 5982 times
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: PR #3794 - pad in any direction

Post by wmayer »

The PR is merged now. But:

What's not working yet are the options Up to first and Up to last
EDIT: This is not an issue of this PR but a general problem. The algorithm fails to find an intersecting face with a ray if the Up to first/last face is too small.
As a workaround one can use the option Up to face and select the face manually.

When using the option Two Lengths then the length in opposite direction is incorrect.
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: PR #3794 - pad in any direction

Post by wmayer »

User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: PR #3794 - pad in any direction

Post by uwestoehr »

wmayer wrote: Sat Sep 12, 2020 2:52 pm When using the option Two Lengths then the length in opposite direction is incorrect.
I was not aware of this yet. I am currently abroad and will have a look Monday evening to reproduce and fix it.
Post Reply