What "work" would you suggest?
Intersecting Holes (BOPAlgo_InvalidCurveOnSurface)
Forum rules
and Helpful information
and Helpful information
IMPORTANT: Please click here and read this first, before asking for help
Also, be nice to others! Read the FreeCAD code of conduct!
Also, be nice to others! Read the FreeCAD code of conduct!
Re: Intersecting Holes (BOPAlgo_InvalidCurveOnSurface)
Star Trek II: The Wrath of Khan: Spock: "...His pattern indicates two-dimensional thinking."
Re: Intersecting Holes (BOPAlgo_InvalidCurveOnSurface)
check the latest file which I have added (and have a closer look at the refine settings).
This topic is really about an "after" it happened fix, in case it can be avoided WITH refining (removeSplitter) certainly that would also be interesting.
This topic is really about an "after" it happened fix, in case it can be avoided WITH refining (removeSplitter) certainly that would also be interesting.
Re: Intersecting Holes (BOPAlgo_InvalidCurveOnSurface)
I don't see, short of dissecting the failed model on the object level, you could fix it without specific tools to work on a "no history" brep.
So, tools to find the offending edges/faces and repair them.
I suppose since the geo check tells the names, the Defeaturing workbench might be able to...
Star Trek II: The Wrath of Khan: Spock: "...His pattern indicates two-dimensional thinking."
Re: Intersecting Holes (BOPAlgo_InvalidCurveOnSurface)
Maybe I lack creativity for that... I really have no idea how to fix that. The issue does not hurt right now but it seems to be there whenever a hole is intersected (and a solution for this needs to survive refining and post editing)drmacro wrote: ↑Tue Nov 23, 2021 2:55 pm I don't see, short of dissecting the failed model on the object level, you could fix it without specific tools to work on a "no history" brep.
So, tools to find the offending edges/faces and repair them.
I suppose since the geo check tells the names, the Defeaturing workbench might be able to...
Re: Intersecting Holes (BOPAlgo_InvalidCurveOnSurface)
So my evil plan, give so less information as possible to subliminal nudge you, to write yours, worked.MRx wrote: ↑Tue Nov 23, 2021 12:26 pm Really no invalid geometry?
Part -> Check Geometry
----
OS: macOS 10.15
Word size of FreeCAD: 64-bit
Version: 0.20.26202 (Git)
Build type: Release
Branch: master
Hash: ca6d49d080dea0abc23d954743eca7c46f33469b
Python version: 3.9.7
Qt version: 5.12.9
Coin version: 4.0.0
OCC version: 7.5.3
Locale: C/Default (C)
So in fact, the model you gave have the issues. When i redo it in a normal way, it works without issue. The last time i get this kind of error, in a hole in hole operation, was many years ago. And as
+1 . You seems to work only with direct modeling programs before, which works completely different. Also direct modeling programs have much more many issue, there are intrinsic in the way the work and they can be unreparable destroyed thru that. Somewhere here in the forum i have a list and rant about the issues.
Deleting the dependencies in a parametric program makes no sense, also with your loading "issue", which is none. I have 3D files with many parts (200+) and have only a loading issue when:
- the file is old and does automatic recompute while opening
- the parts have many drawings in it. At the moment is is the behavior, that drawing are recomputed while loading. This can go fast, but if you get in the drawings issues with the TNP, it can load longer, but not extreme. This can avoided, when you make the drawing in a separate file and link the part to the drawing file. So the assembly loads only the 3D parts, which goes pretty fast.
Just said, that that realtunder works on a lading lightweight part mode, see https://forum.freecad.org/viewtopic.php ... 7&p=329090. Which means when you laod an assembly, it loads only the top level of the part, not the complete. This is the normal behavior in the commercial CAD programs. Also just noted, that maybe is not that fast as commercial CAD programs, but:
- you have not to wait minimum 15min (this is the fastest i know) to start the program to due loading and get all licenses (i also worked with programs, they need >30min)
- also expensive commercial programs have sometimes load long duration. I am remembering on loading times for a single pat till 3/4h.
- OCCT provides their kernel! and that OpenSource!, so FreeCAD have one. Without that, no FreeCAD, we should be thankful for that. And also every OCCT step, the kernel gets better. If you compare it with OCCT6.7, it works better and much faster.
Code: Select all
OS: Debian GNU/Linux 11 (bullseye) (X-Cinnamon/lightdm-xsession)
Word size of FreeCAD: 64-bit
Version: 0.20.26456 (Git)
Build type: Debug
Branch: master
Hash: d34a5616a2b38c96ad05f9a0763ba7504dfb814d
Python version: 3.9.2
Qt version: 5.15.2
Coin version: 4.0.0
OCC version: 7.6.0
Locale: English/United States (en_US)
user1234
Re: Intersecting Holes (BOPAlgo_InvalidCurveOnSurface)
Please if you don't have anything productive to add just don't add your comment here regarding this issue.
No history? Are you kidding me?
A quick sample with history is available here (posted in a previous post, certainly it's easy to skip that):
https://forum.freecadweb.org/download/f ... ?id=170808
There's a bug and that bug and it should either be possible to avoid it completely or fix it afterwards.
The sequence is:
- create intersecting holes
- refine the object
- add some further modifications to it
- do a geometry check
I'm yet not sure where the problem is and how this geometry check works it's probably a wrapper around some OCCT function and possibly the issue is in OCCT itself. If so the issue should be reported to opencascade including a sample. But I did not investigate that issue deep enough yet.
- So does anyone have experience with this particular issue?
- Is any workaround known? (Pre or Post-Workaround)
No history? Are you kidding me?
A quick sample with history is available here (posted in a previous post, certainly it's easy to skip that):
https://forum.freecadweb.org/download/f ... ?id=170808
There's a bug and that bug and it should either be possible to avoid it completely or fix it afterwards.
The sequence is:
- create intersecting holes
- refine the object
- add some further modifications to it
- do a geometry check
I'm yet not sure where the problem is and how this geometry check works it's probably a wrapper around some OCCT function and possibly the issue is in OCCT itself. If so the issue should be reported to opencascade including a sample. But I did not investigate that issue deep enough yet.
- So does anyone have experience with this particular issue?
- Is any workaround known? (Pre or Post-Workaround)
Re: Intersecting Holes (BOPAlgo_InvalidCurveOnSurface)
Then good luck, you will need it. With you attitude till yet, nobody will help you.
Re: Intersecting Holes (BOPAlgo_InvalidCurveOnSurface)
If you want to add your comment just write you have no idea about that problem and you cannot help anyone who has this problem and the story is done. We know that now thanks.
The problem still remains, I think I even created a bugreport last year about it but this year I'd like to see it fixed.
TopoShape.cpp confirms that the error reporting comes from OCCT, so I'll sort out the item (BRP file) and post it in the OCCT forum later
Last edited by MRx on Tue Nov 23, 2021 6:34 pm, edited 1 time in total.
Re: Intersecting Holes (BOPAlgo_InvalidCurveOnSurface)
Hmm...can you actually define which further modifications exactly? Here I have done exactly what you propose, I even used a copy (Body002) that was refined and it's precursors deleted. Then did a Part Boolean, then put the result in a Body (BaseFeature). Then several pockets of sketches that are splines and of rotated sketches that should create splines, etc. As you can see the geom check returns no problem.
- Attachments
-
- Snip macro screenshot-7aeb45.png (152.82 KiB) Viewed 1795 times
Star Trek II: The Wrath of Khan: Spock: "...His pattern indicates two-dimensional thinking."
Re: Intersecting Holes (BOPAlgo_InvalidCurveOnSurface)
Hi,
I added another fresh example with InvalidCurveOnSurface. The issue is clearly caused by refining/removeSplitter.
It looks like you did not pad+refine any of your cutouts afterwards?
I added another fresh example with InvalidCurveOnSurface. The issue is clearly caused by refining/removeSplitter.
It looks like you did not pad+refine any of your cutouts afterwards?
- Attachments
-
- intersectingHole3.FCStd
- (141.84 KiB) Downloaded 23 times