Notes 

(0079377)

msv

20180924 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 pcurves (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. 


(0079378)

msv

20180924 19:59


The bug 0029504 describes exactly the same problem. 



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. 


(0079414)

msv

20180926 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 noncoherent faces orientation there. 



I tried to add this code:
if(!sff.Status(ShapeExtend_FAIL))
{
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());
if(mySafeInputMode)
sfw.SetContext(myContext);
sfw.FixAddPCurveMode() = true;
sfw.FixEdgeCurves();
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. 


(0079420)

msv

20180926 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



(0079421)

msv

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



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? 


(0079466)

msv

20180928 11:08


The new shape.brep looks to be valid:
Draw[1]> rest shape.brep r
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? 



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. 



Try to perform check on each face of the shape, maybe ut will show problems that occur. 


(0079737)

msv

20181005 18:48


I have checked it twice, it is valid, no invalid faces in it. Which OCCT version do you use? 


(0080019)

denix56

20181016 15:59
(edited on: 20181016 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



(0085209)

msv

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


(0086206)

msv

20190812 17:36


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