Archived issue #0026532
Meshing of edge with minSize parameter leads to incorrect result
Description
For the appended edge, the meshing with minSize parameter leads to a wrong, unexpected result. The polygon node distribution is quite asymmetric. The last two polygon segments are very large. In consequence, the visualization of the edge is not smooth.
This seems to be a bug because a minSize of 0.06 should not lead to such a coarse visualization because the model is quite big (curve length ~ 1200).
This seems to be a bug because a minSize of 0.06 should not lead to such a coarse visualization because the model is quite big (curve length ~ 1200).
Steps to reproduce
# with min size
restore Attachment 1 (BREP) a
vdisplay a
vclear
incmesh a 0.3 -min 0.06
vdisplay a
=> ugly curve
# without min size
restore Attachment 1 (BREP) a
vdisplay a
vclear
incmesh a 0.3
vdisplay a
=> nice curve
restore Attachment 1 (BREP) a
vdisplay a
vclear
incmesh a 0.3 -min 0.06
vdisplay a
=> ugly curve
# without min size
restore Attachment 1 (BREP) a
vdisplay a
vclear
incmesh a 0.3
vdisplay a
=> nice curve
Public activity
16 archived notes
Participants are labeled by their role within this record.
Branch [archived branch] has been created by Commenter 3.
[revision removed]
Detailed log of new commits:
Author: Commenter 3
Date: Wed Sep 16 15:57:29 2015 +0300
0026532: Meshing of edge with minSize parameter leads to incorrect result
Fix missed parameter.
[revision removed]
Detailed log of new commits:
Author: Commenter 3
Date: Wed Sep 16 15:57:29 2015 +0300
0026532: Meshing of edge with minSize parameter leads to incorrect result
Fix missed parameter.
Dear Mikhail,
could you please review the fix at branch CR26532.
could you please review the fix at branch CR26532.
Reviewed.
Dear Commenter 1,
Branch CR26532 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested on Release mode.
[revision removed]
Number of compiler warnings:
occt component :
Linux: 15 (15 on master)
Windows: 0 (0 on master)
products component :
Linux: 39 (39 on master)
Windows: 0 (0 on master)
Regressions/Differences/Improvements:
No regressions/differences
Testing cases:
http://occt-tests/CR26532-master-occt-64/Debian70-64/bugs/mesh/bug26532.html
http://occt-tests/CR26532-master-occt-64/Windows-64-VC10/bugs/mesh/bug26532.html
bugs mesh bug26532: OK
Testing on Linux:
occt component :
Total MEMORY difference: 92175374 / 92763477 [-0.63%]
Total CPU difference: 18078.759999999078 / 17943.299999999086 [+0.75%]
products component :
Total MEMORY difference: 25861501 / 25875135 [-0.05%]
Total CPU difference: 7212.699999999991 / 7185.6699999999955 [+0.38%]
Testing on Windows:
occt component :
Total MEMORY difference: 57715737 / 57708424 [+0.01%]
Total CPU difference: 16589.271140798977 / 16459.571909399227 [+0.79%]
products component :
Total MEMORY difference: 16782689 / 16782651 [+0.00%]
Total CPU difference: 5697.250120599973 / 5565.444875699965 [+2.37%]
There are no differences in images found by testdiff.
Branch CR26532 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested on Release mode.
[revision removed]
Number of compiler warnings:
occt component :
Linux: 15 (15 on master)
Windows: 0 (0 on master)
products component :
Linux: 39 (39 on master)
Windows: 0 (0 on master)
Regressions/Differences/Improvements:
No regressions/differences
Testing cases:
http://occt-tests/CR26532-master-occt-64/Debian70-64/bugs/mesh/bug26532.html
http://occt-tests/CR26532-master-occt-64/Windows-64-VC10/bugs/mesh/bug26532.html
bugs mesh bug26532: OK
Testing on Linux:
occt component :
Total MEMORY difference: 92175374 / 92763477 [-0.63%]
Total CPU difference: 18078.759999999078 / 17943.299999999086 [+0.75%]
products component :
Total MEMORY difference: 25861501 / 25875135 [-0.05%]
Total CPU difference: 7212.699999999991 / 7185.6699999999955 [+0.38%]
Testing on Windows:
occt component :
Total MEMORY difference: 57715737 / 57708424 [+0.01%]
Total CPU difference: 16589.271140798977 / 16459.571909399227 [+0.79%]
products component :
Total MEMORY difference: 16782689 / 16782651 [+0.00%]
Total CPU difference: 5697.250120599973 / 5565.444875699965 [+2.37%]
There are no differences in images found by testdiff.
Branch [archived branch] has been updated by Participant.
[revision removed]
Detailed log of new commits:
Author: mkv
Date: Thu Sep 17 12:28:31 2015 +0300
Test case for issue CR26532
[revision removed]
Detailed log of new commits:
Author: mkv
Date: Thu Sep 17 12:28:31 2015 +0300
Test case for issue CR26532
Dear oan,
could you please review following test case
bugs mesh bug26532
could you please review following test case
bugs mesh bug26532
Dear Mikhail,
current implementation of test has no meaning due to absence of any logical check.
It is necessary to add check for equality of number of discretization points (and their coordinates) due to the fact that such a small restriction for min size parameter plays no role for resulting number of points.
Info about discretization points can be taken using dump command, part "Dump of 1 Polygon3Ds"
current implementation of test has no meaning due to absence of any logical check.
It is necessary to add check for equality of number of discretization points (and their coordinates) due to the fact that such a small restriction for min size parameter plays no role for resulting number of points.
Info about discretization points can be taken using dump command, part "Dump of 1 Polygon3Ds"
Dear oan,
test case
bugs mesh bug26532
will be corrected tomorrow.
test case
bugs mesh bug26532
will be corrected tomorrow.
You can try using the command trinfo instead of dump to evaluate the number of mesh nodes.
trinfo will give nothing in this case as far as it reports info about triangulation stored in the shape.
In this case it is just a free edge and BRepMesh stores discretization inside Poly_Polygon3D that is not considered by trinfo.
In this case it is just a free edge and BRepMesh stores discretization inside Poly_Polygon3D that is not considered by trinfo.
Branch [archived branch] has been updated by Participant.
[revision removed]
Detailed log of new commits:
Author: mkv
Date: Fri Sep 18 12:36:04 2015 +0300
Correction of test case for issue CR26532
[revision removed]
Detailed log of new commits:
Author: mkv
Date: Fri Sep 18 12:36:04 2015 +0300
Correction of test case for issue CR26532
Dear oan,
test case
bugs mesh bug26532
was corrected and pushed to branch CR26532 of occt git-repository,
could you please review it
http://occt-tests/CR26532-master-occt-64/Debian70-64/bugs/mesh/bug26532.html
http://occt-tests/CR26532-master-occt-64/Windows-64-VC10/bugs/mesh/bug26532.html
test case
bugs mesh bug26532
was corrected and pushed to branch CR26532 of occt git-repository,
could you please review it
http://occt-tests/CR26532-master-occt-64/Debian70-64/bugs/mesh/bug26532.html
http://occt-tests/CR26532-master-occt-64/Windows-64-VC10/bugs/mesh/bug26532.html
Dear Mikhail,
test script does not work properly. I have tried to use "incmesh a 0.3 -min 100" instead of "incmesh a 0.3 -min 0.06" but test is still OK while number of points and their coordinates should be different.
Please modify test case and check it. Note that shape should be restored twice, not only at the beginning of the script, but before each incmesh as far as algorithm overrides existing triangulation only if deflection of existing polygon is greater than specified.
test script does not work properly. I have tried to use "incmesh a 0.3 -min 100" instead of "incmesh a 0.3 -min 0.06" but test is still OK while number of points and their coordinates should be different.
Please modify test case and check it. Note that shape should be restored twice, not only at the beginning of the script, but before each incmesh as far as algorithm overrides existing triangulation only if deflection of existing polygon is greater than specified.
Branch [archived branch] has been updated by Participant.
[revision removed]
Detailed log of new commits:
Author: mkv
Date: Fri Sep 18 13:22:49 2015 +0300
Correction of test case for issue CR26532
[revision removed]
Detailed log of new commits:
Author: mkv
Date: Fri Sep 18 13:22:49 2015 +0300
Correction of test case for issue CR26532
Dear Commenter 1,
test case
bugs mesh bug26532
was corrected and pushed to branch CR26532 of occt git-repository,
Dear Commenter 1,
Branch CR26532 is TESTED.
test case
bugs mesh bug26532
was corrected and pushed to branch CR26532 of occt git-repository,
Dear Commenter 1,
Branch CR26532 is TESTED.
Branch [archived branch] has been deleted by Participant.
[revision removed]
[revision removed]
Related records