MantisBT - Community
View Issue Details
0025044Community[OCCT] OCCT:Meshpublic2014-07-01 14:232019-09-29 12:36
WindowsVC++ 201064 bit
[OCCT] 6.6.0 
[OCCT] 7.4.0[OCCT] 7.4.0 
0025044: BRepMesh tweaks
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%).
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
Changes from 0024923 are also include in this commit.
No tags attached.
related to 0024923closed bugmaster Community BRepMesh_CircleTool produces bad circles 
related to 0025061new oan Open CASCADE BRepMesh should skip internal wires with self intersections to produce mesh for the shape anyway 
parent of 0025113closed bugmaster Community Mesh - Progress indication and user break functionality for BRepMesh component 
? Checking Fixture Clamping.STEP (1,552,563) 2014-08-13 13:00
zip (774,124) 2014-08-13 19:43
zip Median cx-fs01 bicycle ( kerékpár ).zip (4,443,025) 2019-08-07 10:31
Issue History
2014-07-01 14:23drazmyslovichNew Issue
2014-07-01 14:23drazmyslovichAssigned To => oan
2014-07-01 14:26drazmyslovichNote Added: 0029934
2014-07-01 14:26drazmyslovichStatusnew => resolved
2014-07-01 14:27drazmyslovichRelationship addedrelated to 0024923
2014-07-01 14:27drazmyslovichAdditional Information Updatedbug_revision_view_page.php?rev_id=7674#r7674
2014-07-30 18:22oanNote Added: 0030496
2014-07-30 18:22oanAssigned Tooan => drazmyslovich
2014-07-30 18:22oanStatusresolved => feedback
2014-07-30 18:33oanRelationship addedparent of 0025113
2014-08-04 15:58drazmyslovichNote Added: 0030559
2014-08-04 15:58drazmyslovichAssigned Todrazmyslovich => oan
2014-08-05 19:29abvTarget Version => 6.8.0
2014-08-08 19:39oanNote Added: 0030642
2014-08-08 19:39oanAssigned Tooan => drazmyslovich
2014-08-09 01:36oanNote Edited: 0030642bug_revision_view_page.php?bugnote_id=30642#r7838
2014-08-11 16:05drazmyslovichNote Added: 0030657
2014-08-12 15:11drazmyslovichNote Added: 0030682
2014-08-12 15:11drazmyslovichNote Edited: 0030682bug_revision_view_page.php?bugnote_id=30682#r7849
2014-08-12 15:15drazmyslovichAssigned Todrazmyslovich => oan
2014-08-12 15:49oanNote Added: 0030684
2014-08-12 15:49oanAssigned Tooan => drazmyslovich
2014-08-12 20:16gitNote Added: 0030691
2014-08-12 20:24drazmyslovichNote Added: 0030694
2014-08-12 20:24drazmyslovichAssigned Todrazmyslovich => oan
2014-08-12 20:24drazmyslovichStatusfeedback => resolved
2014-08-13 13:00drazmyslovichFile Added: Checking Fixture Clamping.STEP
2014-08-13 13:00drazmyslovichNote Added: 0030712
2014-08-13 19:43drazmyslovichFile Added:
2014-08-13 19:48drazmyslovichNote Added: 0030729
2014-10-16 13:26oanTarget Version6.8.0 => 7.1.0
2016-10-25 17:39oanTarget Version7.1.0 => 7.2.0
2017-07-20 12:43oanTarget Version7.2.0 => 7.3.0
2018-02-25 21:09abvTarget Version7.3.0 => 7.4.0
2018-11-02 17:49msvNote Added: 0080651
2018-11-02 17:49msvAssigned Tooan => drazmyslovich
2018-11-02 17:49msvStatusresolved => feedback
2018-11-16 22:31oanRelationship addedrelated to 0025061
2018-11-16 22:53oanNote Added: 0081132
2018-11-17 23:05oanNote Added: 0081136
2018-11-17 23:12oanNote Edited: 0081132bug_revision_view_page.php?bugnote_id=81132#r20391
2019-08-07 10:22gitNote Added: 0086046
2019-08-07 10:30drazmyslovichNote Added: 0086047
2019-08-07 10:30drazmyslovichAssigned Todrazmyslovich => oan
2019-08-07 10:30drazmyslovichStatusfeedback => resolved
2019-08-07 10:30drazmyslovichSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=21585#r21585
2019-08-07 10:31drazmyslovichFile Added: Median cx-fs01 bicycle ( kerékpár ).zip
2019-08-07 10:32drazmyslovichNote Edited: 0086047bug_revision_view_page.php?bugnote_id=86047#r21587
2019-08-07 13:15gitNote Added: 0086055
2019-08-07 13:42kgvNote Added: 0086057
2019-08-07 13:42kgvNote Edited: 0086057bug_revision_view_page.php?bugnote_id=86057#r21597
2019-08-07 14:08drazmyslovichNote Added: 0086060
2019-08-07 14:08drazmyslovichNote Edited: 0086060bug_revision_view_page.php?bugnote_id=86060#r21601
2019-08-08 11:14oanNote Added: 0086084
2019-08-08 11:27oanNote Added: 0086085
2019-08-08 11:27oanAssigned Tooan => drazmyslovich
2019-08-08 11:27oanStatusresolved => assigned
2019-08-15 14:00gitNote Added: 0086260
2019-08-15 14:01drazmyslovichNote Added: 0086261
2019-08-15 14:02drazmyslovichAssigned Todrazmyslovich => oan
2019-08-15 14:02drazmyslovichStatusassigned => resolved
2019-08-15 18:18gitNote Added: 0086268
2019-08-16 11:51oanNote Added: 0086271
2019-08-16 11:51oanAssigned Tooan => abv
2019-08-17 21:43gitNote Added: 0086315
2019-08-17 22:26gitNote Added: 0086316
2019-08-18 09:28abvNote Added: 0086317
2019-08-18 09:49gitNote Added: 0086318
2019-08-18 10:02gitNote Added: 0086319
2019-08-18 14:16gitNote Added: 0086320
2019-08-18 14:16abvNote Added: 0086321
2019-08-18 14:27gitNote Added: 0086322
2019-08-22 16:04abvAssigned Toabv => oan
2019-08-22 16:04abvStatusresolved => assigned
2019-09-03 19:26gitNote Added: 0086707
2019-09-05 18:56gitNote Added: 0086814
2019-09-05 18:57oanNote Added: 0086815
2019-09-05 18:57oanAssigned Tooan => abv
2019-09-05 18:57oanStatusassigned => feedback
2019-09-24 21:59gitNote Added: 0087496
2019-09-25 07:37gitNote Added: 0087499
2019-09-25 13:21abvNote Added: 0087509
2019-09-25 13:21abvAssigned Toabv => bugmaster
2019-09-25 13:21abvStatusfeedback => reviewed
2019-09-25 17:42bugmasterTest case number => bugs/mesh
2019-09-25 17:44bugmasterNote Added: 0087517
2019-09-25 17:44bugmasterStatusreviewed => tested
2019-09-29 12:19bugmasterChangeset attached => occt master 8c186dad
2019-09-29 12:19bugmasterStatustested => verified
2019-09-29 12:19bugmasterResolutionopen => fixed
2019-09-29 12:35gitNote Added: 0087599
2019-09-29 12:35gitNote Added: 0087600
2019-09-29 12:35gitNote Added: 0087601
2019-09-29 12:35gitNote Added: 0087602
2019-09-29 12:36gitNote Added: 0087603
2019-09-29 12:36gitNote Added: 0087604
2019-09-29 12:36gitNote Added: 0087605
2019-09-29 12:36gitNote Added: 0087606

