Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0029421Open CASCADE[OCCT] OCCT:Modeling Algorithmspublic2018-01-11 17:432018-01-12 18:19
Assigned Tonbv 
PlatformOSOS Version
Product Version[OCCT] 7.2.0 
Target Version[OCCT] 7.3.0*Fixed in Version 
Summary0029421: Improve 2D-classifier
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 Filespng file icon invalid deflection.PNG (11,585 bytes) 2018-01-12 11:45
? file icon garmon.brep (1,472 bytes) 2018-01-12 11:46

- Relationships

-  Notes
ssv (developer)
2018-01-11 18:34


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.
nbv (developer)
2018-01-12 10:11
edited on: 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.

ssv (developer)
2018-01-12 10:32

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.
nbv (developer)
2018-01-12 11:09


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.
nbv (developer)
2018-01-12 11:45
edited on: 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.

msv (developer)
2018-01-12 18:05

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.

- 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 View Revisions
2018-01-12 10:17 nbv Note Edited: 0073371 View Revisions
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 11:49 nbv Relationship added related to 0028211
2018-01-12 12:48 nbv Note Edited: 0073382 View Revisions
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-12 18:19 nbv Note Added: 0073396
2018-01-12 18:26 nbv Note Deleted: 0073396

Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker