Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0030158Community[OCCT] OCCT:Shape Healingpublic2018-09-24 13:342019-10-21 13:57
Assigned Tobugmaster 
PlatformWindowsOSVC++ 2015OS Version64 bit
Product Version[OCCT] 7.3.0 
Target Version[OCCT] 7.4.0Fixed in Version[OCCT] 7.4.0 
Summary0030158: Shape Healing - Incorrect result produced by ShapeUpgrade_UnifySameDomain
DescriptionThe problem is caused by the process of shape fixing in 4 front faces, that has one edge as a seam. Firstly, the left pair of faces is merged and their right edges that are seams are adjusted to form closed wire. Then the right pair merged and again the adjustment is performed and it cracks the previous wire.

I propose not to merge such kind of faces (as ocad performs if the common edge of faces is seam).

The patch and examples of bodies are attached.
Steps To Reproducetest bugs modalg_7 bug30158_1
test bugs modalg_7 bug30158_2
Test case numberNot required
Attached Filespatch file icon ShapeUpgrade_UnifySameDomain.cxx.patch (1,902 bytes) 2018-09-24 13:34
? file icon shape_after.brep (30,129 bytes) 2018-09-24 13:34
? file icon shape2.brep (16,031 bytes) 2018-10-16 15:59
png file icon 2_faces.PNG (7,473 bytes) 2019-06-21 17:46
png file icon 2_faces_vori_1.PNG (9,186 bytes) 2019-06-21 17:46
png file icon 2_faces_vori_4.PNG (8,867 bytes) 2019-06-21 17:47
png file icon 2_faces_pcurves_1.PNG (4,783 bytes) 2019-06-21 17:47
png file icon 2_faces_pcurves_4.PNG (4,104 bytes) 2019-06-21 17:47
? file icon bug30158_1.brep (30,145 bytes) 2019-06-27 13:19
? file icon bug30158_2.brep (32,090 bytes) 2019-06-27 13:19

- Relationships
duplicate of 0029504closedbugmaster Open CASCADE ShapeUpgrade_UnifySameDomain produces invalid shape and ShapeFix_Shape is unable to fix it 

-  Notes
msv (developer)
2018-09-24 19:55

I dislike this patch, because it limits the capabilities of the algorithm.

Indeed, the problem here is concluded in the following. The edge common between two faces lying on the same surface must have a special curve representation on that surface allowing specification of two p-curves (BRep_CurveOnClosedSurface).

Now the algorithm makes each face independently, and for this edge the simple curve representation is set (BRep_CurveOnSurface).

So, the solution is to perform postprocessing on the result shape, so as to find such edges and to replace their curve representation with the correct one.
msv (developer)
2018-09-24 19:59

The bug 0029504 describes exactly the same problem.
denix56 (reporter)
2018-09-26 10:54

I have investigated the problem a bit and found out that (in my case) the edge has BRep_CurveOnClosedSurface but int both faces edge is reversed, meaning that it use same 2d curve.
I you know how to integrate face reverse in unify domain, please tell, because I tried different apporaches but the result is incorrect.
msv (developer)
2018-09-26 16:13

May be you see in the edge BRep_CurveOnClosedSurface that is left from the old surface, but the algorithm for the new face inserts one more BRep_CurveOnSurface. I saw in your model exactly this issue. The edge in the result has one extra curve representation.
I did not observe non-coherent faces orientation there.
denix56 (reporter)
2018-09-26 20:08

I tried to add this code:

          aResult = sff.Face();

          ShapeBuild_ReShape sbrs;

          for(TopExp_Explorer exp(aResult, TopAbs_WIRE); exp.More(); exp.Next())
              ShapeFix_Wire sfw(TopoDS::Wire(exp.Current()), aResult, Precision::Confusion());
              sfw.FixAddPCurveMode() = true;

              sbrs.Replace(exp.Current(), sfw.Wire());

          aResult = TopoDS::Face(sbrs.Apply(aResult));
        // perform substitution of faces

        myContext->Merge(faces, aResult);

It seems to me that, as I mentioned before the problem is that edge is reversed in both faces, meaning that both faces use same 2d curve from curve_onclosedsurface.
msv (developer)
2018-09-26 22:07

How did you find that edge has the same orientation in both faces? If we speak about the attached shape_before.brep then I have checked, and in both the input shape and the result of unification all common edges of concerned faces have different orientation in adjacent faces. Look at draw commands with output:

restore shape_before.brep a
unifysamedom r a

explode a f
explode a_1 e
explode a_5 e
explode a_2 e
explode a_8 e
whatis a_1_4 a_5_1
#a_1_4 is a shape EDGE REVERSED Modified Orientable
#a_5_1 is a shape EDGE FORWARD Modified Orientable
whatis a_2_4 a_8_1
#a_2_4 is a shape EDGE REVERSED Modified Orientable
#a_8_1 is a shape EDGE FORWARD Modified Orientable

explode r f
explode r_1 e
explode r_4 e
whatis r_1_3 r_4_1
#r_1_3 is a shape EDGE FORWARD Modified Orientable
#r_4_1 is a shape EDGE REVERSED Modified Orientable
msv (developer)
2018-09-26 22:13

So, my first note 0030158:0079377 is left in force.

I think that such fix is to be done by FixShape algorithm. Now it misses such fix. So, the best way to solve the problem is to add new kind of fix to ShapeFix, and then call the fix from UnifySameDomain on the final result of the algorithm.
denix56 (reporter)
2018-09-27 11:39

It seems I misunderstand something.
I`ve attached file after performing such fix and fixshifting after that. But the face is still incorrect. Could you please check that shape as you done before?
msv (developer)
2018-09-28 11:08

The new shape.brep looks to be valid:
Draw[1]> rest shape.brep r
Draw[3]> checksh r
This shape seems to be valid

I have checked the faces and edges deeper, and found out no problem. The edge now has the only curve on closed surface representation, and the face is closed in parameteric space.
How did you obtain such result? Can we add such fix in the code of UnifySameDomain?
denix56 (reporter)
2018-09-28 18:07

This fix does not fixed the face and when you perform brepcheck on faces it would be unorientable. I am convinced that problem is in the fact that common edge is reversed in both faces, and fix shifted will break it as before.
denix56 (reporter)
2018-10-04 08:44

Try to perform check on each face of the shape, maybe ut will show problems that occur.
msv (developer)
2018-10-05 18:48

I have checked it twice, it is valid, no invalid faces in it. Which OCCT version do you use?
denix56 (reporter)
2018-10-16 15:59
edited on: 2018-10-16 16:01

Sorry, it seems that i provide not the shape that has a problem. Saved wrong one.
Here is one that has holes instead of faces

msv (developer)
2019-06-21 17:57

Sorry for long delay.
I have inspected the shape2.brep. It is invalid according to checkshape. And it is correct information.
I have uploaded several screenshots to show what is incorrect in this shape.
The picture 2_faces.PNG shows two faces a_1 and a_4 built on the same cylinder in 3D space view.
The picture 2_faces_vori_1.PNG shows these faces, but the face a_1 is shown with orientations of its edges. The common edge is forward.
The picture 2_faces_vori_4.PNG shows the same, but the face a_4 is shown with orientations. The common edge is reversed.
The picture 2_faces_pcurves_1.PNG shows pcurves of a_1 in 2D space. We see that one edge is shifted in the right direction.
The picture 2_faces_pcurves_4.PNG shows pcurves of a_4. We see the same pcurve of the seam edge is used here but with another edge orientation.

This proves the conclusion I have made in the note 0030158:0079377.
msv (developer)
2019-08-12 17:36

This bug is fixed with #30534. Please close it.

- Issue History
Date Modified Username Field Change
2018-09-24 13:34 denix56 New Issue
2018-09-24 13:34 denix56 Assigned To => kgv
2018-09-24 13:34 denix56 File Added: ShapeUpgrade_UnifySameDomain.cxx.patch
2018-09-24 13:34 denix56 File Added: shape_before.brep
2018-09-24 13:34 denix56 File Added: shape_after.brep
2018-09-24 13:39 kgv Assigned To kgv => gka
2018-09-24 13:39 kgv Summary Incorrect result produced by ShapeUpgrade_UnifySameDomain => Shape Healing - Incorrect result produced by ShapeUpgrade_UnifySameDomain
2018-09-24 14:10 abv Assigned To gka => msv
2018-09-24 19:55 msv Note Added: 0079377
2018-09-24 19:59 msv Relationship added duplicate of 0029504
2018-09-24 19:59 msv Note Added: 0079378
2018-09-26 10:54 denix56 Note Added: 0079406
2018-09-26 16:13 msv Note Added: 0079414
2018-09-26 20:08 denix56 Note Added: 0079419
2018-09-26 22:07 msv Note Added: 0079420
2018-09-26 22:13 msv Note Added: 0079421
2018-09-27 11:36 denix56 File Added: shape.brep
2018-09-27 11:39 denix56 Note Added: 0079435
2018-09-28 11:08 msv Note Added: 0079466
2018-09-28 18:07 denix56 Note Added: 0079494
2018-10-04 08:44 denix56 Note Added: 0079663
2018-10-05 18:48 msv Note Added: 0079737
2018-10-16 15:59 denix56 Note Added: 0080019
2018-10-16 15:59 denix56 File Added: shape2.brep
2018-10-16 16:01 denix56 Note Edited: 0080019 View Revisions
2018-10-19 20:26 denix56 Tag Attached: ShapeUpgrade_UnifySameDomain
2019-06-21 17:46 msv File Added: 2_faces.PNG
2019-06-21 17:46 msv File Added: 2_faces_vori_1.PNG
2019-06-21 17:47 msv File Added: 2_faces_vori_4.PNG
2019-06-21 17:47 msv File Added: 2_faces_pcurves_1.PNG
2019-06-21 17:47 msv File Added: 2_faces_pcurves_4.PNG
2019-06-21 17:57 msv Note Added: 0085209
2019-06-27 13:18 jgv File Deleted: shape_before.brep
2019-06-27 13:18 jgv File Deleted: shape.brep
2019-06-27 13:19 jgv File Added: bug30158_1.brep
2019-06-27 13:19 jgv File Added: bug30158_2.brep
2019-07-17 11:51 msv Relationship added related to 0030534
2019-08-12 17:36 msv Note Added: 0086206
2019-08-12 17:36 msv Assigned To msv => bugmaster
2019-08-12 17:36 msv Status new => feedback
2019-08-12 17:36 msv Steps to Reproduce Updated View Revisions
2019-08-13 16:31 bugmaster Test case number => Not required
2019-08-13 16:31 bugmaster Status feedback => verified
2019-08-13 16:31 bugmaster Resolution open => fixed
2019-10-21 13:57 abv Target Version => 7.4.0

Copyright © 2000 - 2021 MantisBT Team
Powered by Mantis Bugtracker