Archived issue #0025044
BRepMesh tweaks
Description
At the code base 6.6.0 I made several modifications to BRepMesh code in order to receive more consistent mesh for my model data base. At the current code base, my modifications also perform equally or better in 80% cases. Unfortunately, it's almost impossible to merge properly my modifications to the current code base, therefore I commit them as they are.
Besides the better mesh results, my modifications can use ProgressIndicator in order to represent the meshing progress and to abort processing.
According to my performance comparison, my modifications perform up to 10% slower as the current code base (for the most of the models the difference is 1-2%).
Besides the better mesh results, my modifications can use ProgressIndicator in order to represent the meshing progress and to abort processing.
According to my performance comparison, my modifications perform up to 10% slower as the current code base (for the most of the models the difference is 1-2%).
Steps to reproduce
pload ALL
stepread bicycle.step a *
renamevar a_1 a
tclean a
set faces [explode a f]
set nb [llength $faces]
for {set i 1} {$i <= $nb} {incr i} {
set info [incmesh a_$i 0.31]
set status [lindex $info 6]
if { [string compare $status "NoError"] != 0 && [string compare $status "Reused"] != 0 } {
puts $i; puts " - "; puts $status
}
}
stepread bicycle.step a *
renamevar a_1 a
tclean a
set faces [explode a f]
set nb [llength $faces]
for {set i 1} {$i <= $nb} {incr i} {
set info [incmesh a_$i 0.31]
set status [lindex $info 6]
if { [string compare $status "NoError"] != 0 && [string compare $status "Reused"] != 0 } {
puts $i; puts " - "; puts $status
}
}
Additional information
Changes from 0024923 are also include in this commit.
Public activity
48 archived notes
Participants are labeled by their role within this record.
The tweaks are committed, please, review them
Hello!
Sorry for late reply. First of all, thank you a lot for your commitment.
We had to finish several activities related to BRepMesh and now I am going to explore tweaks you pushed to repository.
I have briefly inspected the changes and I immediately noticed a magnificent thing, the draft for progress indication functionality. I am going to integrate it first!
The bad news are that it is very difficult to recognize changes in BRepMesh_Delaun due to huge modifications made since 6.6.0. These modifications include functionality resolving some problematic cases as well as new approach of adjusting of a mesh to face boundaries and hence they are highly correlated with code in your branch.
Considering this fact it is preferable to check current state of OCCT for consistency with your model data base, therefore, I kindly ask you to provide models related to each tweak made in BRepMesh if possible. After that we can add them to OCCT non-regression testing base that will allow us to consider these cases for further evolution of the component. In order of private nature of that models we can place them to the base of private shapes that assures that they will not be available to anyone except of us. Concerning changes in general, could you please provide brief description for particular tweak? It is necessary to identify parts of code implemented in context of distinct problem as well as the problem itself.
Additionally, I suppose to split current issue on several ones in order of proper check for regressions and modifications if necessary. This will help us to apply changes more safely.
With [signature removed]
OAN
Sorry for late reply. First of all, thank you a lot for your commitment.
We had to finish several activities related to BRepMesh and now I am going to explore tweaks you pushed to repository.
I have briefly inspected the changes and I immediately noticed a magnificent thing, the draft for progress indication functionality. I am going to integrate it first!
The bad news are that it is very difficult to recognize changes in BRepMesh_Delaun due to huge modifications made since 6.6.0. These modifications include functionality resolving some problematic cases as well as new approach of adjusting of a mesh to face boundaries and hence they are highly correlated with code in your branch.
Considering this fact it is preferable to check current state of OCCT for consistency with your model data base, therefore, I kindly ask you to provide models related to each tweak made in BRepMesh if possible. After that we can add them to OCCT non-regression testing base that will allow us to consider these cases for further evolution of the component. In order of private nature of that models we can place them to the base of private shapes that assures that they will not be available to anyone except of us. Concerning changes in general, could you please provide brief description for particular tweak? It is necessary to identify parts of code implemented in context of distinct problem as well as the problem itself.
Additionally, I suppose to split current issue on several ones in order of proper check for regressions and modifications if necessary. This will help us to apply changes more safely.
With [signature removed]
OAN
Hello, oan,
Thank you for your feedback.
For sure, I checked the current state of OCCT BRepMesh module, and naturally it performs much better as 6.6.0 original state, but still in comparison with my modified version of 6.6.0 module it lacks in a lot of cases, as I've written in the description only in 20% of models the current OCCT BRepMesh module performs better as 6.6.0 with my modifications.
And unfortunately, due to the huge changes in BRepMesh module since version 6.6.0 it's almost impossible to merge my modifications directly into the current code base. I've discussed this situation already once with abv and he has recommended me to commit my changes as they are. I can provide you with unified diff of all my modifications in BRepMesh folder for 6.6.0, if it will help to identify the changes.
Regarding the models with failed meshes - it's quite hard for me to provide you with any kind of relevant models, because my models database consists from customers' models and we've signed do not share them further... The only thing I can do: I can extract 1,2 failing faces from models. But such analysis will take time...
So, how is it better to proceed further on your opinion? Should I just provide you with the unified diff? Or do you want me first to merge as much as possible with creating child tickets and the rest give you as unified diff?
[signature removed]
Dima
Thank you for your feedback.
For sure, I checked the current state of OCCT BRepMesh module, and naturally it performs much better as 6.6.0 original state, but still in comparison with my modified version of 6.6.0 module it lacks in a lot of cases, as I've written in the description only in 20% of models the current OCCT BRepMesh module performs better as 6.6.0 with my modifications.
And unfortunately, due to the huge changes in BRepMesh module since version 6.6.0 it's almost impossible to merge my modifications directly into the current code base. I've discussed this situation already once with abv and he has recommended me to commit my changes as they are. I can provide you with unified diff of all my modifications in BRepMesh folder for 6.6.0, if it will help to identify the changes.
Regarding the models with failed meshes - it's quite hard for me to provide you with any kind of relevant models, because my models database consists from customers' models and we've signed do not share them further... The only thing I can do: I can extract 1,2 failing faces from models. But such analysis will take time...
So, how is it better to proceed further on your opinion? Should I just provide you with the unified diff? Or do you want me first to merge as much as possible with creating child tickets and the rest give you as unified diff?
[signature removed]
Dima
Hello, Dima,
Concerning identification of changes in general, I have an idea: we can try to create a new branch with your changes relatively tag V6_0_0 (commit hash [revision removed]), not the current master. Like this, we can eliminate stratification of changes made since that version and retrieve actual modifications. So, I suppose that there is no necessity to prepare a unified diff.
If I get you right, you did not use some source control software on your workstation to track changes related to particular problem. If I am wrong, it would be nice if you provided a set of diffs with changes implementing some functionality in context of a single problem. If not, it would be quite helpful if you prepared some small description for the cases you fixed. On the other hand, test models contain such description in itself.
As for the test cases, it would be even more suitable if you provided only problematic parts of models. I suppose that you have accumulated an extensive database and extraction of problematic cases can take a lot of time, so I would suggest to automate this process using Draw. For instance in the following way:
pload ALL
set name <some_model>
#in case of BREP file
restore $name a
# in case of STEP files the code might be the following:
stepread $name a *
renamevar a_1 a
tclean a
set faces [explode a f]
set nb [llength $faces]
for {set i 1} {$i <= $nb} {incr i} {
set info [incmesh a_$i 10]
# deflection can be set to another value
set status [lindex $info 6]
if { [string compare $status "NoError"] != 0 } {
save a_$i ${name}_face${i}.brep
}
}
[signature removed]
Oleg
Concerning identification of changes in general, I have an idea: we can try to create a new branch with your changes relatively tag V6_0_0 (commit hash [revision removed]), not the current master. Like this, we can eliminate stratification of changes made since that version and retrieve actual modifications. So, I suppose that there is no necessity to prepare a unified diff.
If I get you right, you did not use some source control software on your workstation to track changes related to particular problem. If I am wrong, it would be nice if you provided a set of diffs with changes implementing some functionality in context of a single problem. If not, it would be quite helpful if you prepared some small description for the cases you fixed. On the other hand, test models contain such description in itself.
As for the test cases, it would be even more suitable if you provided only problematic parts of models. I suppose that you have accumulated an extensive database and extraction of problematic cases can take a lot of time, so I would suggest to automate this process using Draw. For instance in the following way:
pload ALL
set name <some_model>
#in case of BREP file
restore $name a
# in case of STEP files the code might be the following:
stepread $name a *
renamevar a_1 a
tclean a
set faces [explode a f]
set nb [llength $faces]
for {set i 1} {$i <= $nb} {incr i} {
set info [incmesh a_$i 10]
# deflection can be set to another value
set status [lindex $info 6]
if { [string compare $status "NoError"] != 0 } {
save a_$i ${name}_face${i}.brep
}
}
[signature removed]
Oleg
Hello, Oleg,
Thanks for a tip to fast extracting the faces, this will definitely help me!
We use SVN on our side for source controlling, but unfortunately due to bad internal repository policy I wasn't allowed to commit each change with the proper messages, therefore my svn log messages won't help at all.
But I'll embed the comments with some problem descriptions to all my changes.
Finally, regarding the merging of my changes, I think, that the most effective way will be the following:
1. I'll try and merge as much as it's possible with the current master, because some my modifications aren't overlapping with the general 6.7.0 changes. I'll check how does it improve the result mesh and commit all these changes.
2. I guess, that the rest of my changes are the changes, which are already integrated in the current master, but due to the big number of modifications in 6.7.0 code base, aren't recognizable any more.
I hope, this way will comfort you as well.
[signature removed]
Dima
Thanks for a tip to fast extracting the faces, this will definitely help me!
We use SVN on our side for source controlling, but unfortunately due to bad internal repository policy I wasn't allowed to commit each change with the proper messages, therefore my svn log messages won't help at all.
But I'll embed the comments with some problem descriptions to all my changes.
Finally, regarding the merging of my changes, I think, that the most effective way will be the following:
1. I'll try and merge as much as it's possible with the current master, because some my modifications aren't overlapping with the general 6.7.0 changes. I'll check how does it improve the result mesh and commit all these changes.
2. I guess, that the rest of my changes are the changes, which are already integrated in the current master, but due to the big number of modifications in 6.7.0 code base, aren't recognizable any more.
I hope, this way will comfort you as well.
[signature removed]
Dima
Hello, Oleg,
I'm currently busy with merging my code with the current BRepMesh master and found very strange modification of the code. Could you please verify if it's done correctly:
6.6.0 code base BRepMesh_Vertex.cxx: Line 65
Standard_Boolean BRepMesh_Vertex::IsEqual(const BRepMesh_Vertex& Other)const
{
if (myMovability!=BRepMesh_Deleted && Other.myMovability!=BRepMesh_Deleted)
return (myUV.IsEqual(Other.myUV, Precision::PConfusion()));
return Standard_False;
}
Current master BRepMesh_Vertex.hxx: Line 111
Standard_EXPORT Standard_Boolean IsEqual(const BRepMesh_Vertex& theOther) const
{
if (myMovability != BRepMesh_Deleted ||
theOther.myMovability != BRepMesh_Deleted)
{
return Standard_False;
}
return (myUV.IsEqual(theOther.myUV, Precision::PConfusion()));
}
The functionality of IsEqual is completely inverted... Is it correct?
I'm currently busy with merging my code with the current BRepMesh master and found very strange modification of the code. Could you please verify if it's done correctly:
6.6.0 code base BRepMesh_Vertex.cxx: Line 65
Standard_Boolean BRepMesh_Vertex::IsEqual(const BRepMesh_Vertex& Other)const
{
if (myMovability!=BRepMesh_Deleted && Other.myMovability!=BRepMesh_Deleted)
return (myUV.IsEqual(Other.myUV, Precision::PConfusion()));
return Standard_False;
}
Current master BRepMesh_Vertex.hxx: Line 111
Standard_EXPORT Standard_Boolean IsEqual(const BRepMesh_Vertex& theOther) const
{
if (myMovability != BRepMesh_Deleted ||
theOther.myMovability != BRepMesh_Deleted)
{
return Standard_False;
}
return (myUV.IsEqual(theOther.myUV, Precision::PConfusion()));
}
The functionality of IsEqual is completely inverted... Is it correct?
Hello, Dima!
Your observation is valid. It is disappointing misprint and I will correct it in context of #0023106.
Fortunately there is no code block or data collection in BRepMesh using this method explicitly or implicitly, therefore it has not led to any regression.
Thank you for attentiveness.
Your observation is valid. It is disappointing misprint and I will correct it in context of #0023106.
Fortunately there is no code block or data collection in BRepMesh using this method explicitly or implicitly, therefore it has not led to any regression.
Thank you for attentiveness.
Branch [archived branch] has been created by Author.
[revision removed]
This branch includes the following new commits:
new 2d13f29 0025044: The merged version of BRepMesh tweaks
Detailed log of new commits:
[revision removed]
Author: razmyslovich
Date: Tue Aug 12 18:16:03 2014 +0200
0025044: The merged version of BRepMesh tweaks
[revision removed]
This branch includes the following new commits:
new 2d13f29 0025044: The merged version of BRepMesh tweaks
Detailed log of new commits:
[revision removed]
Author: razmyslovich
Date: Tue Aug 12 18:16:03 2014 +0200
0025044: The merged version of BRepMesh tweaks
Oleg, I've just committed the merged version of my tweaks. Please, review them. I'll attach tomorrow the relevant models/faces.
Due to the big size of the model, I just provide the link, where it can be free downloaded https://grabcad.com/library/colt-1911-a1-model-goverment-pistol
Oleg, I've uploaded 58 faces from my models database, which can't be meshed by the current master mesh code, but can be meshed after applying my modifications (including the faces from the models I uploaded earlier today)
I would like to point, that the file contains only the faces, which are effected by my modifications; I still have other 143 faces, which can't be meshed even with my modifications.
I hope this data helps you.
I would like to point, that the file contains only the faces, which are effected by my modifications; I still have other 143 faces, which can't be meshed even with my modifications.
I hope this data helps you.
Dear Dmitry, please check the bug state after integration of the fix for #0026106.
About half of problematic faces from attached archive are successfully meshed using current master (actually, next week integration branch).
Another half seems similar to #0025588, i.e. faces with open wires where gap is covered by tolerance. These ones should result in closed discrete contours of null area formed by two straight links causing error of meshing algorithm.
Model "2.stp" from the archive #0025588 is meshed without errors according to tricheck command.
Model "Attachment 2 (STEP)" contains several invalid faces according to checkshape report. However, all faces contain triangulation either correct or partially corrupted.
Meshing was performed implicitly by calling vdisplay command.
Another half seems similar to #0025588, i.e. faces with open wires where gap is covered by tolerance. These ones should result in closed discrete contours of null area formed by two straight links causing error of meshing algorithm.
Model "2.stp" from the archive #0025588 is meshed without errors according to tricheck command.
Model "Attachment 2 (STEP)" contains several invalid faces according to checkshape report. However, all faces contain triangulation either correct or partially corrupted.
Meshing was performed implicitly by calling vdisplay command.
Correction, all faces from the archive can be meshed using more fair angular tolerance producing several points along the border edges via
incmesh a 0.1 -a 5
incmesh a 0.1 -a 5
Branch [archived branch] has been created by Author.
[revision removed]
Detailed log of new commits:
Author: build
Date: Wed Aug 7 09:20:07 2019 +0200
0025044: Improve the meshing results for tiny faces - use smaller UV deflection threshold; recognize a small face with 1 wire and 2 small edges as a face for refinement; frontier edges with no connections should never be removed; improve frontierAdjust function to detect all possible intersections; fix the recognition of glued edges in GeomTool
[revision removed]
Detailed log of new commits:
Author: build
Date: Wed Aug 7 09:20:07 2019 +0200
0025044: Improve the meshing results for tiny faces - use smaller UV deflection threshold; recognize a small face with 1 wire and 2 small edges as a face for refinement; frontier edges with no connections should never be removed; improve frontierAdjust function to detect all possible intersections; fix the recognition of glued edges in GeomTool
Hello, Oleg,
I ported my changes for BRepMesh module to the current 7.4.0 master. Surely, most of the issues were fixed after your refactoring of the module. Still, the cases with tiny faces are not handled properly.
As an example model I used the bicycle from grabCAD https://grabcad.com/library/64119/details?folder_id=112727 I attach it also to the ticket. Before my changes 7 faces are left without mesh; with my changes 4 faces are left without mesh
Please, review the changes committed to the branch CR25044_2
Thank you very much
[signature removed]
Dima
I ported my changes for BRepMesh module to the current 7.4.0 master. Surely, most of the issues were fixed after your refactoring of the module. Still, the cases with tiny faces are not handled properly.
As an example model I used the bicycle from grabCAD https://grabcad.com/library/64119/details?folder_id=112727 I attach it also to the ticket. Before my changes 7 faces are left without mesh; with my changes 4 faces are left without mesh
Please, review the changes committed to the branch CR25044_2
Thank you very much
[signature removed]
Dima
Branch [archived branch] has been updated by Commenter 2.
[revision removed]
Detailed log of new commits:
Author: Commenter 2
Date: Wed Aug 7 13:13:23 2019 +0300
# Minor code corrections
[revision removed]
Detailed log of new commits:
Author: Commenter 2
Date: Wed Aug 7 13:13:23 2019 +0300
# Minor code corrections
build <razmyslovich_@_volumegraphics.com>
Are you sure your git settings are correct?
You've used "razmyslovich" instead of "build" in previous patches.
You are right, sorry - my computer was exchange recently...
I fixed it.
I fixed it.
Test reports are available at (unfortunately, only internally):
http://occt-tests/CR25044_2-master-OAN-OCCT/Windows-64-VC14/summary.html
http://occt-tests/CR25044_2-master-OAN-OCCT/Debian80-64/diff_summary.html
Test results are the following:
51 FAILED
32 IMPROVEMENT
Significant improvements:
bugs mesh bug25827
mesh standard O5
mesh standard U7
mesh standard V7
mesh standard W4
mesh standard V4
bugs mesh bug25307 (no free links)
bugs mesh bug25738 (no free nodes)
bugs moddata_2 bug22746_3
bugs modalg_2 bug21060
Regressions:
bugs mesh bug28500 (minor, changed status)
bugs vis bug22849 (minor, changed status)
mesh standard C7 (free links)
mesh standard P8 (free nodes)
mesh standard R2 (free nodes)
mesh standard U5 (free nodes)
mesh standard X2 (free nodes)
mesh standard W5 (face without triangulation)
bugs mesh bug25586_3 (face without triangulation)
bugs moddata_1 bug22761 (missed triangulation on some faces)
mesh standard B5 (incorrect triangulation near the hole)
bugs vis bug21578 (difference in visualization)
bugs mesh bug24594 (difference in visualization)
bugs mesh bug24593_1 (difference in visualization)
bugs mesh bug24593_2 (difference in visualization)
bugs modalg_2 bug20827 (difference in visualization)
bugs modalg_6 bug26701 (incorrect insertion of frontier links!)
bugs modalg_2 bug22830 (incorrect insertion of frontier links!)
bugs modalg_6 bug26130 (exception, division by zero?)
Unstable behaviour (without relation to changes):
de iges_3 A7
de step_2 C2
de step_2 F2
de step_2 U7
de step_4 C1
de step_4 H7
heal surface_to_revolution_advanced ZE8
offset shape_type_i_c XK4
offset shape_type_i_c XK7
offset shape_type_i_c XL8
offset shape_type_i_c ZL5
Other changes are just changed number of nodes and triangles in mesh.
http://occt-tests/CR25044_2-master-OAN-OCCT/Windows-64-VC14/summary.html
http://occt-tests/CR25044_2-master-OAN-OCCT/Debian80-64/diff_summary.html
Test results are the following:
51 FAILED
32 IMPROVEMENT
Significant improvements:
bugs mesh bug25827
mesh standard O5
mesh standard U7
mesh standard V7
mesh standard W4
mesh standard V4
bugs mesh bug25307 (no free links)
bugs mesh bug25738 (no free nodes)
bugs moddata_2 bug22746_3
bugs modalg_2 bug21060
Regressions:
bugs mesh bug28500 (minor, changed status)
bugs vis bug22849 (minor, changed status)
mesh standard C7 (free links)
mesh standard P8 (free nodes)
mesh standard R2 (free nodes)
mesh standard U5 (free nodes)
mesh standard X2 (free nodes)
mesh standard W5 (face without triangulation)
bugs mesh bug25586_3 (face without triangulation)
bugs moddata_1 bug22761 (missed triangulation on some faces)
mesh standard B5 (incorrect triangulation near the hole)
bugs vis bug21578 (difference in visualization)
bugs mesh bug24594 (difference in visualization)
bugs mesh bug24593_1 (difference in visualization)
bugs mesh bug24593_2 (difference in visualization)
bugs modalg_2 bug20827 (difference in visualization)
bugs modalg_6 bug26701 (incorrect insertion of frontier links!)
bugs modalg_2 bug22830 (incorrect insertion of frontier links!)
bugs modalg_6 bug26130 (exception, division by zero?)
Unstable behaviour (without relation to changes):
de iges_3 A7
de step_2 C2
de step_2 F2
de step_2 U7
de step_4 C1
de step_4 H7
heal surface_to_revolution_advanced ZE8
offset shape_type_i_c XK4
offset shape_type_i_c XK7
offset shape_type_i_c XL8
offset shape_type_i_c ZL5
Other changes are just changed number of nodes and triangles in mesh.
Dear Dima,
Unfortunately, patch in its current state leads to some regressions, so it cannot be integrated as is.
I suppose that these regressions could be the result of changes in BRepMesh_Delaun class.
For instance:
bugs modalg_6 bug26701
bugs modalg_2 bug22830
Could you please give some hints about new functionality in this particular tool.
Will the fix for tiny faces work without these changes?
Probably, results would be different if we try to exclude modifications of BRepMesh_Delaun and check functionality that handles tiny faces in BRepMesh_ModelHealer only.
What do you think about it?
P.S.: I am not sure that shapes from the report above can be shared to resolve remaining problems, but I can figure it out.
[signature removed]
Oleg.
Unfortunately, patch in its current state leads to some regressions, so it cannot be integrated as is.
I suppose that these regressions could be the result of changes in BRepMesh_Delaun class.
For instance:
bugs modalg_6 bug26701
bugs modalg_2 bug22830
Could you please give some hints about new functionality in this particular tool.
Will the fix for tiny faces work without these changes?
Probably, results would be different if we try to exclude modifications of BRepMesh_Delaun and check functionality that handles tiny faces in BRepMesh_ModelHealer only.
What do you think about it?
P.S.: I am not sure that shapes from the report above can be shared to resolve remaining problems, but I can figure it out.
[signature removed]
Oleg.
Branch [archived branch] has been updated by Author.
[revision removed]
Detailed log of new commits:
Author: Author
Date: Thu Aug 15 12:58:15 2019 +0200
Merge branch 'CR25044_2' of git.dev.opencascade.org:occt into CR25044_2
Author: Author
Date: Thu Aug 15 12:53:11 2019 +0200
0025044: Revert the unrelated changes
[revision removed]
Detailed log of new commits:
Author: Author
Date: Thu Aug 15 12:58:15 2019 +0200
Merge branch 'CR25044_2' of git.dev.opencascade.org:occt into CR25044_2
Author: Author
Date: Thu Aug 15 12:53:11 2019 +0200
0025044: Revert the unrelated changes
Dear Oleg,
I have tried to exclude the changes in BRepMesh_Delaun and run tests on my side with out models database. And I would agree, that these part of the changes can be excluded.
The changes in BRepMesh_Delaun are related to more sophisticated checks of face boundaries, particularly I have added a check for triangles, which intersect the boundary edges (frontier). These changes still improve the mesh results in some cases, but also introduce some regressions, therefore let's exclude them for now and as soon as I found some critical faces, which need this logic, I will propose the refined changes for BRepMesh_Delaun in a separate ticket.
Still, the changes for tiny faces are located not only in BRepMesh_ModelHealer but also in BRepMesh_DefaultRangeSplitter. As tiny faces can have UV sizes smaller as default deflection UV, it's necessary to consider UV sizes for tolerance values.
I reverted all other changes in CR25044_2 branch. Could you please try again to run your tests?
Thank you.
[signature removed]
Dima
I have tried to exclude the changes in BRepMesh_Delaun and run tests on my side with out models database. And I would agree, that these part of the changes can be excluded.
The changes in BRepMesh_Delaun are related to more sophisticated checks of face boundaries, particularly I have added a check for triangles, which intersect the boundary edges (frontier). These changes still improve the mesh results in some cases, but also introduce some regressions, therefore let's exclude them for now and as soon as I found some critical faces, which need this logic, I will propose the refined changes for BRepMesh_Delaun in a separate ticket.
Still, the changes for tiny faces are located not only in BRepMesh_ModelHealer but also in BRepMesh_DefaultRangeSplitter. As tiny faces can have UV sizes smaller as default deflection UV, it's necessary to consider UV sizes for tolerance values.
I reverted all other changes in CR25044_2 branch. Could you please try again to run your tests?
Thank you.
[signature removed]
Dima
Branch [archived branch] has been created by Commenter 2.
[revision removed]
Detailed log of new commits:
Author: Author
Date: Thu Aug 15 18:13:43 2019 +0300
0025044: Revert the unrelated changes
Author: build
Date: Wed Aug 7 09:20:07 2019 +0200
0025044: Improve the meshing results for tiny faces - use smaller UV deflection threshold; recognize a small face with 1 wire and 2 small edges as a face for refinement; frontier edges with no connections should never be removed; improve frontierAdjust function to detect all possible intersections; fix the recognition of glued edges in GeomTool
[revision removed]
Detailed log of new commits:
Author: Author
Date: Thu Aug 15 18:13:43 2019 +0300
0025044: Revert the unrelated changes
Author: build
Date: Wed Aug 7 09:20:07 2019 +0200
0025044: Improve the meshing results for tiny faces - use smaller UV deflection threshold; recognize a small face with 1 wire and 2 small edges as a face for refinement; frontier edges with no connections should never be removed; improve frontierAdjust function to detect all possible intersections; fix the recognition of glued edges in GeomTool
DC,
Here are the testing results for the updated patch:
http://occt-tests/CR25044_master-master-OAN-OCCT/Windows-64-VC14/diff_summary.html
http://occt-tests/CR25044_master-master-OAN-OCCT/Debian80-64/diff_summary.html
Generally, they are OK, except "mesh standard P8" where a single free node has appeared.
I suppose, the difference in behaviour is caused by amplification of an edge containing plain loop in 2D that can be considered as self-intersecting in context of applied patch (however, no status is returned for this particular use case). There is an additional discretization point on the loop causing "free node" status.
So, personally I do not consider it as a regression, but the result of edge discretization algorithm with specific parameters.
Please make decision about patch integration or possibility of sharing the reference shape from "mesh standard P8" test publicly.
Improvements (absence of cross-face errors and faces without triangulation):
bugs mesh bug25827
mesh advanced B2
mesh advanced B3
mesh advanced B7
mesh advanced_shading A7
mesh standard H5
mesh standard O5
Changed statuses (additional self-intersecting status):
bugs mesh bug28500
bugs vis bug22849
Changed number of triangles:
bugs iges buc60823
bugs iges bug306
bugs mesh bug23513
bugs mesh bug29149
bugs mesh bug29962
bugs moddata_1 bug15519
bugs moddata_1 bug22759
bugs moddata_2 bug258_1
bugs moddata_2 bug428
Here are the testing results for the updated patch:
http://occt-tests/CR25044_master-master-OAN-OCCT/Windows-64-VC14/diff_summary.html
http://occt-tests/CR25044_master-master-OAN-OCCT/Debian80-64/diff_summary.html
Generally, they are OK, except "mesh standard P8" where a single free node has appeared.
I suppose, the difference in behaviour is caused by amplification of an edge containing plain loop in 2D that can be considered as self-intersecting in context of applied patch (however, no status is returned for this particular use case). There is an additional discretization point on the loop causing "free node" status.
So, personally I do not consider it as a regression, but the result of edge discretization algorithm with specific parameters.
Please make decision about patch integration or possibility of sharing the reference shape from "mesh standard P8" test publicly.
Improvements (absence of cross-face errors and faces without triangulation):
bugs mesh bug25827
mesh advanced B2
mesh advanced B3
mesh advanced B7
mesh advanced_shading A7
mesh standard H5
mesh standard O5
Changed statuses (additional self-intersecting status):
bugs mesh bug28500
bugs vis bug22849
Changed number of triangles:
bugs iges buc60823
bugs iges bug306
bugs mesh bug23513
bugs mesh bug29149
bugs mesh bug29962
bugs moddata_1 bug15519
bugs moddata_1 bug22759
bugs moddata_2 bug258_1
bugs moddata_2 bug428
Branch [archived branch] has been created by Participant.
[revision removed]
Detailed log of new commits:
Author: Author
Date: Wed Aug 7 10:20:07 2019 +0300
0025044: BRepMesh tweaks - degenerated faces
BRepMesh+ModelHealer - recognize a small face with 1 wire and 2 small edges as a face for refinement
[revision removed]
Detailed log of new commits:
Author: Author
Date: Wed Aug 7 10:20:07 2019 +0300
0025044: BRepMesh tweaks - degenerated faces
BRepMesh+ModelHealer - recognize a small face with 1 wire and 2 small edges as a face for refinement
Branch [archived branch] has been updated forcibly by Participant.
[revision removed]
[revision removed]
Oleg, we need to add faces provided by Dmitry to the test database, and add relevant tests, this shall allow us to verify the change and see improvements and not only regressions.
I observe that the final version of the branch effectively contains two changes only:
- detection of degenerated faces in BRepMesh_ModelHealer.cxx
- decrease of working tolerance in BRepMesh_DefaultRangeSplitter.cxx
I have created separate branch CR25044_test1 for the first one, to test it separately.
The results of tests are:
Changed statuses (additional self-intersecting status):
bugs mesh bug28500
bugs vis bug22849
Improvements:
mesh advanced_shading A7
mesh standard_incmesh O5
mesh standard_incmesh_parallel O5
mesh standard_shading O5
Visual differences look like improvements (eliminated meshing artifacts) on several cases:
advanced_shading A7
bugs xde bug23969
bugs iges bug22487_1
bugs step bug30628
However, on one test it looks like regression (small gap in the object)
bugs modalg_4 bug697_4
Thus this change overall looks like improvement, however to complete it we need to update tests accordingly, and check more carefully the bug697_4 to verify that it is not regression.
I observe that the final version of the branch effectively contains two changes only:
- detection of degenerated faces in BRepMesh_ModelHealer.cxx
- decrease of working tolerance in BRepMesh_DefaultRangeSplitter.cxx
I have created separate branch CR25044_test1 for the first one, to test it separately.
The results of tests are:
Changed statuses (additional self-intersecting status):
bugs mesh bug28500
bugs vis bug22849
Improvements:
mesh advanced_shading A7
mesh standard_incmesh O5
mesh standard_incmesh_parallel O5
mesh standard_shading O5
Visual differences look like improvements (eliminated meshing artifacts) on several cases:
advanced_shading A7
bugs xde bug23969
bugs iges bug22487_1
bugs step bug30628
However, on one test it looks like regression (small gap in the object)
bugs modalg_4 bug697_4
Thus this change overall looks like improvement, however to complete it we need to update tests accordingly, and check more carefully the bug697_4 to verify that it is not regression.
Branch [archived branch] has been created by Participant.
[revision removed]
Detailed log of new commits:
Author: abv
Date: Sun Aug 18 09:46:38 2019 +0300
0025044: BRepMesh tweaks - Improve the meshing results for tiny faces
Use smaller UV deflection threshold
[revision removed]
Detailed log of new commits:
Author: abv
Date: Sun Aug 18 09:46:38 2019 +0300
0025044: BRepMesh tweaks - Improve the meshing results for tiny faces
Use smaller UV deflection threshold
Branch [archived branch] has been updated forcibly by Participant.
[revision removed]
[revision removed]
Branch [archived branch] has been updated forcibly by Participant.
[revision removed]
[revision removed]
Branch CR25044_test2 is made for testing change in DefaultSplitter.
That change causes regression on test mesh standard_incmesh P8, due to tolerance decreasing from 1e-5 to 1e-6 on line .
First I tried it in variant without changing 1e-5 to 1e-6. The result is: no regressions reported, visual improvements (no green wireframe artifacts) on two tests:
bugs iges bug22394
bugs step bug5708
That change causes regression on test mesh standard_incmesh P8, due to tolerance decreasing from 1e-5 to 1e-6 on line .
First I tried it in variant without changing 1e-5 to 1e-6. The result is: no regressions reported, visual improvements (no green wireframe artifacts) on two tests:
bugs iges bug22394
bugs step bug5708
Branch [archived branch] has been updated forcibly by Participant.
[revision removed]
[revision removed]
Branch [archived branch] has been created by Commenter 2.
[revision removed]
Detailed log of new commits:
Author: Commenter 2
Date: Tue Sep 3 19:19:57 2019 +0300
#Test sceneries for particular faces
[revision removed]
Detailed log of new commits:
Author: Commenter 2
Date: Tue Sep 3 19:19:57 2019 +0300
#Test sceneries for particular faces
Branch [archived branch] has been updated by Commenter 2.
[revision removed]
Detailed log of new commits:
Author: Commenter 2
Date: Thu Sep 5 18:53:50 2019 +0300
#Added STEP scripts
[revision removed]
Detailed log of new commits:
Author: Commenter 2
Date: Thu Sep 5 18:53:50 2019 +0300
#Added STEP scripts
Test scripts have been added according to attached shapes.
Branch [archived branch] has been created by Participant.
[revision removed]
Detailed log of new commits:
Author: Commenter 2
Date: Tue Sep 3 19:19:57 2019 +0300
0025044: BRepMesh tweaks - treatments for degenerated and tiny faces
BRepMesh_ModelHealer - recognize a small face with 1 wire and 2 small edges as a face for refinement.
BRepMesh_DefaultRangeSplinner - reduce tolerance on tiny faces to improve the meshing results.
Added new test cases: bugs mesh bug25044_*.
Existing test cases updated to reflect improvements.
[revision removed]
Detailed log of new commits:
Author: Commenter 2
Date: Tue Sep 3 19:19:57 2019 +0300
0025044: BRepMesh tweaks - treatments for degenerated and tiny faces
BRepMesh_ModelHealer - recognize a small face with 1 wire and 2 small edges as a face for refinement.
BRepMesh_DefaultRangeSplinner - reduce tolerance on tiny faces to improve the meshing results.
Added new test cases: bugs mesh bug25044_*.
Existing test cases updated to reflect improvements.
Branch [archived branch] has been updated forcibly by Participant.
[revision removed]
[revision removed]
Branch CR25044_3 is tested and shows several improvements (as described above), see Jenkins job CR25044_2-master-OAN. Please integrate.
Combination -
OCCT branch : [archived branch]
master SHA - [revision removed]
[revision removed]
Products branch : [archived branch] SHA - [revision removed]
was compiled on Linux, MacOS and Windows platforms and tested in optimize mode.
Number of compiler warnings:
No new/fixed warnings
Regressions/Differences/Improvements:
No regressions/differences
CPU differences:
Debian80-64:
OCCT
Total CPU difference: 16809.910000000036 / 16808.79000000008 [+0.01%]
Products
Total CPU difference: 10578.870000000032 / 10568.68000000004 [+0.10%]
Windows-64-VC14:
OCCT
Total CPU difference: 18203.84375 / 18242.09375 [-0.21%]
Products
Total CPU difference: 12482.96875 / 12507.671875 [-0.20%]
Image differences :
No differences that require special attention
Memory differences :
No differences that require special attention
OCCT branch : [archived branch]
master SHA - [revision removed]
[revision removed]
Products branch : [archived branch] SHA - [revision removed]
was compiled on Linux, MacOS and Windows platforms and tested in optimize mode.
Number of compiler warnings:
No new/fixed warnings
Regressions/Differences/Improvements:
No regressions/differences
CPU differences:
Debian80-64:
OCCT
Total CPU difference: 16809.910000000036 / 16808.79000000008 [+0.01%]
Products
Total CPU difference: 10578.870000000032 / 10568.68000000004 [+0.10%]
Windows-64-VC14:
OCCT
Total CPU difference: 18203.84375 / 18242.09375 [-0.21%]
Products
Total CPU difference: 12482.96875 / 12507.671875 [-0.20%]
Image differences :
No differences that require special attention
Memory differences :
No differences that require special attention
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]
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]
Branch [archived branch] has been deleted by Participant.
[revision removed]
[revision removed]
Branch [archived branch] has been deleted by Participant.
[revision removed]
[revision removed]
Related records
- #0024923 · related to · closedBRepMesh_CircleTool produces bad circles
- #0025061 · related to · newBRepMesh should skip internal wires with self intersections to produce mesh for the shape anyway
- #0025113 · parent of · closedMesh - Progress indication and user break functionality for BRepMesh component