MantisBT - Community
View Issue Details
0025044Community[OCCT] OCCT:Meshpublic2014-07-01 14:232018-11-17 23:12
WindowsVC++ 201064 bit
[OCCT] 6.6.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%).
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 0025113resolved msv Community Progress indication and user break functionality for BRepMesh component 
Not all the children of this issue are yet resolved or closed.
? Checking Fixture Clamping.STEP (1,552,563) 2014-08-13 13:00
zip (774,124) 2014-08-13 19:43
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

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