2014-07-01 14:26   
The tweaks are committed, please, review them
2014-07-30 18:22   

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 best regards,
2014-08-04 15:58   
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?

2014-08-08 19:39   
(edited on: 2014-08-09 01:36)
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 b9d558fc5725ee3ac272e8cb3ec90fb83a4d9e6e), 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
Best regards,

2014-08-11 16:05   
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.

2014-08-12 15:11   
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?

2014-08-12 15:49   
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.
2014-08-12 20:16   
Branch CR25044_1 has been created by drazmyslovich.

SHA-1: 2d13f2972dfe99d1a8ce9daac438b10b88a90c09

This branch includes the following new commits:

       new 2d13f29 0025044: The merged version of BRepMesh tweaks

Detailed log of new commits:

commit 2d13f2972dfe99d1a8ce9daac438b10b88a90c09
Author: razmyslovich
Date: Tue Aug 12 18:16:03 2014 +0200

    0025044: The merged version of BRepMesh tweaks
2014-08-12 20:24   
Oleg, I've just committed the merged version of my tweaks. Please, review them. I'll attach tomorrow the relevant models/faces.
2014-08-13 13:00   
Due to the big size of the model, I just provide the link, where it can be free downloaded [^]
2014-08-13 19:48   
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.
2018-11-02 17:49   
Dear Dmitry, please check the bug state after integration of the fix for 0026106.
2018-11-16 22:53   
(edited on: 2018-11-17 23:12)
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 "Checking Fixture Clamping.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.

2018-11-17 23:05   
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
2019-08-07 10:22   
Branch CR25044_2 has been created by drazmyslovich.

SHA-1: ebfd9b54b6c0b08e23b6139d54ee7ecd09735383

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
2019-08-07 10:30   
(edited on: 2019-08-07 10:32)
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 [^] 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


2019-08-07 13:15   
Branch CR25044_2 has been updated by oan.

SHA-1: db734ec401ab49847094441bdb5ebc180dc36d9f

Detailed log of new commits:

Author: oan
Date: Wed Aug 7 13:13:23 2019 +0300

    # Minor code corrections

2019-08-07 13:42   
build <>

Are you sure your git settings are correct?
You've used "razmyslovich" instead of "build" in previous patches.

2019-08-07 14:08   
You are right, sorry - my computer was exchange recently...
I fixed it.

2019-08-08 11:14   
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:

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

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.
2019-08-08 11:27   
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.

Best regards,
2019-08-15 14:00   
Branch CR25044_2 has been updated by drazmyslovich.

