|Anonymous | Login||2019-08-24 12:48 MSK|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0030158||Community||[OCCT] OCCT:Shape Healing||public||2018-09-24 13:34||2019-08-13 16:31|
|Platform||Windows||OS||VC++ 2015||OS Version||64 bit|
|Product Version||[OCCT] 7.3.0|
|Target Version||Fixed in Version|
|Summary||0030158: Shape Healing - Incorrect result produced by ShapeUpgrade_UnifySameDomain|
|Description||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.
|Steps To Reproduce||test bugs modalg_7 bug30158_1|
test bugs modalg_7 bug30158_2
|Test case number||Not required|
|Attached Files|| ShapeUpgrade_UnifySameDomain.cxx.patch (1,902 bytes) 2018-09-24 13:34|
shape_after.brep (30,129 bytes) 2018-09-24 13:34
shape2.brep (16,031 bytes) 2018-10-16 15:59
2_faces.PNG (7,473 bytes) 2019-06-21 17:46
2_faces_vori_1.PNG (9,186 bytes) 2019-06-21 17:46
2_faces_vori_4.PNG (8,867 bytes) 2019-06-21 17:47
2_faces_pcurves_1.PNG (4,783 bytes) 2019-06-21 17:47
2_faces_pcurves_4.PNG (4,104 bytes) 2019-06-21 17:47
bug30158_1.brep (30,145 bytes) 2019-06-27 13:19
bug30158_2.brep (32,090 bytes) 2019-06-27 13:19
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.
|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.
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.
I tried to add this code:
aResult = sff.Face();
for(TopExp_Explorer exp(aResult, TopAbs_WIRE); exp.More(); exp.Next())
ShapeFix_Wire sfw(TopoDS::Wire(exp.Current()), aResult, Precision::Confusion());
sfw.FixAddPCurveMode() = true;
aResult = TopoDS::Face(sbrs.Apply(aResult));
// perform substitution of faces
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.
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
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?
The new shape.brep looks to be valid:
Draw> rest shape.brep r r Draw> 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.|
|I have checked it twice, it is valid, no invalid faces in it. Which OCCT version do you use?|
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
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.
|This bug is fixed with #30534. Please close it.|
|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|
|Copyright © 2000 - 2019 MantisBT Team|