View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0025022 | Community | OCCT:Shape Healing | public | 2014-06-18 17:11 | 2021-08-31 15:27 |
| Reporter | drazmyslovich | Assigned To | |||
| Priority | normal | Severity | minor | ||
| Status | assigned | Resolution | open | ||
| Platform | Windows | OS | VC++ 2010 | ||
| Product Version | 6.6.0 | ||||
| Target Version | Unscheduled | ||||
| Summary | 0025022: ShapeFix_Wire::FixIntersectingEdges finds wrong intersection point | ||||
| Description | The attached file shows the model, where 1 of two faces is always without mesh. It can be supposed, that the problem lies in BRepMesh module, but actually the problem is caused by ShapeFix. As you can see, one of the faces contains 2 circles - one is inside of another with one common point (it's 1 wire, not 2). There are no geometrical intersections between these 2 circles (actually 1 circle and 1 bspline). But ShapeFix anyway finds 2 intersection points, cuts the edges and increases the tolerance of the common vertex. For BRepMesh this modification ends up in one of the following scenarios: 1. With the current precision, BRepMesh identifies the face with circles as a face with self-intersecting wire and rejects to mesh it. 2. If you decrease UVDEFLECTION for BRepMesh to 1.e-06, than BRepMesh can resolve the self-intersection for this face, but it should decrease the edge deflection to the value, when the increased tolerance causes the second face to be identified as a face with opened wire... | ||||
| Steps To Reproduce | Place a breakpoint in ShapeFix_Wire::FixIntersectingEdges during the import. | ||||
| Tags | No tags attached. | ||||
| Test case number | |||||
|
|
face.step (25,688 bytes) |
|
|
Dear Dmitry, The intersection point exists actually (maybe problem is in replacing circle by several BSpline curves). There are two test scripts in Draw to argue it (face is shape from face.step before all shape healing modifications): script 1 (attached Draw screen in debug mode test1.bmp) explode face e // 9 edges distmin d face_1 face_9 // 2 intersection points. script 2 (attached test2.bmp) pcu face //face_n now are 2dcurves trim c1 face_1 0.05 0.95 //to cut intersection point in the end of edge trim c2 face_9 1.6 3.1 2dintersect c1 c2 // - one intersection point This case can not be fixed by Shape Healing because of next steps in algorithm: 1) Split wire into two loops (four edges connected in one vertex) 2) Find second intersection point and split edges in both wires. After these actions there are two wires on face, and both of them is partly inside another (intersected in vertices), so result shape is invalid (Bad Orientation Of Subshape). |
|
|
face (9,537 bytes) |
|
|
test1.bmp (768,150 bytes) |
|
|
test2.bmp (768,150 bytes) |
|
|
Dear, Irina, thank you for your analysis. Be honest, I haven't evaluated the geometry of the faces and was relying on the STEP file structures, because according to the STEP file it was at least designed to have no intersection points, but most probably during the export to step file some significant digits were cut due to precision or something else... Anyway, in this case, should not ShapeFix create a degenerate edge for the neighbor faces, so that their wires don't remain opened? (first vertex = last vertex, but in 2d the vertices represent cur points) Regards, Dima |
|
|
Dear Dmitry, In case of reading full STEP file, all 3 wires are closed as in picture, as in topology. In case of reading only problem face from STEP file, its wires are not closed in picture, but they have a big tolerance (near 1) and gaps are covered by it. Gaps in 2D are not a mistake too, because 2D curves for planes are not stored. And projection of closed in 3D wire is closed in 2D. Because of these reasons, I can't completely understand your question, so could your please rephrase it, if it is still necessary. |
|
|
Dear Irina, I agree, that the wires are closed and all gaps are covered with necessary tolerance values. But the problem appears later during meshing of the faces: always one of the faces doesn't have a triangulation. It happens due to the following reasons: 1. Due to the current discretization deflection value of 1.e-5 the fixed wire of the problem face is recognized by the mesher as having self-intersecting. Even it's geometrically and topologically just a normal wire. So the problem face remains without a triangulation. 2. Adjusting the discretization deflection value can help to avoid self-intersecting problem. But the smaller deflection value causes the wire of the second face to be recognized as open wire, because the total distance between 2 geometrical points of the same topological vertex is more, than any gaps... Therefore my last question was: for such case isn't it necessary to insert a degenerated edge between 2 geometrical points to cover the distance between them? Thank you! Regards, Dima |
|
|
Dear Dmitry, Degenerated edge - is an edge with normal 2D curve and degenerative (point) 3D curve. It can cover distance only in 2D and only on periodic surfaces, like apex in cone surface. So degenerative edge can't help in this situation. Maybe 0022642 will be interesting for you? Its subject is close to this problem. |
|
|
Dear Irina, I think, that the most suitable ticket for my problem is 0024084. I hope, that so far this tool is implemented, the faces will be properly triangulated. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-06-18 17:11 | drazmyslovich | New Issue | |
| 2014-06-18 17:11 | drazmyslovich | Assigned To | => gka |
| 2014-06-18 17:11 | drazmyslovich | File Added: face.step | |
| 2014-07-31 18:42 | ika | Note Added: 0030514 | |
| 2014-07-31 18:42 | ika | File Added: face | |
| 2014-07-31 18:50 | ika | File Added: test1.bmp | |
| 2014-07-31 18:52 | ika | File Added: test2.bmp | |
| 2014-08-04 17:06 | drazmyslovich | Note Added: 0030561 | |
| 2014-08-04 17:06 | drazmyslovich | Note Edited: 0030561 | |
| 2014-08-05 19:29 |
|
Target Version | => 6.8.0 |
| 2014-08-20 19:23 | ika | Note Added: 0030960 | |
| 2014-09-11 09:11 |
|
Assigned To | gka => drazmyslovich |
| 2014-09-11 09:11 |
|
Status | new => feedback |
| 2014-09-17 18:16 | drazmyslovich | Note Added: 0031831 | |
| 2014-09-17 18:17 | drazmyslovich | Assigned To | drazmyslovich => ika |
| 2014-09-18 19:23 | ika | Status | feedback => assigned |
| 2014-09-18 19:29 | ika | Note Added: 0031882 | |
| 2014-09-18 19:29 | ika | Assigned To | ika => drazmyslovich |
| 2014-09-18 19:29 | ika | Status | assigned => feedback |
| 2014-09-18 19:29 | ika | Note Edited: 0031882 | |
| 2014-09-26 06:18 |
|
Target Version | 6.8.0 => 7.1.0 |
| 2014-09-29 12:09 | drazmyslovich | Note Added: 0032290 | |
| 2014-09-29 12:09 | drazmyslovich | Relationship added | related to 0024084 |
| 2016-11-03 17:07 |
|
Target Version | 7.1.0 => 7.2.0 |
| 2017-08-14 16:21 |
|
Assigned To | drazmyslovich => abv |
| 2017-08-14 16:21 |
|
Status | feedback => assigned |
| 2017-08-14 16:21 |
|
Target Version | 7.2.0 => 7.3.0 |
| 2018-02-25 21:14 |
|
Target Version | 7.3.0 => 7.4.0 |
| 2019-09-04 13:04 |
|
Target Version | 7.4.0 => 7.5.0 |
| 2020-09-11 16:48 |
|
Target Version | 7.5.0 => 7.6.0 |
| 2021-08-31 15:27 |
|
Target Version | 7.6.0 => Unscheduled |
