MantisBT - Community
View Issue Details
0025287Community[OCCT] OCCT:Meshpublic2014-09-29 17:172020-03-20 10:12
nikiml 
bugmaster 
normalmajor 
verifiedfixed 
WindowsVC++ 200564 bit
 
[OCCT] 7.5.0* 
bugs/mesh/bug25287
0025287: BRepMesh_IncrementalMesh produces (way) out of tolerance mesh
Observed distance between the surface of the face and the mesh of the face
is sometimes 3x bigger than the requested tolerance of .0001.

I suspect there are other faces on the body that do not tessellate properly,
but I specifically measured the highlighted and pictured in the attached files one.
The problem face is named "TESSELLATION_PROBLEM" in the step file and colored
in magenta (#9419 = COLOUR_RGB ( '',0.9372549019607843100, 0.0, 0.9372549019607843100 ))
 
Unfortunately the problem does not present itself when tessellating the face by itself.
It only does when the whole body is tessellated. See the attached images.
STEPControl_Reader reader;

Standard_CString s = Interface_Static::CVal("xstep.cascade.unit");
if(s != "M")
    Interface_Static::SetCVal("xstep.cascade.unit", "M");

IFSelect_ReturnStatus stat = reader.ReadFile(attached_test_file);
if(IFSelect_RetDone!=stat)return;

reader.PrintCheckLoad(Standard_False,IFSelect_ItemsByEntity);

Standard_Integer nbr = reader.NbRootsForTransfer();
for ( Standard_Integer n = 1; n<=nbr; n++)
    Standard_Boolean ok = reader.TransferRoot(n);

Standard_Integer nbs = reader.NbShapes();
if (!nbs) return;

for (Standard_Integer i=1; i<=nbs; i++) {
    TopExp_Explorer ex;
    for (ex.Init(reader.Shape(i),TopAbs_SOLID);ex.More(); ex.Next())
        BRepMesh_IncrementalMesh(ex.Current(),0.0001, Standard_False, 0.52359877559829882);
}
No tags attached.
related to 0031251verified bugmaster Community Mesh - Add a parameter for IncrementalMesh to ignore face tolerance for face deflection 
related to 0031449new oan Open CASCADE Mesh - BRepMesh works too long and produces many free nodes on a valid face 
7z bad_tessellation.7z (1,026,420) 2014-09-29 17:17
https://tracker.dev.opencascade.org/
? face_only.step (11,777) 2014-11-26 19:54
https://tracker.dev.opencascade.org/
Issue History
2014-09-29 17:17nikimlNew Issue
2014-09-29 17:17nikimlAssigned To => oan
2014-09-29 17:17nikimlFile Added: bad_tessellation.7z
2014-09-29 18:11nikimlNote Added: 0032327
2014-11-24 18:13oanNote Added: 0034650
2014-11-24 18:13oanAssigned Tooan => nikiml
2014-11-24 18:13oanStatusnew => feedback
2014-11-26 19:54nikimlFile Added: face_only.step
2014-11-26 20:01nikimlNote Added: 0034721
2014-11-27 00:37nikimlAssigned Tonikiml => oan
2014-11-27 11:19oanAssigned Tooan => nikiml
2014-11-27 11:19oanNote Added: 0034727
2014-12-24 16:51nikimlNote Added: 0035689
2014-12-26 05:16nikimlAssigned Tonikiml => oan
2017-08-14 16:39abvTarget Version => 7.4.0
2019-09-06 18:34oanTarget Version7.4.0 => 7.5.0*
2019-12-20 20:07oanRelationship addedrelated to 0031251
2019-12-31 01:04gitNote Added: 0089830
2019-12-31 01:06oanAssigned Tooan => msv
2019-12-31 01:06oanStatusfeedback => resolved
2019-12-31 01:11oanNote Added: 0089831
2020-01-09 09:43msvNote Added: 0089840
2020-01-09 09:43msvAssigned Tomsv => oan
2020-01-09 09:43msvStatusresolved => assigned
2020-01-09 09:44msvNote Added: 0089841
2020-01-13 11:52gitNote Added: 0089864
2020-01-13 14:09oanNote Added: 0089870
2020-01-13 14:09oanAssigned Tooan => msv
2020-01-13 14:09oanStatusassigned => resolved
2020-01-13 14:09oanNote Edited: 0089870bug_revision_view_page.php?bugnote_id=89870#r22434
2020-01-13 14:33msvNote Added: 0089872
2020-01-13 14:33msvAssigned Tomsv => bugmaster
2020-01-13 14:33msvStatusresolved => reviewed
2020-01-13 16:12bugmasterTest case number => bugs/mesh/bug25287
2020-01-13 16:17bugmasterStatusreviewed => tested
2020-01-18 12:27bugmasterChangeset attached => occt master 0c061f3d
2020-01-18 12:27bugmasterStatustested => verified
2020-01-18 12:27bugmasterResolutionopen => fixed
2020-01-18 15:36gitNote Added: 0089946
2020-03-20 10:12oanRelationship addedrelated to 0031449

Notes
(0032327)
nikiml   
2014-09-29 18:11   
Actually VC++ 2008 is the compiler I used
(0034650)
oan   
2014-11-24 18:13   
Dear nikiml,

you expect BRepMesh to generate mesh using deflection 0.0001 while the shape itself (in particular face 182) has tolerance 0.00041686426330493794. So it is impossible to achieve smaller deflection than allowed by the lower threshold equal to double tolerance of shape (please refer to http://dev.opencascade.org/doc/overview/html/occt_user_guides__modeling_algos.html#occt_modalg_10_2 [^]).

Use the following commands to check it:
pload ALL
param xstep.cascade.unit M
stepread bad_tess_face_plus.step a *
explode a_1 f
donly a_1_182
small
fit

tolerance a_1_182
# Tolerance MAX=0.00041686426330493794

incmesh a_1_182 0.0001
trinfo a_1_182
# This shape contains 30 triangles.
# 26 nodes.
# Maximal deflection 0.0005910771042467142

You might notice that deflection reported by trinfo is less than double tolerance of the shape (0.00041686426330493794 * 2 = 0.00083372852660987588). This is due to the fact that BRepMesh tries to approximate deviation of triangles from real surface using common approaches and remember the worst one as the result deflection.

With best regards,
Oleg.
(0034721)
nikiml   
2014-11-26 20:01   
Hi Oleg,

thank you for looking into it.
I did try the steps you outlined and this is the tolerance info i got:

Tolerance MAX=0.00041686426330493794 AVG=3.0071378819225741e-005 MIN=9.9999999999999995e-008
FACE : MAX=9.9999999999999995e-008 AVG=9.9999999999999995e-008 MIN=9.9999999999999995e-008
EDGE : MAX=4.7788167756847529e-007 AVG=1.7121668554196864e-007 MIN=9.9999999999999995e-008
VERTEX : MAX=0.00041686426330493794 AVG=4.6686536487135722e-005 MIN=9.9999999999999995e-008

which if i understand it correctly means there are some vertices attached to that face at distances ~.0004 from the surface.

I then did some manual+python step parsing and extracted the step code for that face (attached). I then checked the distances from the vertices to the surface and this is the list i got:
[9.586483546369914e-14, 1.4202197846473947e-14, 2.76942858006242e-13, 2.361115391976294e-13, 2.6451593489057727e-13, 3.5505494616184868e-15, 2.0948241823549072e-13, 2.982461547759529e-13, 1.8285329727335207e-13]

So i found no vertex at distance bigger than 9.9999999999999995e-008, and therefore I still do not understand where the value .004 is coming from.

Additionally I would expect that the conical surface can be tessellated with arbitrary precision and even if some face vertices are off only a handful of mesh vertices need to be corrected for that.

Hope this makes sense,
Best regards,
Nikolay
(0034727)
oan   
2014-11-27 11:19   
Hi Nikolay,

In OCCT tolerance has a little bit different meaning. If I am right, currently OCCT documention does not have distinct articles related to tolerances of shapes, however you can find some information about vertex/edge/face tolerance in chapter "BRep Format". Please use the following link: http://dev.opencascade.org/doc/overview/html/occt_user_guides__brep_wp.html#occt_brep_format_5_2 [^]

The point is that shape after retrieveing from STEP file automatically goes to shape fix tool which may enchance tolerances of vertices to fit them to the ends of 3D and 2D curves of neighboring edges.

Could you please explain the last supposition about tessellation of conical surface?
(0035689)
nikiml   
2014-12-24 16:51   
The sentence about conical surface is in fact valid for any explicit surface.

Not sure how the vertex tolerance ends up so big provided the edge and face tolerance are so small, but what I was trying to say is that even if there are some vertices that need to be so tolerant, if we imagine the following tessellation algorithm, the tessellation should not be that bad:

   1) tessellation is generated face by face (this tessellation can be as precise as the face tolerance above)
   2) edge tessellation is used "correct" or "refine" the face tessellation from 1) in order for adjacent face tessellations to match across the adjacent edges(resulting tessellation so far should be as precise as the edge tolerance above)
   3) fix/join tessellation vertices that correspond to body vertices

