MantisBT - Community
View Issue Details
0022778Community[OCCT] OCCT:Meshpublic2011-10-25 14:372016-06-06 16:15
szy 
bugmaster 
normalminor 
closedfixed 
A
[OCCT] 6.5.2 
[OCCT] 6.6.0[OCCT] 6.6.0 
bugs mesh bug22778
0022778: Bug in BRepMesh
Post from the Forum - http://www.opencascade.org/org/forum/thread_22070/. [^]
" Here are a geometry and a program that show the B-spline mesher is still buggy in OCCT 6.5.1. The BRep is a sphere trimmed by a square made of 120 TopoDS_Edge. The program is run with the B-spline mesher and without (thanks to the attached patch). In both cases I give the number of triangles for the sphere as a reference (the optimal mesh), and for the sphere converted to GeomAbs_BSplineSurface.

Without the patch (B-spline mesher):
$ ./a.out
Number of triangles for the sphere geometry: 886
Number of triangles for the nurbs geometry: 46948

With the patch (generic mesher):
$ ./a.out
Number of triangles for the sphere geometry: 886
Number of triangles for the nurbs geometry: 1676

This geometry is not a pathological case as over refined trimming are more than common in real world. I think a mesh 28 time too thin should be concidered as a bug.

See the patch, source code, and geometry attached.

Regards,

Jerome
"
So, after applying to the initial shape of the BRepBuilderAPI_NurbsConvert and building a mesh with the same deflection a number of triangles sufficiently differ.
plaod ALL
restore square.brep s
checkshape s
incmesh s 0.001
trinfo s
##This shape contains 226 triangles.
## 174 nodes.
##Maximal deflection 0.00088688254163757894
nurbsconvert r s
checkshape r
## This shape seems to be valid
incmesh r 0.001
Draw[11]> trinfo r
This shape contains 2148 triangles.
                    1135 nodes.
Maximal deflection 6.7388607894560643e-005



No tags attached.
related to 0022893closed mkv Community Possible regression in tesselation algorithm of OCCT6.5.2 
bz2 bugocc.tar.bz2 (16,066) 2011-10-25 14:37
https://tracker.dev.opencascade.org/
Issue History
2011-10-25 14:37szyNew Issue
2011-10-25 14:37szyAssigned To => jgv
2011-10-25 14:37szyFile Added: bugocc.tar.bz2
2011-10-25 14:38szyAssigned Tojgv => pdn
2011-10-25 14:44pdnAssigned Topdn => azn
2011-11-25 14:35szyNote Added: 0018624
2011-11-25 14:35szyAssigned Toazn => msv
2011-11-25 14:35szyStatusnew => assigned
2011-11-25 14:35szyOSL =>
2011-11-25 14:35szyOS VersionL =>
2011-11-25 18:43msvNote Added: 0018632
2011-11-25 18:44msvAssigned Tomsv => pdn
2011-11-28 14:53pdnNote Added: 0018641
2011-11-28 14:53pdnAssigned Topdn => abv
2011-11-28 15:36szyNote Added: 0018644
2011-12-01 09:54abvNote Deleted: 0018644
2012-01-13 22:11jeromerobertNote Added: 0019128
2012-01-14 08:24abvNote Added: 0019129
2012-01-14 08:24abvRelationship addedrelated to 0022893
2012-03-22 06:18abvTarget Version6.5.3 => 6.5.4
2012-10-23 19:15abvTarget Version6.5.4 => 6.6.0
2012-11-09 09:49abvCategoryOCCT:Modeling Algorithms => OCCT:Mesh
2012-12-03 22:54abvTest case number => bugs mesh bug22778
2012-12-03 22:56abvNote Added: 0022530
2012-12-03 22:56abvAssigned Toabv => bugmaster
2012-12-03 22:56abvStatusassigned => feedback
2013-01-16 15:00bugmasterStatusfeedback => tested
2013-01-21 18:30bugmasterNote Added: 0023047
2013-01-21 18:30bugmasterStatustested => verified
2013-01-21 18:30bugmasterResolutionopen => fixed
2013-04-23 13:36aivStatusverified => closed
2013-04-29 15:21aivFixed in Version => 6.6.0
2016-06-06 16:15abvRelationship addedrelated to 0027362

Notes
(0018624)
szy   
2011-11-25 14:35   
Mikhail,
Could you assign the bug to somebody from MESH pool.
SZY
(0018632)
msv   
2011-11-25 18:43   
There is no such entity "Mesh pool" in the organization. But I know that the mentioned algorithm was last time improved by various people under inspection of PDN.
Dear Pavel, could you help to find the proper person to fix the bug?
(0018641)
pdn   
2011-11-28 14:53   
After the analysis of the bug description, attached files and step to reproduce I can comment in the following way:
1) The current state of the BRepMesh mesher (OCC 6.5.2 and trunk) are better that state in the proposed patch. Current difference in sphere and NURBS is about 10 times.
2) This difference is quite OK and explained by the simple algorithmic behavior when information on analytic surface type (sphere) is used. In case of sphere, algorithm is able to compute the maximal error analytically, when for NURBS is should be estimated.

IMHO, the bug should be resolved as documented. Possible improvements if free BRepMesh algorithm can be considered in the frame of OCCT evolution. Similar issue is recorded for Express Mesh.
Thus, I reassign the problem to Andrey to take decision for planning.
(0019128)
jeromerobert   
2012-01-13 22:11   
Results with OCC 6.5.2 (much better thanks !):

B-Spline mesher:
  Number of triangles for the sphere geometry: 646
  Number of triangles for the nurbs geometry: 2148

Generic mesher:
  Number of triangles for the sphere geometry: 646
  Number of triangles for the nurbs geometry: 1438
(0019129)
abv   
2012-01-14 08:24   
I guess that issue 0022893 is probably related to this one, as an opposite side of the medal: decrease of number of triangles on b-splines can lead to decreased shading quality. To be investigated
(0022530)
abv   
2012-12-03 22:56   
Test case for this issue (bugs mesh bug22778) pushed to branch CR22778.
Note that I have moved test case for #23473 from bugs mesh bug23473 to relevant grid (mesh standard* X5).
Please review and test.
(0023047)
bugmaster   
2013-01-21 18:30   
Integrated into master of OCCT repository