MantisBT
Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Related Changesets ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0025287Community[OCCT] OCCT:Meshpublic2014-09-29 17:172020-03-20 10:12
Reporternikiml 
Assigned Tobugmaster 
PrioritynormalSeveritymajor 
StatusverifiedResolutionfixed 
PlatformWindowsOSVC++ 2005OS Version64 bit
Product Version 
Target Version[OCCT] 7.5.0*Fixed in Version 
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 Files7z file icon bad_tessellation.7z (1,026,420 bytes) 2014-09-29 17:17
? file icon face_only.step (11,777 bytes) 2014-11-26 19:54

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

-  Notes
(0032327)
nikiml (developer)
2014-09-29 18:11

Actually VC++ 2008 is the compiler I used
(0034650)
oan (developer)
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 (developer)
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 (developer)
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 (developer)
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 (administrator)
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 (developer)
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 (developer)
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 (developer)
2020-01-09 09:44

And please make a jenkins job to validate it.
(0089864)
git (administrator)
2020-01-13 11:52

Branch CR25287 has been updated forcibly by oan.

SHA-1: 714a80d555fb59e659cc53fa4cd5974e2566d166
(0089870)
oan (developer)
2020-01-13 14:09
edited on: 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 (developer)
2020-01-13 14:33

Reviewed.
(0089946)
git (administrator)
2020-01-18 15:36

Branch CR25287 has been deleted by inv.

SHA-1: 714a80d555fb59e659cc53fa4cd5974e2566d166

- Related Changesets
occt: master 0c061f3d
Timestamp: 2019-12-30 22:01:06
Author: oan
Committer: bugmaster
Details ] Diff ]
0025287: BRepMesh_IncrementalMesh produces (way) out of tolerance mesh Added test case
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 View Revisions
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


Copyright © 2000 - 2020 MantisBT Team
Powered by Mantis Bugtracker