Archived issue #0024983
For the incorrect seam edge in STEP file no fix is provided
Description
Since the original geometry in STEP file is corrupted, I've marked the ticket as "question". The original file was generated by Adobe 3D Reviewer (part of Acrobat Extended Pro) by our customer. The attached file is "synthetic" - the single face was manually extracted from the original file. The header is also changed due to security reasons.
The problem: ShapeFix_ComposeShell creates 3 empty faces for the specified geometry instead of creating a seam edge on the conical surface (I've checked already the solution from CR24055, it doesn't help).
The reason: STEP file contains predefined seam edge (check references #2720, #2721), but the defined seam edge isn't high enough. ShapeFix_ComposeShell identifies the specified edge as seam, and therefore doesn't try to build another seam edge, which will satisfy the condition and construct the face instead of splitting it into peaces.
Proving workaround: removing references #2720, #2721 from the edge loop #1628 resolves the problem - ShapeFix_ComposeShell doesn't find any existing seam edge and builds the correct one.
Question: is it possible to automate the identification of wrong seam edges? I expect, that the answer is "No", since it's impossible strictly to define which seam edge is wrong. As a proposal: maybe it's possible to introduce a flag for ShapeFix, that it should always try to through away any existing seam edges and build a new one?
The problem: ShapeFix_ComposeShell creates 3 empty faces for the specified geometry instead of creating a seam edge on the conical surface (I've checked already the solution from CR24055, it doesn't help).
The reason: STEP file contains predefined seam edge (check references #2720, #2721), but the defined seam edge isn't high enough. ShapeFix_ComposeShell identifies the specified edge as seam, and therefore doesn't try to build another seam edge, which will satisfy the condition and construct the face instead of splitting it into peaces.
Proving workaround: removing references #2720, #2721 from the edge loop #1628 resolves the problem - ShapeFix_ComposeShell doesn't find any existing seam edge and builds the correct one.
Question: is it possible to automate the identification of wrong seam edges? I expect, that the answer is "No", since it's impossible strictly to define which seam edge is wrong. As a proposal: maybe it's possible to introduce a flag for ShapeFix, that it should always try to through away any existing seam edges and build a new one?
Steps to reproduce
Import the attached file into the viewer and check the result.
Public activity
17 archived notes
Participants are labeled by their role within this record.
This kind of situation can be detected by presence of the same edge twice in the wire, without one of its end vertices being not shared by any other edge in the same wire. In fact, some kind of this check should be already made (likely in ShapeFix); at least wire consisting of only seam edge (see EDGE_LOOP #1626) gets successfully removed during translation. If ShapeFix already has code for treatment of this case (perhaps FixNotched()?), the solution could be just reordering fixes so as to have that fix prior to FixMissingSeam.
Changing the sequence of fixes in ShapeFix_Face::Perform resolves the issue. I'll commit the change in order to verify if it doesn't effect any other tests. Should be a test case created?
The changed is committed. Please, verify it.
Dmitry, the commit looks fine, just could you please make it a single commit on top of current master?
The test case will be created as part of testing process by our QA team, though you are welcome to provide draft.
The test case will be created as part of testing process by our QA team, though you are welcome to provide draft.
Sorry for messing up the things. I've committed the changes on the root and pushed it to branch CR24983_1
No remarks, please test (branch CR24983_2)
Dmitry, I have rebased this change on master as simple commit, not a merge one (merge commit, being one commit after master, still contains all changes from the merged branch), and added a test case (bugs heal bug24983). Note that STEP file is not included in commit (can be placed to tests/heal/data for running test).
Dmitry, I have rebased this change on master as simple commit, not a merge one (merge commit, being one commit after master, still contains all changes from the merged branch), and added a test case (bugs heal bug24983). Note that STEP file is not included in commit (can be placed to tests/heal/data for running test).
Dear BugMaster,
Branch CR24983_2 (and products from GIT master) was compiled on Linux, MacOS and Windows platforms and tested.
[revision removed]
Number of compiler warnings:
occt component :
Linux: 16 (16 on master)
Windows: 0 (0 on master)
MacOS: 203 (203 on master)
products component :
Linux: 11 (11 on master)
Windows: 2 (2 on master)
Regressions/Differences:
http://occt-tests/CR24983-2-master-occt/Debian60-64/summary.html
http://occt-tests/CR24983-2-master-occt/Windows-32-VC9/summary.html
de iges_1(001) G9, I3, L8, M6, O5, R8
de iges_2(002) F4, G4, H9
de iges_3(003) A2, B2
de step_2(005) F1, W2
de step_3(006) E6
Testing cases:
http://occt-tests/CR24983-2-master-occt/Debian60-64/bugs/heal/bug24983.html
http://occt-tests/CR24983-2-master-occt/Windows-32-VC9/bugs/heal/bug24983.html
bugs heal(017) bug24983: OK
Testing on Linux:
Total MEMORY difference: 357776136 / 358087976
Total CPU difference: 49297.68 / 52024.34
Testing on Windows:
Total MEMORY difference: 381338176 / 381625692
Total CPU difference: 38684.328125 / 41886.671875
There are no differences in images found by testdiff.
Branch CR24983_2 (and products from GIT master) was compiled on Linux, MacOS and Windows platforms and tested.
[revision removed]
Number of compiler warnings:
occt component :
Linux: 16 (16 on master)
Windows: 0 (0 on master)
MacOS: 203 (203 on master)
products component :
Linux: 11 (11 on master)
Windows: 2 (2 on master)
Regressions/Differences:
http://occt-tests/CR24983-2-master-occt/Debian60-64/summary.html
http://occt-tests/CR24983-2-master-occt/Windows-32-VC9/summary.html
de iges_1(001) G9, I3, L8, M6, O5, R8
de iges_2(002) F4, G4, H9
de iges_3(003) A2, B2
de step_2(005) F1, W2
de step_3(006) E6
Testing cases:
http://occt-tests/CR24983-2-master-occt/Debian60-64/bugs/heal/bug24983.html
http://occt-tests/CR24983-2-master-occt/Windows-32-VC9/bugs/heal/bug24983.html
bugs heal(017) bug24983: OK
Testing on Linux:
Total MEMORY difference: 357776136 / 358087976
Total CPU difference: 49297.68 / 52024.34
Testing on Windows:
Total MEMORY difference: 381338176 / 381625692
Total CPU difference: 38684.328125 / 41886.671875
There are no differences in images found by testdiff.
Irina, could you please have a look at the regressions reported? The first seem to be just decrease of number of edges, though in the end of the list some more checkshape faces are shown...
The analysis led to the following results:
Improvements (number of invalid faces is decreased):
iges_1 O5
iges_2 F4
iges_3 A2
step_3 E6
Regressions:
step_2 F1 - face is read incorrect (see attached Attachment 3 (PNG)) but checkshape is OK, after writing and second reading this face became invalid (attached Attachment 2 (PNG))
Other tests are not regressions of improvements, only new behavior.
Improvements (number of invalid faces is decreased):
iges_1 O5
iges_2 F4
iges_3 A2
step_3 E6
Regressions:
step_2 F1 - face is read incorrect (see attached Attachment 3 (PNG)) but checkshape is OK, after writing and second reading this face became invalid (attached Attachment 2 (PNG))
Other tests are not regressions of improvements, only new behavior.
Add check for invalid Surface of linear extrusion (with basis curve - line and extrusion direction parallel to this line) during converting STEP surface.
Branch CR24983_2 is ready to be reviewed.
Dear GKA,
Please review.
Branch CR24983_2 is ready to be reviewed.
Dear GKA,
Please review.
Branch CR24983 is ready to be tested
Dear BugMaster,
Branch CR24983_2 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested.
[revision removed]
Number of compiler warnings:
occt component :
Linux: 16 (16 on master)
Windows: 0 (0 on master)
MacOS: 200 (203 on master)
products component :
Linux: 11 (11 on master)
Windows: 2 (2 on master)
Regressions/Differences:
http://occt-tests/CR24983-2-master-occt/Debian60-64/summary.html
http://occt-tests/CR24983-2-master-occt/Windows-32-VC9/summary.html
de iges_1(001) G9, I3, L8, M6, O5, R8
de iges_2(002) F4, G4, H9
de iges_3(003) A2, B2
de step_2(005) F1, W2
de step_3(006) E6
Testing cases:
http://occt-tests/CR24983-2-master-occt/Debian60-64/bugs/heal/bug24983.html
http://occt-tests/CR24983-2-master-occt/Windows-32-VC9/bugs/heal/bug24983.html
bugs heal(017) bug24983: OK
Testing on Linux:
Total MEMORY difference: 336442728 / 336637348
Total CPU difference: 49223.69000000001 / 44189.09
Testing on Windows:
Total MEMORY difference: 374380072 / 374695312
Total CPU difference: 39062.390625 / 37900.515625
There are no differences in images found by testdiff.
Branch CR24983_2 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested.
[revision removed]
Number of compiler warnings:
occt component :
Linux: 16 (16 on master)
Windows: 0 (0 on master)
MacOS: 200 (203 on master)
products component :
Linux: 11 (11 on master)
Windows: 2 (2 on master)
Regressions/Differences:
http://occt-tests/CR24983-2-master-occt/Debian60-64/summary.html
http://occt-tests/CR24983-2-master-occt/Windows-32-VC9/summary.html
de iges_1(001) G9, I3, L8, M6, O5, R8
de iges_2(002) F4, G4, H9
de iges_3(003) A2, B2
de step_2(005) F1, W2
de step_3(006) E6
Testing cases:
http://occt-tests/CR24983-2-master-occt/Debian60-64/bugs/heal/bug24983.html
http://occt-tests/CR24983-2-master-occt/Windows-32-VC9/bugs/heal/bug24983.html
bugs heal(017) bug24983: OK
Testing on Linux:
Total MEMORY difference: 336442728 / 336637348
Total CPU difference: 49223.69000000001 / 44189.09
Testing on Windows:
Total MEMORY difference: 374380072 / 374695312
Total CPU difference: 39062.390625 / 37900.515625
There are no differences in images found by testdiff.
Dear MKV,
As I wrote before,
de iges_1(001) G9, I3, L8, M6, O5, R8
de iges_2(002) F4, G4, H9
de iges_3(003) A2, B2
de step_2(005) W2
de step_3(006) E6
are not regressions,
what about
de step_2(005) F1 - it is new right behavior.
So could you please regenerate reference data of all these tests?
As I wrote before,
de iges_1(001) G9, I3, L8, M6, O5, R8
de iges_2(002) F4, G4, H9
de iges_3(003) A2, B2
de step_2(005) W2
de step_3(006) E6
are not regressions,
what about
de step_2(005) F1 - it is new right behavior.
So could you please regenerate reference data of all these tests?
Dear BugMaster,
following test cases are corrected and pushed to branch CR24983_2
de iges_1(001) G9, I3, L8, M6, O5, R8
de iges_2(002) F4, G4, H9
de iges_3(003) A2, B2
de step_2(005) F1, W2
de step_3(006) E6
following test cases are corrected and pushed to branch CR24983_2
de iges_1(001) G9, I3, L8, M6, O5, R8
de iges_2(002) F4, G4, H9
de iges_3(003) A2, B2
de step_2(005) F1, W2
de step_3(006) E6
Branch [archived branch] has been deleted by Participant.
[revision removed]
[revision removed]
Branch [archived branch] has been deleted by Participant.
[revision removed]
[revision removed]
Branch [archived branch] has been deleted by Participant.
[revision removed]
[revision removed]