View Issue Details

Related ChangesetsJump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0025287CommunityOCCT:Meshpublic2014-09-29 17:172020-12-02 17:11
Reporternikiml Assigned Tobugmaster  
PrioritynormalSeveritymajor 
Status closedResolutionfixed 
PlatformWindowsOSVC++ 2005 
Target Version7.5.0Fixed in Version7.5.0 
Summary0025287: BRepMesh_IncrementalMesh produces (way) out of tolerance mesh
DescriptionObserved 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.
Steps To ReproduceSTEPControl_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);
}
TagsNo tags attached.
Test case numberbugs/mesh/bug25287

Attached Files

  • bad_tessellation.7z (1,026,420 bytes)
  • face_only.step (11,777 bytes)

Relationships

related to 0031251 closedbugmaster Community Mesh - Add a parameter for IncrementalMesh to ignore face tolerance for face deflection 
related to 0031449 closedoan Open CASCADE Mesh - BRepMesh works too long and produces many free nodes on a valid face 

Activities

nikiml

2014-09-29 17:17

developer  

bad_tessellation.7z (1,026,420 bytes)

nikiml

2014-09-29 18:11

developer   ~0032327

Actually VC++ 2008 is the compiler I used

oan

2014-11-24 18:13

developer   ~0034650

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.

nikiml

2014-11-26 19:54

developer  

face_only.step (11,777 bytes)

nikiml

2014-11-26 20:01

developer   ~0034721

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

oan

2014-11-27 11:19

developer   ~0034727

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?

nikiml

2014-12-24 16:51

developer   ~0035689

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

git

2019-12-31 01:04

administrator   ~0089830

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

oan

2019-12-31 01:11

developer   ~0089831

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.

msv

2020-01-09 09:43

developer   ~0089840

This test case runs longer than 3 hours on my PC. Please make it run shorter to include it in the test base.

msv

2020-01-09 09:44

developer   ~0089841

And please make a jenkins job to validate it.

git

2020-01-13 11:52

administrator   ~0089864

Branch CR25287 has been updated forcibly by oan.

SHA-1: 714a80d555fb59e659cc53fa4cd5974e2566d166

oan

2020-01-13 14:09

developer   ~0089870

Last edited: 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

msv

2020-01-13 14:33

developer   ~0089872

Reviewed.

git

2020-01-18 15:36

administrator   ~0089946

Branch CR25287 has been deleted by inv.

SHA-1: 714a80d555fb59e659cc53fa4cd5974e2566d166

Related Changesets

occt: master 0c061f3d

2019-12-30 22:01:06

oan


Committer: bugmaster Details Diff		 0025287: BRepMesh_IncrementalMesh produces (way) out of tolerance mesh Added test case Affected Issues
0025287
add - tests/bugs/mesh/bug25287 Diff File

Issue History

Date Modified Username Field Change
2014-09-29 17:17 nikiml New Issue
2014-09-29 17:17 nikiml Assigned To => oan
2014-09-29 17:17 nikiml File Added: bad_tessellation.7z
2014-09-29 18:11 nikiml Note Added: 0032327
2014-11-24 18:13 oan Note Added: 0034650
2014-11-24 18:13 oan Assigned To oan => nikiml
2014-11-24 18:13 oan Status new => feedback
2014-11-26 19:54 nikiml File Added: face_only.step
2014-11-26 20:01 nikiml Note Added: 0034721
2014-11-27 00:37 nikiml Assigned To nikiml => oan
2014-11-27 11:19 oan Assigned To oan => nikiml
2014-11-27 11:19 oan Note Added: 0034727
2014-12-24 16:51 nikiml Note Added: 0035689
2014-12-26 05:16 nikiml Assigned To nikiml => oan
2017-08-14 16:39 abv Target Version => 7.4.0
2019-09-06 18:34 oan Target Version 7.4.0 => 7.5.0
2019-12-20 20:07 oan Relationship added related to 0031251
2019-12-31 01:04 git Note Added: 0089830
2019-12-31 01:06 oan Assigned To oan => msv
2019-12-31 01:06 oan Status feedback => resolved
2019-12-31 01:11 oan Note Added: 0089831
2020-01-09 09:43 msv Note Added: 0089840
2020-01-09 09:43 msv Assigned To msv => oan
2020-01-09 09:43 msv Status resolved => assigned
2020-01-09 09:44 msv Note Added: 0089841
2020-01-13 11:52 git Note Added: 0089864
2020-01-13 14:09 oan Note Added: 0089870
2020-01-13 14:09 oan Assigned To oan => msv
2020-01-13 14:09 oan Status assigned => resolved
2020-01-13 14:09 oan Note Edited: 0089870
2020-01-13 14:33 msv Note Added: 0089872
2020-01-13 14:33 msv Assigned To msv => bugmaster
2020-01-13 14:33 msv Status resolved => reviewed
2020-01-13 16:12 bugmaster Test case number => bugs/mesh/bug25287
2020-01-13 16:17 bugmaster Status reviewed => tested
2020-01-18 12:27 bugmaster Changeset attached => occt master 0c061f3d
2020-01-18 12:27 bugmaster Status tested => verified
2020-01-18 12:27 bugmaster Resolution open => fixed
2020-01-18 15:36 git Note Added: 0089946
2020-03-20 10:12 oan Relationship added related to 0031449
2020-12-02 16:40 emo Fixed in Version => 7.5.0
2020-12-02 17:11 emo Status verified => closed