|Anonymous | Login||2020-02-27 21:07 MSK|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0023857||Community||[OCCT] OCCT:Modeling Algorithms||public||2013-03-25 17:07||2016-09-26 08:29|
|Product Version||[OCCT] 6.5.4|
|Target Version||[OCCT] Unscheduled||Fixed in Version|
|Summary||0023857: Degenerate surface normals occur on face boundary.|
|Description||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?
|Steps To Reproduce||restore Volute4.brep v|
vsetdispmode v 1
|Tags||No tags attached.|
|Test case number|
|Attached Files|| Volute4.brep (294,862 bytes) 2013-03-25 17:07|
false normals.png (84,639 bytes) 2013-03-25 17:08
false normals flat shading.PNG (28,991 bytes) 2013-03-25 17:08
Normals_At_MidVParam.png (5,751 bytes) 2014-09-02 11:29
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.
The problem is in surface produced by GeomAPI algorithm on this set of points; I suggest you try using different algorithm for its generation.
|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?|
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.
which algorithms for surface creation in GeomAPI do you mean?
Or do you mean algorithms from other packages, e.g. BRepOffsetAPI_ThruSections?
|From my side, the issue could be closed as we are now using BRepOffsetAPI_ThruSections instead.|
|Closed as not fixable|
|2013-03-25 17:07||Timo||New Issue|
|2013-03-25 17:07||Timo||Assigned To||=> oan|
|2013-03-25 17:07||Timo||File Added: Volute4.brep|
|2013-03-25 17:08||Timo||File Added: false normals.png|
|2013-03-25 17:08||Timo||File Added: false normals flat shading.PNG|
|2014-09-02 11:24||oan||Relationship added||parent of 0025209|
|2014-09-02 11:29||oan||File Added: Normals_At_MidVParam.png|
|2014-09-02 11:39||oan||Note Added: 0031263|
|2014-09-02 11:40||oan||Category||OCCT:Mesh => OCCT:Modeling Algorithms|
|2014-09-02 11:40||oan||Assigned To||oan => ifv|
|2014-09-11 18:05||abv||Note Added: 0031625|
|2014-09-11 18:05||abv||Assigned To||ifv => Timo|
|2014-09-11 18:05||abv||Status||new => feedback|
|2014-09-11 18:05||abv||Target Version||=> Unscheduled|
|2014-09-12 13:23||Timo||Note Added: 0031660|
|2014-09-12 13:24||Timo||Assigned To||Timo => abv|
|2014-09-12 13:24||Timo||Status||feedback => assigned|
|2014-09-12 13:48||abv||Note Added: 0031661|
|2014-10-29 12:04||Timo||Note Added: 0033807|
|2016-09-23 14:41||Timo||Note Added: 0058071|
|2016-09-26 08:28||abv||Note Added: 0058130|
|2016-09-26 08:28||abv||Status||assigned => closed|
|2016-09-26 08:29||abv||Resolution||open => not fixable|
|Copyright © 2000 - 2020 MantisBT Team|