[finished] project: Making Part Extrude taking care of inner structure

[jonasb]

If it is known which types of edges do not work, then it might be possible to check for them before attempting one of the methods rather than trying one and seeing if it fails.

I guess this can change from one OCC version to another. I also guess that OCC will do such a check first, so the assumption is that if it fails, it will fail fast. But that has to be checked.

[TheMarkster]

If it is known which types of edges do not work, then it might be possible to check for them before attempting one of the methods rather than trying one and seeing if it fails.

I guess this can change from one OCC version to another. I also guess that OCC will do such a check first, so the assumption is that if it fails, it will fail fast. But that has to be checked.

Possibly it could change with different versions. I'm not sure right off how to check the edge type in C++ using OCC. Maybe TopExp_Explorer or something similar. In python I would do something like:

Code: Select all

for wire in profile.Shape.Wires:
    for edge in wire.Edges:
        if edge.Curve.TypeId == 'Part::GeomBSplineCurve':
            pass #handle this situation

[uwestoehr]

I don't think you are right here. PartDesign_Draft is TNP sensitive because it relies on FreeCAD's face numbering. The OCC function does not use face numbers, as long as we can identify what faces should be drafted inside the feature code, everything will be fine with respect to TNP.

Then fine with me.

However, can someone please explain me on an example the issue with the B-spline. I still haven't understand it.

Actually topological naming is a good example. Imagine that you create a pad with taper=0. You create a sketch on its side face and continue modeling. Then you change taper angle of the pad. You will then get a failed model.

This works for me, here is an example:

Loft-example.FCStd

(30.5 KiB) Downloaded 25 times

Here you are, it's the augmented example from my post above:

Thanks, now I got it.

What I wonder now is that when the problem is known and affects such a basic feature like PD Loft and Part Extrude, nobody took care yet if and how the OCC kernel offers us a better way to create lofts/extrudes.

So in effect, I am happy to have started this topic, hoping we will find a better solution now .

[uwestoehr]

Now I tried it. It was straight-forward to implement a proof of concept.

Great!
To move on, I propose
1. you make a PR to change PD Loft. Loft does not have the direction feature, it just takes the wires as they are already defined.
2. When this PR is ready and merged, we use make a further PR to use this method for Part Extrude for the case that the extrusion direction is the normal. For the other extrusion directions we keep the current method.

Would that be OK for you?

[adrianinsaval]

What I wonder now is that when the problem is known and affects such a basic feature like PD Loft and Part Extrude, nobody took care yet if and how the OCC kernel offers us a better way to create lofts/extrudes.

Great!
To move on, I propose
1. you make a PR to change PD Loft. Loft does not have the direction feature, it just takes the wires as they are already defined.

I think you are a little confused, how can Draft be used to make a loft? Tapered pad =/= loft. Or is it me that I'm lost?

[-alex-]

What I wonder now is that when the problem is known and affects such a basic feature like PD Loft and Part Extrude, nobody took care yet if and how the OCC kernel offers us a better way to create lofts/extrudes.

The problem is maybe known but not so much discussed AFAIK.
Since I'm not skilled in programming I opened this thread few month ago in open discussion subforum:
https://forum.freecadweb.org/viewtopic.php?f=8&t=63211
But I've got no any relpy, except from @realthunder, I thanks him for that.

[davidosterberg]

Great!
To move on, I propose
1. you make a PR to change PD Loft. Loft does not have the direction feature, it just takes the wires as they are already defined.
2. When this PR is ready and merged, we use make a further PR to use this method for Part Extrude for the case that the extrusion direction is the normal. For the other extrusion directions we keep the current method.

Would that be OK for you?

I will be happy to help.

1) I can make a PR to FeaturePad that implements the logic of modifying the original pad to have draft, but does not expose it in the UI. The changes will be local in FeaturePad.cpp and will thus not interfere much with your PR.
2) Then you can adapt your PR (that contains a nice gui) so that it first tries the Draft logic, and if that fails it falls back on using your new method generateTaperedPrism.

[davidosterberg]

This works for me, here is an example:
Loft-example.FCStd

It is interesting that it is possible to Sketch on the spline surface. But it does not work without bugs.
I tried to sketch on one of the other faces and the pad went off in a wonky direction

bug.PNG (16.68 KiB) Viewed 1511 times

I agree with Chrisb that it is tiring to come up with counter example after counter example. Go back in the thread and see how many that actually support the idea that BSplines are just as good as plane surfaces.


OS: Windows 10 Version 2009
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.24276 (Git)
Build type: Release
Branch: releases/FreeCAD-0-19
Hash: a88db11e0a908f6e38f92bfc5187b13ebe470438
Python version: 3.8.6+
Qt version: 5.15.1
Coin version: 4.0.1
OCC version: 7.5.0
Locale: English/Australia (en_AU)

Edit:

BSpline_sketching.gif (487.21 KiB) Viewed 1496 times

[davidosterberg]

PR for Draft based method:
https://github.com/FreeCAD/FreeCAD/pull/5379

[uwestoehr]

1) I can make a PR to FeaturePad that implements the logic of modifying the original pad to have draft

As I wrote, your method should first be use for PD Loft. PD Loft takes 2 sections and builds a shell around them. It appears that this method leads always to splines, even if the 2 sections are e.g. rectangles. So let's improve the situation and use your proposal for PD Loft. This way we can also stress-test your solution with existing test cases.

If it works there well for different test cases it can be implemented also for Part Extrude.

Meanwhile I first need to create the infrastructure that PD Pad/Pocket uses the same code as Part Extrude. I expect this will be as much work as it took to unify the code base for Pad and Pocket. Therefore let's please act in stages.