View Issue Details

IDProjectCategoryView StatusLast Update
0025022CommunityOCCT:Shape Healingpublic2021-08-31 15:27
Reporterdrazmyslovich Assigned Toabv 
PrioritynormalSeverityminor 
Status assignedResolutionopen 
PlatformWindowsOSVC++ 2010 
Product Version6.6.0 
Target VersionUnscheduled 
Summary0025022: ShapeFix_Wire::FixIntersectingEdges finds wrong intersection point
DescriptionThe 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 ReproducePlace a breakpoint in ShapeFix_Wire::FixIntersectingEdges during the import.
TagsNo tags attached.
Test case number

Attached Files

  • face.step (25,688 bytes)
  • face (9,537 bytes)
  • test1.bmp (768,150 bytes)
  • test2.bmp (768,150 bytes)

Relationships

related to 0024084 assignedoan Open CASCADE Additional tool for resolving 2d loops on discretized wires should be implemented in BRepMesh 

Activities

drazmyslovich

2014-06-18 17:11

developer  

face.step (25,688 bytes)

ika

2014-07-31 18:42

developer   ~0030514

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).

ika

2014-07-31 18:42

developer  

face (9,537 bytes)

ika

2014-07-31 18:50

developer  

test1.bmp (768,150 bytes)

ika

2014-07-31 18:52

developer  

test2.bmp (768,150 bytes)

drazmyslovich

2014-08-04 17:06

developer   ~0030561

Last edited: 2014-08-04 17:06

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

ika

2014-08-20 19:23

developer   ~0030960

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.

drazmyslovich

2014-09-17 18:16

developer   ~0031831

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

ika

2014-09-18 19:29

developer   ~0031882

Last edited: 2014-09-18 19:29

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.

drazmyslovich

2014-09-29 12:09

developer   ~0032290

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.

Issue History

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 abv Target Version => 6.8.0
2014-08-20 19:23 ika Note Added: 0030960
2014-09-11 09:11 abv Assigned To gka => drazmyslovich
2014-09-11 09:11 abv 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 abv 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 abv Target Version 7.1.0 => 7.2.0
2017-08-14 16:21 abv Assigned To drazmyslovich => abv
2017-08-14 16:21 abv Status feedback => assigned
2017-08-14 16:21 abv Target Version 7.2.0 => 7.3.0
2018-02-25 21:14 abv Target Version 7.3.0 => 7.4.0
2019-09-04 13:04 abv Target Version 7.4.0 => 7.5.0
2020-09-11 16:48 utverdov Target Version 7.5.0 => 7.6.0
2021-08-31 15:27 gka Target Version 7.6.0 => Unscheduled