View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0033677 | Community | OCCT:Modeling Algorithms | public | 2024-04-12 15:52 | 2024-04-12 15:53 |
| Reporter | dpasukhi | Assigned To | oan | ||
| Priority | normal | Severity | major | ||
| Status | new | Resolution | open | ||
| Target Version | 7.9.0 | ||||
| Summary | 0033677: Modeling Algorithms - Fuse operation Extrema_GenExtCS problem | ||||
| Description | I am having some issues using BOPAlgo_Builder to perform a General Fuse operation. I have a CAD of a thin portion of a toroidal wall [think of a 45 degrees wedge cut off a torus-like cake] and I want to add pipes that enter the wall from its outer surface, run along the inner surface for a bit and then exit. Each pipe is created by extruding a square section along five paths: a straight line, a quarter circumference, a line for which I have an analytical expression, another quarter circumference and finally another straight line. The five paths together should make a C1-continuous line. I then fuse the five resulting solids to make a single pipe and all my pipes are saved as brep files. On to the fuse, my code looks like this:
TopoDS_Shape fws; // This is the wall section
std::vector<TopoDS_Shape> pipes; // This is a list containing all the pipes as read by BRepTools::Read
BOPAlgo_Builder partitioner;
partitioner.AddArgument(fws); // Add the wall
for (int i = 0; i < nPipes; ++i) {
partitioner.AddArgument(pipes[i]); // Add all the pipes
}
partitioner.Perform(); // Do the deed
Now, what I noticed is that the general fuse fails for some seemingly random pipes. Some pictures for context: 2pipes.png shows two of the pipes I have 2pipesAndWall.png shows the same two pipes and the wall they should be fused with. I am very confident that the pipes are properly placed. generalFuseMainSolid.png shows the main component that I extract from the compound resulting from the general fuse. You can see that the pipe on the right was correctly removed from the wall but the one on the left was not. closeUp.png shows a close up of the two central holes from the previous picture. You can see that the one on the left only has three sides, which seems to suggest that the general fuse could not correctly find an intersection between the two solids. I suspect that the whole issue lies here. Now, as I said this happens only sporadically and erratically for some pipes that don't seem to have much in common. Out of 2400 of my latest run, 12 pipes were defective. [Some of them with a different defect but we'll get to that later on]. What's even more interesting is that I was preparing an example to upload that performs the same operations with a smaller portion of my wall, 9 degrees wide instead of 45, and with that example [same pipe] the algorithm worked just fine! Again: the only difference was that I changed the wall, which I generate from a bigger geometry doing a general fuse with a wedge [think of a proper slice of cake] but the surface should otherwise be the same. This seems to suggest that there are some relative tolerances at play that somehow make the algorithm work in one case but not in the other. I tried compiling OCCT in debug mode and catching floating point exceptions but none were thrown... | ||||
| Additional information and documentation updates | https://dev.opencascade.org/content/erratic-issue-general-fuse-algorithm | ||||
| Tags | No tags attached. | ||||
| Test case number | |||||
