-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Face.build() failing to determine the correct face #70
Comments
This is exactly why I did the workaround with the STEP importer. |
In native OpenCascade you would probably end up handling many variations of BRepBuilderAPI_MakeFace::BRepBuilderAPI_MakeFace(). I know this is not an easy job and, more important, that would mean reinventing the wheel: the STEP import source code is freely available from OCCT and, as far as I can see, is far from trivial. So I see two opposite ways to go:
Acis.py) Part is used to build models for FreeCAD. This is easy to get rid of. Let's say we have produced in some way a STEP representation, we then just save it to file and import it: that means using Part only for the FreeCAD plugin functionality and would be one line of code. Acis2Step.py) Optionally, but strongly suggested: see the ongoing discussion on #69 . EDIT: for both Acis.py and Acis2Step.py for what concerns the parametric splines construction. But, as said, that would be optional. Keeping Part as it is used now is just fine and very convenient. |
According to the latest changes, however, Acis2Step.py now builds the face by means of surface.generalFuse(edges, tolerance).
This was probably done with the good intention of reducing the dependencies from Part in Acis2Step (partly), so complying with #65, but, as you know, the overall functionality is jeopardized. At least before it worked. |
convertModel() in importerSAT does the step file import trick for FreeCAD already, so that the very useful STEP file generation that everybody longs for is a side-effect in this case. |
As far as I can tell, before the latest changes the general fusion algorithm, even if used also in STRATEGY_STEP, was inifluential (and this is proven by the fact that it worked). Maybe the code was not that clear, but:
depended on the face.Surface (the same even if the chosen face is wrong) and acisFace, which were both good to our goal. NOTE: I am not that sure that this behaviour has been preserved, just asking for confirmation. |
@marcocecchiscmgroup : This behaviour has been preserved - confirmed. |
Okay.
About this point, the discussion can migrate on #69 , where the Helix construction is being dealt with. Coils can be the next, if the solution will be viable. About fixing STRATEGY_SAT, which I am still interested in given that at the moment is not production quality, unfortunately, I am debugging the OCCT source code and will report right back. |
Debugging was easied by this simple model: Going top bottom in the call stack (just the relevant instructions):
As I suspected by initially flicking through the code, this whole business is quite difficult to replicate in python and I wonder if it's worth at all. If it's not, it makes little sense keeping the STRATEGY_SAT in place, I am afraid. |
On the other hand, implementing once and for all a full-fledged native Part import would enable a more accurate model building (offset curves, revolution solids and the like) without having to translate to NU(R)BS, with a loss of precision/information. Of course the whole thing must work, and it might not be an easy job. What's your opinion? |
Part Import based on Features was my main topic to achieve, because of all the parts I have constructed with Inventor. Not much of the features I was using are missing right now. |
Hello Marco, |
After more careful checking, I cannot exclude that the input dxf that I was referring to is ill formed. I need to be sure before wasting your time. I will open a new ticket in case. Apologizes for the noise. Marco |
swept.zip
If you take a partial torus like this one attached, the STRATEGY_SAT face reconstruction via surface.generalFuse()/eliminateOuterFaces() fails because the opencascade fuse algorithm will split the whole torus in the two complementary halves plus the internal faces/ellipses (as expected, being a fusion algorithm). The fact is that every single such entity is 'seam' (in the isSeam() sense) to the given coedges.
Conversely, STEP conversion is just fine, in that is 1-1 with the ACIS surface/coedges representation.
The text was updated successfully, but these errors were encountered: