MantisBT - Community
View Issue Details
0030158Community[OCCT] OCCT:Shape Healingpublic2018-09-24 13:342019-08-13 16:31
WindowsVC++ 201564 bit
[OCCT] 7.3.0 
Not required
0030158: Shape Healing - Incorrect result produced by ShapeUpgrade_UnifySameDomain
The 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.
test bugs modalg_7 bug30158_1
test bugs modalg_7 bug30158_2
duplicate of 0029504verified bugmaster Open CASCADE ShapeUpgrade_UnifySameDomain produces invalid shape and ShapeFix_Shape is unable to fix it 
patch ShapeUpgrade_UnifySameDomain.cxx.patch (1,902) 2018-09-24 13:34
? shape_after.brep (30,129) 2018-09-24 13:34
? shape2.brep (16,031) 2018-10-16 15:59
png 2_faces.PNG (7,473) 2019-06-21 17:46
png 2_faces_vori_1.PNG (9,186) 2019-06-21 17:46
png 2_faces_vori_4.PNG (8,867) 2019-06-21 17:47
png 2_faces_pcurves_1.PNG (4,783) 2019-06-21 17:47
png 2_faces_pcurves_4.PNG (4,104) 2019-06-21 17:47
? bug30158_1.brep (30,145) 2019-06-27 13:19
? bug30158_2.brep (32,090) 2019-06-27 13:19
Issue History
2018-09-24 13:34denix56New Issue
2018-09-24 13:34denix56Assigned To => kgv
2018-09-24 13:34denix56File Added: ShapeUpgrade_UnifySameDomain.cxx.patch
2018-09-24 13:34denix56File Added: shape_before.brep
2018-09-24 13:34denix56File Added: shape_after.brep
2018-09-24 13:39kgvAssigned Tokgv => gka
2018-09-24 13:39kgvSummaryIncorrect result produced by ShapeUpgrade_UnifySameDomain => Shape Healing - Incorrect result produced by ShapeUpgrade_UnifySameDomain
2018-09-24 14:10abvAssigned Togka => msv
2018-09-24 19:55msvNote Added: 0079377
2018-09-24 19:59msvRelationship addedduplicate of 0029504
2018-09-24 19:59msvNote Added: 0079378
2018-09-26 10:54denix56Note Added: 0079406
2018-09-26 16:13msvNote Added: 0079414
2018-09-26 20:08denix56Note Added: 0079419
2018-09-26 22:07msvNote Added: 0079420
2018-09-26 22:13msvNote Added: 0079421
2018-09-27 11:36denix56File Added: shape.brep
2018-09-27 11:39denix56Note Added: 0079435
2018-09-28 11:08msvNote Added: 0079466
2018-09-28 18:07denix56Note Added: 0079494
2018-10-04 08:44denix56Note Added: 0079663
2018-10-05 18:48msvNote Added: 0079737
2018-10-16 15:59denix56Note Added: 0080019
2018-10-16 15:59denix56File Added: shape2.brep
2018-10-16 16:01denix56Note Edited: 0080019bug_revision_view_page.php?bugnote_id=80019#r20129
2018-10-19 20:26denix56Tag Attached: ShapeUpgrade_UnifySameDomain
2019-06-21 17:46msvFile Added: 2_faces.PNG
2019-06-21 17:46msvFile Added: 2_faces_vori_1.PNG
2019-06-21 17:47msvFile Added: 2_faces_vori_4.PNG
2019-06-21 17:47msvFile Added: 2_faces_pcurves_1.PNG
2019-06-21 17:47msvFile Added: 2_faces_pcurves_4.PNG
2019-06-21 17:57msvNote Added: 0085209
2019-06-27 13:18jgvFile Deleted: shape_before.brep
2019-06-27 13:18jgvFile Deleted: shape.brep
2019-06-27 13:19jgvFile Added: bug30158_1.brep
2019-06-27 13:19jgvFile Added: bug30158_2.brep
2019-07-17 11:51msvRelationship addedrelated to 0030534
2019-08-12 17:36msvNote Added: 0086206
2019-08-12 17:36msvAssigned Tomsv => bugmaster
2019-08-12 17:36msvStatusnew => feedback
2019-08-12 17:36msvSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=21637#r21637
2019-08-13 16:31bugmasterTest case number => Not required
2019-08-13 16:31bugmasterStatusfeedback => verified
2019-08-13 16:31bugmasterResolutionopen => fixed

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.
2018-09-24 19:59   
The bug 0029504 describes exactly the same problem.
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.
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.
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.
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
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.
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?
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?
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.
2018-10-04 08:44   
Try to perform check on each face of the shape, maybe ut will show problems that occur.
2018-10-05 18:48   
I have checked it twice, it is valid, no invalid faces in it. Which OCCT version do you use?
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

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.
2019-08-12 17:36   
This bug is fixed with #30534. Please close it.