View Issue Details

IDProjectCategoryView StatusLast Update
0029421Open CASCADEOCCT:Modeling Algorithmspublic2019-09-06 07:43
ReporternbvAssigned Tomsv  
Status feedbackResolutionopen 
Product Version7.2.0 
Target VersionUnscheduled 
Summary0029421: Make face classifier algorithm stable and robust
DescriptionAlgorithm of classification of 2D-point relatively to the face is a fundamental low-level OCCT-algorithm. Therefore, it should be made more stable and reliable.

Some steps to improve have been (temporary) made in frame of the fix #28211. Further improvement will consist:

1. Make OCCT work with discrete polygonal classifier only (such as CSLib_Class2d). As result, classes BRepTopAdaptor_FClass2d and IntTools_FClass2d should be eliminated.

2. Use geometrical model only for checking ON-status (compare the minimal distance between the classified point and curve with the given tolerance). For searching this distance, use fond nearest point on the correspond segment of the polygon as a start point for local extrema algorithm.
TagsNo tags attached.
Test case number

Attached Files

  • invalid deflection.PNG (11,585 bytes)
  • garmon.brep (1,472 bytes)
  • 0001-0028211-Modeling-Algorithms-Boolean-fuse-operation-p.patch (725,209 bytes)
  • git_fragment.PNG (8,088 bytes)
  • patch to IR-2018-07-13.patch (690,664 bytes)
  • patches(IR-2018-11-16).7z (109,071 bytes)


related to 0029860 assignedemv Open CASCADE Modeling Algorithms - BOPAlgo_BuilderFace cannot build new faces correctly 
related to 0023667 feedbacknbv Open CASCADE checkshape command does not detect problems in the attached shape 
related to 0028800 feedbackmsv Open CASCADE The compound of two faces is incorrectly detected as self-interfered 
related to 0029203 feedbackmsv Open CASCADE Ambiguous behavior of Point-Face-classification algorithms: shall it return ON-status? 
related to 0030365 verifiedsmoskvin Open CASCADE Modeling Algorithms - Create tool to compute deviation between any 2D-curve and some its segment 
related to 0030947 feedbackifv Open CASCADE Modeling Algorithms, BRepClass_FaceClassifier - Incorrect classification of the point 



2018-01-11 18:34

developer   ~0073367


Please note that IntTools_FClass2d is used in many OCCT-dependent projects which might need precise classifier and not the polygonal one (which would require a prior tessellation apparently). So, please, consider keeping the precise classifier in OCCT. It is natural to have a precise classifier for precise geometry in a precise modeling kernel which OCCT actually is.


2018-01-12 10:11

developer   ~0073371

Last edited: 2018-01-12 10:17

Dear Sergei (SSV),

Indeed, I do not support migration to work with discreet objects instead of continuous one (e.g. replace curves with polygons etc.). However, it is my (and only mine) general position. Discreet object is approximate model, which increases inaccuracies.

However, please take into account the fact that the main objective of classifier is in defining state of point (IN or OUT). In most valid cases, considering discreet objects (instead of continuous one) is enough for it. Moreover, (if obtained polygon does not contain self-intersections) we can trust the polygonal classifier absolutely.

I.e. main question is in quality of discretisation and in validity of shape itself.

> IntTools_FClass2d is used in many OCCT-dependent projects which might need precise classifier

Why must classifier be precise? Which information do you need to obtain? Parameter on edge? We will keep this possibility. However, even in current OCCT-algorithms (TopOpeBrep*-classes), this parameter is used only in case of ON-status of classification. But it is not task for classifier. And, of course, new parameter (after this bug will be fixed) will differ from current one.

Sergei, computation of this parameter is not a task of classifier. Please use Extrema algorithm. You will obtain more stable and reliable result.


2018-01-12 10:32

developer   ~0073372

When we speak about a classifier, we touch the very (if not the most) basic thing of modeling. You ask "Why classifier must be precise?". For me, it should be precise simply because otherwise, you cannot have a true precise modeler (whenever I say "precise" I do not account inevitable numerical imprecision, I mean only curved geometry).