SHA-1: 835c9803fcfd9f961b673912e2c977142c162f78

Detailed log of new commits:

Author: drazmyslovich
Date: Thu Aug 15 12:58:15 2019 +0200

    Merge branch 'CR25044_2' of into CR25044_2

Author: drazmyslovich
Date: Thu Aug 15 12:53:11 2019 +0200

    0025044: Revert the unrelated changes

2019-08-15 14:01   
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.

2019-08-15 18:18   
Branch CR25044_master has been created by oan.

SHA-1: 578436a8d8cb44482eb32dc125ccfbf1e81135c7

Detailed log of new commits:

Author: drazmyslovich
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
2019-08-16 11:51   

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
2019-08-17 21:43   
Branch CR25044_test1 has been created by abv.

SHA-1: 3ad1d7884e6f4757178471c5fd4de039abcb7038

Detailed log of new commits:

Author: drazmyslovich
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
2019-08-17 22:26   
Branch CR25044_test1 has been updated forcibly by abv.

SHA-1: 9736cc087bfd672ea54aa716ef58f1ca1230b563
2019-08-18 09:28   
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

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.
2019-08-18 09:49   
Branch CR25044_test2 has been created by abv.

SHA-1: 0b8afacfd67203c8793800ecf4c8f5590ed4e799

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
2019-08-18 10:02   
Branch CR25044_test2 has been updated forcibly by abv.

SHA-1: 3c0f0e0a3379b2aa1389794812c8e64033168f4d
2019-08-18 14:16   
Branch CR25044_test2 has been updated forcibly by abv.

SHA-1: 1fbd74da4015b24a7a349ab45a45d27624e71fa7
2019-08-18 14:16   
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
2019-08-18 14:27   
Branch CR25044_test2 has been updated forcibly by abv.

SHA-1: 14f8de043523bc58fb055edd28553c7e796c4c58
2019-09-03 19:26   
Branch CR25044_testscripts has been created by oan.

SHA-1: 91f6e434471e449e0f33437067c82b915c0a5a24

Detailed log of new commits:

Author: oan
Date: Tue Sep 3 19:19:57 2019 +0300

    #Test sceneries for particular faces
2019-09-05 18:56   
Branch CR25044_testscripts has been updated by oan.

SHA-1: 0a1c8db81145a280592a5f6786fc9c5a5ab93c89

Detailed log of new commits:

Author: oan
Date: Thu Sep 5 18:53:50 2019 +0300

    #Added STEP scripts

2019-09-05 18:57   
Test scripts have been added according to attached shapes.
2019-09-24 21:59   
Branch CR25044_3 has been created by abv.

SHA-1: 49b0e098c2b9713a7131d4628490fc14710079fe

Detailed log of new commits:

Author: oan
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.
2019-09-25 07:37   
Branch CR25044_3 has been updated forcibly by abv.

SHA-1: 4f53f6368d5f50d3035f370353cbc40aa19d82da
2019-09-25 13:21   
Branch CR25044_3 is tested and shows several improvements (as described above), see Jenkins job CR25044_2-master-OAN. Please integrate.
2019-09-25 17:44   
Combination -
OCCT branch : CR25044_3
master SHA - 4f53f6368d5f50d3035f370353cbc40aa19d82da
Products branch : master SHA - cede13b0d79b1c3448ecd68f0db85c2a087762ad
was compiled on Linux, MacOS and Windows platforms and tested in optimize mode.

Number of compiler warnings:
No new/fixed warnings

No regressions/differences

CPU differences:
Total CPU difference: 16809.910000000036 / 16808.79000000008 [+0.01%]
Total CPU difference: 10578.870000000032 / 10568.68000000004 [+0.10%]
Total CPU difference: 18203.84375 / 18242.09375 [-0.21%]
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
2019-09-29 12:35   
Branch CR25044 has been deleted by inv.

SHA-1: 26e5d99e54e6eddfc059c43b30cddbd83cd0cdc3
2019-09-29 12:35   
Branch CR25044_1 has been deleted by inv.

SHA-1: 2d13f2972dfe99d1a8ce9daac438b10b88a90c09
2019-09-29 12:35   
Branch CR25044_2 has been deleted by inv.

SHA-1: 835c9803fcfd9f961b673912e2c977142c162f78
2019-09-29 12:35   
Branch CR25044_3 has been deleted by inv.

SHA-1: 4f53f6368d5f50d3035f370353cbc40aa19d82da
2019-09-29 12:36   
Branch CR25044_master has been deleted by inv.

SHA-1: 578436a8d8cb44482eb32dc125ccfbf1e81135c7
2019-09-29 12:36   
Branch CR25044_test1 has been deleted by inv.

SHA-1: 9736cc087bfd672ea54aa716ef58f1ca1230b563
2019-09-29 12:36   
Branch CR25044_test2 has been deleted by inv.

SHA-1: 14f8de043523bc58fb055edd28553c7e796c4c58
2019-09-29 12:36   
Branch CR25044_testscripts has been deleted by inv.

SHA-1: 0a1c8db81145a280592a5f6786fc9c5a5ab93c89