The last step will lead to tessellation as precise as the vertex tolerance, but it also affects only tessellation vertices that correspond to body vertices which amounts to "very few" vertices. Also, If a tolerant vertex in the body is on smooth edges than the resulting triangles can be as precise as the edge tolerance, and if the tolerance vertex is sharp than it can safely have multiple tessellation vertices matching it since they all need to have different normals anyway.

Hope it makes sense,

Nikolay
(0089830)
git   
2019-12-31 01:04   
Branch CR25287 has been created by oan.

SHA-1: f55af7858f8d9fabe8d831aca9891ea88b599fa9


Detailed log of new commits:

Author: oan
Date: Tue Dec 31 01:01:06 2019 +0300

    0025287: BRepMesh_IncrementalMesh produces (way) out of tolerance mesh
    Added test case
(0089831)
oan   
2019-12-31 01:11   
The issue could be solved using feature introduced in context of 0031251 patch.

Parameter -force_face_def of incmesh command may be used to achieve better results.
(0089840)
msv   
2020-01-09 09:43   
This test case runs longer than 3 hours on my PC. Please make it run shorter to include it in the test base.
(0089841)
msv   
2020-01-09 09:44   
And please make a jenkins job to validate it.
(0089864)
git   
2020-01-13 11:52   
Branch CR25287 has been updated forcibly by oan.

SHA-1: 714a80d555fb59e659cc53fa4cd5974e2566d166
(0089870)
oan   
2020-01-13 14:09   
Mikhail,

Please asure that you checked out and compiled the latest version of OCCT.

Test reports are available by the following link:
http://jenkins-test-12.nnov.opencascade.com/view/CR25287-master-OAN/view/COMPARE/ [^]

Execution time of "test bugs mesh bug25287":
TOTAL CPU TIME: 1.16 sec

(0089872)
msv   
2020-01-13 14:33   
Reviewed.
(0089946)
git   
2020-01-18 15:36   
Branch CR25287 has been deleted by inv.

SHA-1: 714a80d555fb59e659cc53fa4cd5974e2566d166