The job of a classifier is to take a bounded region (1D, 2D or 3D) and perform point membership classification (PMC) test. Internally, it can use whatever mechanism (e.g., extrema). If I understand your point, you are going to use a polygonal domain instead of the curved one to make PMC test faster and more reliably. I agree that it can make sense in some circumstances. What I ask is not to remove the basic PMC tool (IntTools_FClass2d) which works on a real (not approximated) geometry. The tool is used in many projects and it works quite well. Please, let's keep the tools which are useful and working. OCCT non-regression database is too small (actually, it is super-small compared to commercial kernels) to be sure that such a fundamental change will not break anything in extra projects.


2018-01-12 11:09

developer   ~0073375


1. Current classes BRepTopAdaptor_FClass2d and IntTools_FClass2d will be defined as DEPRECATED (they will exist during several releases). However, new classifier will be put into special new package.

2. User interface (API) of classifier will not be changed. Input data (as now) will be: 2D-point, face and tolerance. All corrections will touch implementation only.

3. In case, when discreet classifier returns ON-status but real status is not ON (the distance between classified point and real edge is quite big), quality of discretisation must be locally (!) increased until the polygonal classifier returns status differ from ON.


2018-01-12 11:45

developer   ~0073382

Last edited: 2018-01-12 12:48

Please note that using of discreet model (instead of continued one) requires computation of precise deflection. It will take much system time. Especially in case, shown in the picture "invalid deflection.PNG" (screenshot of garmon.brep attached curve).

2D-deflection itself can be computed with recurrent formula from the message 0029203:0071647. However, it requires start-point. So, in considered case, this computation must be executed several time (for every knee) or we need to discretise every interknots-interval separately.


2018-01-12 11:45


invalid deflection.PNG (11,585 bytes)


2018-01-12 11:46


garmon.brep (1,472 bytes)


2018-01-12 18:05

developer   ~0073394

I do not agree with conclusions.
It was intended to do the next steps in this bug:

1. Make IntTools_FClass2d be alias to BRepTopAdaptor_FClass2d and declare it deprecated.

2. Make all improvements inside the class BRepTopAdaptor_FClass2d.

Actually it already contains procedure of discretization to obtain a polygon, and the algorithm uses polygon if the point is far enough from it. And the algorithm uses exact BRepClass_FaceClassifier in other case.

In the new code, if the point is near to some polygon segment, it will be re-checked using local extrema on curve. If it is not ON the curve, then usual classification with polygon is performed, except for near segments; for them local extrema line-curve will be used to obtain the actual parameter of intersection point on the ray.


2018-01-22 13:17


0001-0028211-Modeling-Algorithms-Boolean-fuse-operation-p.patch (725,209 bytes)


2018-01-22 13:25

developer   ~0073554

Attached file "0001-0028211-Modeling-Algorithms-Boolean-fuse-operation-p.patch" contains all accumulations made in frame of the fix for the issue #28211 (branch CR28211_msv). Maybe some code fragment (mainly test cases from "lowalgos") will be useful for this new development.

This patch is based on "remotes/origin/IR-2018-01-19" (see "git_fragment.PNG" attached picture; patches for other commits are included in separated relation bugs).


2018-01-22 13:26


git_fragment.PNG (8,088 bytes)


2018-07-20 09:36


patch to IR-2018-07-13.patch (690,664 bytes)


2018-07-20 09:38

developer   ~0077840

The file "patch to IR-2018-07-13.patch" contains the version of the fix from "0001-0028211-Modeling-Algorithms-Boolean-fuse-operation-p.patch" rebased on IR-2018-07-13. Some test cases have become failed. Their new behavior should be investigated again.


2018-10-23 11:07

developer   ~0080217

Last edited: 2018-11-19 14:17

Dear colleagues,

The attached file "patches(IR-2018-11-16).7z" contains continued fix rebased on IR-2018-11-16. Currently this fix contain all important parts made in frame of the issue #28211 and some additional tools touching improvements in discretization wires for polygonal classifier and in compute maximal deviation of this discretization.

Nevertheless, before starting improvement of classifier algorithm itself (no matter: discrete classifier, polygonal classifier or ray-classifier) we must answer the many questions about predictable behavior of the new algorithm. In detail, these questions are explained in the Word-document (in Russian) sent to you. Here I am enumerating them:

1. How should we check ON-status (see the issue 0029203)? Shall we use only external input tolerance or we have to take into account tolerances of edges and vertices? In 1st case, there is a risk of ambiguous result of checking in 2D and in 3D-space. E.g. completely valid edge having quite big tolerance (to satisfy same-parameter criterion). We classify some 2D-point which lies exactly in 2D-curve. However, the distance between its 3D-image and the edge is greater than the input tolerance (but less than the tolerance of the edge). Shall we return ON-status in this case? Additionally, please see the message 0029203:0071647. Iterative formula has been rewritten in the attached patches (see issue 0030365).

2. In most cases, pseudo-edges increase stability and robustness of the classification algorithm. But what shall we do in case of negative role of these edges (when the behavior of the current version of the algorithm is much more logical and stable than the algorithm with pseudo-edges)?

3. CSLib_Class2d. Do we really need in both tolerances (TolU and TolV) or one 2D-tolerance is enough? Moreover, every polygonal segment must have its individual tolerance (equal to the maximal deviation to the curve). Additionally, for discrete classifier we need to store coincidence between every polygonal segment and corresponding arc. And the head question is: how shall we process cases when the curve intersects corresponding segments in several points (i.e. has micro-oscillations).

4. Tool for checking of self-interference of the polygon is really important for polygonal-classifier. However, it makes work of the algorithm significantly slower in most valid cases (when p-curve of the faces has trivial rectangular structure). So, What shall we do here?


2018-10-23 11:08

developer   ~0080219

Dear Mikhail,

We are looking forward your decision.


2018-11-19 14:13


patches(IR-2018-11-16).7z (109,071 bytes)

Issue History

Date Modified Username Field Change
2018-01-11 17:43 nbv New Issue
2018-01-11 17:43 nbv Assigned To => msv
2018-01-11 18:34 ssv Note Added: 0073367
2018-01-12 10:11 nbv Note Added: 0073371
2018-01-12 10:14 nbv Note Edited: 0073371
2018-01-12 10:17 nbv Note Edited: 0073371
2018-01-12 10:32 ssv Note Added: 0073372
2018-01-12 11:09 nbv Note Added: 0073375
2018-01-12 11:45 nbv Note Added: 0073382
2018-01-12 11:45 nbv File Added: invalid deflection.PNG
2018-01-12 11:46 nbv File Added: garmon.brep
2018-01-12 12:48 nbv Note Edited: 0073382
2018-01-12 15:58 nbv Relationship added related to 0029203
2018-01-12 17:29 msv Product Version => 7.2.0
2018-01-12 18:05 msv Note Added: 0073394
2018-01-12 18:06 msv Assigned To msv => nbv
2018-01-12 18:06 msv Status new => assigned
2018-01-22 13:17 nbv File Added: 0001-0028211-Modeling-Algorithms-Boolean-fuse-operation-p.patch
2018-01-22 13:25 nbv Note Added: 0073554
2018-01-22 13:26 nbv File Added: git_fragment.PNG
2018-05-22 09:57 msv Summary Improve 2D-classifier => Make face classifier algorithm stable and robust
2018-07-19 15:34 nbv Relationship added related to 0029860
2018-07-19 15:35 nbv Relationship added related to 0023667
2018-07-19 15:36 nbv Relationship added related to 0028800
2018-07-20 09:36 nbv File Added: patch to IR-2018-07-13.patch
2018-07-20 09:38 nbv Note Added: 0077840
2018-10-23 09:58 nbv File Added: patches (IR-2018-10-19).7z
2018-10-23 10:00 nbv File Deleted: patches (IR-2018-10-19).7z
2018-10-23 10:01 nbv File Added: patches (IR-2018-10-19).7z
2018-10-23 11:07 nbv Note Added: 0080217
2018-10-23 11:08 nbv Note Added: 0080219
2018-10-23 11:08 nbv Assigned To nbv => msv
2018-10-23 11:08 nbv Status assigned => feedback
2018-11-19 14:05 nbv File Deleted: patches (IR-2018-10-19).7z
2018-11-19 14:13 nbv File Added: patches(IR-2018-11-16).7z
2018-11-19 14:15 nbv Note Edited: 0080217
2018-11-19 14:17 nbv Note Edited: 0080217
2018-11-23 12:57 nbv Relationship added related to 0030365
2019-07-18 18:58 msv Target Version 7.4.0 => Unscheduled
2019-09-06 07:43 emv Relationship added related to 0030947