Mon, 09/20/2010 - 02:17
At IntTools_FClass2d.cxx:99, Umin = RealLast(). Real_Last() returns DBL_MAX. On my system this is 1.7976931348623157e+308. At some point, it should get changed to a lower value, but apparently this doesn't always happen (note the value of Umin when I print it):
Program received signal SIGINT, Interrupt.
0x00007fffef603639 in IntTools_FClass2d::Perform (this=0x7fffffffbd30, _Puv=..., RecadreOnPeriodic=1)
at ../../../src/IntTools/IntTools_FClass2d.cxx:572
572 uu += uperiod;
(gdb) print uu
$19 = 69807874615.462234
(gdb) print uperiod
$20 = 6.2831853071795862
(gdb) cont
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x00007fffef603657 in IntTools_FClass2d::Perform (this=0x7fffffffbd30, _Puv=..., RecadreOnPeriodic=1)
at ../../../src/IntTools/IntTools_FClass2d.cxx:571
571 while (uu
(gdb) print uu
$21 = 128345489561.46558
(gdb) print uperiod
$22 = 6.2831853071795862
(gdb) print Umin
$23 = 1.7976931348623157e+308
(gdb)
===============================================
If the difference between uu and Umin is large, the while loop would be much faster if something like
uperiod * (int)((Umin-uu) / uperiod) was added.
570- if (uu
uu += uperiod * (int)((Umin-uu) / uperiod); /* add this line*/
571- while (uu
572- uu += uperiod;
573- }
574- } else {
uu += uperiod * (int)((Umin-uu) / uperiod); /* add this line*/
575- while (uu >= Umin){
576- uu -= uperiod;
577- }
578- uu += uperiod;
579- }
There are 2 while loops near line 720 of this file that are similar to these.
Mon, 09/20/2010 - 06:48
Here are 2 files. These are dumps of shapes that cause the error
Dump_50_pipe_shell.brep - this is the pipe
Dump_50_pre_sub_solid.brep - this is the shape the pipe is to be subtracted from
I use solid = BRepAlgoAPI_Cut (solid,pipe);
Mon, 09/20/2010 - 14:02
Hi,
The posted problem was checked. There is no crush.
Cut operation (BRepAlgoAPI_Cut (solid,pipe)) produces the result,
but the resulting shape is not valid (not closed solid).
The corresponding bug with ID = OCC22022 is assigned.
Later you can track the status of the problem by the specified ID.
We will try to fix it in the reasonable time period depending on our technical capability and availability of resources.
If you can't wait and the problem is urgent for you, you may contact us via Contact Form http://www.opencascade.org/about/contacts/.
We will do all our best to find a solution acceptable for you.
Regards
sergey
Mon, 09/20/2010 - 14:20
Hello Mark,
Topologically your shape seems correct ("Dump_50_pre_sub_solid.brep"), but contains faces with wrong parametric dimensions (the reason of the delay in the calculation), and un-connected wires.I tested your case using ShapeProcessAPI_ApplySequence and applying ShapeProcess.FixFaceSize with tollerance 0.5 and afterwards ShapeProcess.FixWireGaps and the boolean subtraction created a topologically correct solid. (Without further investigation of its geometry).
Fotis
Mon, 09/20/2010 - 14:49
Hi Fotis,
This is much in line with my experience in OCC's boolean tools.
My feeling is that OCC's bool ops aren't so bad as sometimes suggested on this forum, but *are* really sensitive to the quality of the input.
It would be a *wonderful* addition to have a function that checks for such conditions before running a bool op.
If a bool op than fails, one could be pretty sure that its due to the bool op function, not due to brep data that isn't in shape to be subjected to a bool op. That would be a serious help to reduce the false positives with respect to OCC's boolean operations. I have to admit that I've fallen victim to this several times myself, where I found out that my brep data wasn't in good enough for the picky boolean operation functions.
Would that be an idea?
Tue, 09/21/2010 - 12:36
Hello Jelle,
I am also in line with your thoughts (geometry-topology "healing"), not only with boolean operations, but also with the rest of the higher level topology API.I think that "healing" before and after an operation is an important issue that needs to be taken well care of.
Now if this "healing" should be handled "low level" by OCC or the calling process is another question not so easy to answer here, but since OCC thankfully provides the TKShHealing package it can be implemented at application level using the provided API.
In your specific case jelle, you could use the provided healing classes and write an "operation" wrapper that will test your shapes against some issues like the foresaid above (plus others).
Waiting for any thoughts or remarks
Fotis
Sat, 09/25/2010 - 06:09
Thank you, Fotis!
I was not familiar with ShapeProcessAPI_ApplySequence and had to look it up. Unfortunately the documentation is pretty thin[1], and there aren't too many examples either. I ended up using ShHealOper* from Salome's Geom module.
I created a file with the following content, and pass its name to ShapeProcessAPI_ApplySequence. This helps, but I still get shapes with bad faces and/or visually incorrect geometry. Are the contents of this file correct? If so, what should I do?
-------------------------------------------
ShapeProcess.exec.op : FixFaceSize,FixWireGaps
ShapeProcess.FixFaceSize.Tolerance : 0.5
-------------------------------------------
[1]: ShapeProcessAPI_ApplySequence and ShapeProcess.FixWireGaps are not mentioned in shape_heal.pdf from v6.3.0. However, FixWireGaps *is* mentioned as a method of ShapeFix_Wireframe...
Sat, 09/25/2010 - 12:11
Hello Mark,
Try with ShapeProcess.FixFaceSize.Tolerance : 1.e-2 and let's see if this helps.I found out that i used another resource file that had this value when i tested your case.If it will not help try to use the higher level ShHealOper* classes which i also used to get a valid result, but i do not see what the difference would be with direct interfacing of ShapeProcessAPI_ApplySequence.
*FixWireGaps and all the operators supported were found in ShapeProcess_OperLibrary.cpp
Fotis
Sat, 09/25/2010 - 21:15
I meant to say that I use ShHealOper_ShapeProcess, which uses ShapeProcessAPI_ApplySequence internally.
I tried changing ShapeProcess.FixFaceSize.Tolerance to 1e-2, and I tried using the file ShHealingFullSet from salomegeometry svn. The result is better, but there are still some missing faces and extra faces. I'm also getting a segfault from BRepAlgoAPI_Cut, but my simplified test gives a segfault in a different location than in my program. Once I figure it out, I'll post.
Sun, 09/26/2010 - 19:31
Here are the shapes and code that causes a segmentation fault on my machine (64 bit). Strangely, it does not cause a segmentation fault if used with debug libraries!
Wed, 09/29/2010 - 16:52
Hi Mark,
In new version (OCCT 6.4) it not leads to segmentation fault.
Cut operation just returns error status.
Regards
Sergey
Sun, 09/26/2010 - 23:37
Hello Mark,
First of all can you notify the forum if the healing of the geometry fixed you first provided test case (brep files) ? If yes then your new provided shapes is another issue and needs some examining, and hopefully till tomorrow if all is good i will try to dig a bit into them.
Fotis
Wed, 09/29/2010 - 02:12
Shape healing fixed the first case and my program was able to run longer.
Both of the shapes attached to my segfault post have had shape healing applied. In spite of that, the larger of the two is messed up - it has missing faces as well as one extra face.
The faces are obviously an issue I must solve, but I don't think that BRepAlgoAPI_Cut should cause a segmentation fault for any input shapes. The main reason to post this was to provide the shapes to OCC so they could look at the problem.
If anyone knows a way to add faces that should exist, or to remove faces that don't make sense, I'd like to hear about it. I didn't see anything in shape healing that sounded like it would help.
Thanks
Mark
Wed, 09/29/2010 - 16:29
Hello Mark,
1)The access violation could not be reproduced in my system, so i cannot do much on this.Make sure you have added in your code an OCC exception handler.If this is the case then maybe the occ team can check it deeper.
2)Your provided shape was already not valid propably because of an earlier cut operation (missing-extra faces). Since the input data is not correct then also the cut operation propaly will not produce correct results.So this is why it fails.
3)Using my tools i recreated the missing faces, and fixed all geometry and topology issues, and the cut operation produced a valid result, so the cut algorythm works with your provided shapes (fixed).Find attached the correct breps in this post.
4)My humble opinion is that you should reconsider your approach on the issue you try to solve.Take a good note on sergey zaritchny's post.Also if you have the tool and the path and you try to reconstruct the geometry, a good way is to try to implement a sweep algo and apply boolean cut once.
Fotis
Wed, 09/29/2010 - 17:03
Hi,
I would added several words to this post.
It makes no any sense to apply boolean operations to invalid arguments.
Because result may be unpredictable (boolean operations expects valid arguments).
I would recommend to check each argument for validity before the operation.
Regards
Sergey
Mon, 09/20/2010 - 10:41
Hi Mark,
I got the same crash in my win32 version. Both of solids are topology correct. So I think that's a bug of OCC Boolean operation.
Ding