MantisBT - Community
View Issue Details
0023857Community[OCCT] OCCT:Modeling Algorithmspublic2013-03-25 17:072016-09-26 08:29
Timo 
abv 
normaltweak 
closednot fixable 
[OCCT] 6.5.4 
[OCCT] Unscheduled 
0023857: Degenerate surface normals occur on face boundary.
Some triangles of the surface mesh seem to have wrong normals, which make the surface look dark on the boundary.

Meshing the surface with lower deflection makes the dark stripe smaller, but always the outermost triangles are dark.

The surface was created from the points contained in Volute4.brep using GeomAPI_PointsToBSplineSurface with default parameters.

Is this a meshing problem or is the surface created by GeomAPI_PointsToBSplineSurface problematic?

restore Volute4.brep v
vinit
vdisplay v
vfit
vsetdispmode v
vsetdispmode v 1
No tags attached.
parent of 0025209closed bugmaster Open CASCADE Draw command "normals" should be extended to show variable number of normals 
? Volute4.brep (294,862) 2013-03-25 17:07
https://tracker.dev.opencascade.org/
png false normals.png (84,639) 2013-03-25 17:08
https://tracker.dev.opencascade.org/
png false normals flat shading.PNG (28,991) 2013-03-25 17:08
https://tracker.dev.opencascade.org/
png Normals_At_MidVParam.png (5,751) 2014-09-02 11:29
https://tracker.dev.opencascade.org/
Issue History
2013-03-25 17:07TimoNew Issue
2013-03-25 17:07TimoAssigned To => oan
2013-03-25 17:07TimoFile Added: Volute4.brep
2013-03-25 17:08TimoFile Added: false normals.png
2013-03-25 17:08TimoFile Added: false normals flat shading.PNG
2014-09-02 11:24oanRelationship addedparent of 0025209
2014-09-02 11:29oanFile Added: Normals_At_MidVParam.png
2014-09-02 11:39oanNote Added: 0031263
2014-09-02 11:40oanCategoryOCCT:Mesh => OCCT:Modeling Algorithms
2014-09-02 11:40oanAssigned Tooan => ifv
2014-09-11 18:05abvNote Added: 0031625
2014-09-11 18:05abvAssigned Toifv => Timo
2014-09-11 18:05abvStatusnew => feedback
2014-09-11 18:05abvTarget Version => Unscheduled
2014-09-12 13:23TimoNote Added: 0031660
2014-09-12 13:24TimoAssigned ToTimo => abv
2014-09-12 13:24TimoStatusfeedback => assigned
2014-09-12 13:48abvNote Added: 0031661
2014-10-29 12:04TimoNote Added: 0033807
2016-09-23 14:41TimoNote Added: 0058071
2016-09-26 08:28abvNote Added: 0058130
2016-09-26 08:28abvStatusassigned => closed
2016-09-26 08:29abvResolutionopen => not fixable

Notes
(0031263)
oan   
2014-09-02 11:39   
Reported problem related to incorrect surface produced by GeomAPI_PointsToBSplineSurface (see screenshot Normals_At_MidVParam.png).

Surface with inverted normals at its boundaries does not allow producing correct mesh anyway and result will always have dark areas during visualization.
(0031625)
abv   
2014-09-11 18:05   
Hello Timo,

The problem is in surface produced by GeomAPI algorithm on this set of points; I suggest you try using different algorithm for its generation.
(0031660)
Timo   
2014-09-12 13:23   
Yes, we can also use a different algorithm, but we have many other similar cases where this problem doesn't occur with GeomAPI. So, basically such distribution of points seems to be compatible with GeomAPI. Wouldn't it be good to investigate it and to make it more robust if possible?
(0031661)
abv   
2014-09-12 13:48   
As far as I understand, default algorithm in GeomAPI_PointsToBSplineSurface is direct interpolation, which is quite straightforward and well-defined algorithm. It is known that such algorithms are sensitive to input data and can produce geometries with loops. However, they are still useful in many cases.

If we consider improving this algorithm, this will mean we create different one. But we already have a number of alternative algorithms in GeomAPI, that is why I suggest trying them first.

Note that it is still possible that interpolation algorithm has some bug inside, though I believe it is very unlikely.
(0033807)
Timo   
2014-10-29 12:04   
Dear Andrey,

which algorithms for surface creation in GeomAPI do you mean?

Or do you mean algorithms from other packages, e.g. BRepOffsetAPI_ThruSections?
(0058071)
Timo   
2016-09-23 14:41   
From my side, the issue could be closed as we are now using BRepOffsetAPI_ThruSections instead.
(0058130)
abv   
2016-09-26 08:28   
Closed as not fixable