View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0029421 | Open CASCADE | OCCT:Modeling Algorithms | public | 2018-01-11 17:43 | 2019-09-06 07:43 |
| Reporter | Assigned To | ||||
| Priority | normal | Severity | minor | ||
| Status | feedback | Resolution | open | ||
| Product Version | 7.2.0 | ||||
| Target Version | Unscheduled | ||||
| Summary | 0029421: Make face classifier algorithm stable and robust | ||||
| Description | Algorithm 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. | ||||
| Tags | No tags attached. | ||||
| Test case number | |||||
| related to | 0029860 | assigned | Open CASCADE | Modeling Algorithms - BOPAlgo_BuilderFace cannot build new faces correctly | |
| related to | 0023667 | feedback | Open CASCADE | checkshape command does not detect problems in the attached shape | |
| related to | 0028800 | feedback | Open CASCADE | The compound of two faces is incorrectly detected as self-interfered | |
| related to | 0029203 | feedback | Open CASCADE | Ambiguous behavior of Point-Face-classification algorithms: shall it return ON-status? | |
| related to | 0030365 | closed | Open CASCADE | Modeling Algorithms - Create tool to compute deviation between any 2D-curve and some its segment | |
| related to | 0030947 | feedback | Open CASCADE | Modeling Algorithms, BRepClass_FaceClassifier - Incorrect classification of the point |
|
|
DC, 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. |
|
|
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. |
|
|
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. |
|
|
Resume: 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. |
|
|
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 developer |
invalid deflection.PNG (11,585 bytes) |
|
2018-01-12 11:46 developer |
garmon.brep (1,472 bytes) |
|
|
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 developer |
0001-0028211-Modeling-Algorithms-Boolean-fuse-operation-p.patch (725,209 bytes) |
|
|
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 developer |
git_fragment.PNG (8,088 bytes) |
|
2018-07-20 09:36 developer |
patch to IR-2018-07-13.patch (690,664 bytes) |
|
|
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. |
|
|
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? |
|
|
Dear Mikhail, We are looking forward your decision. |
|
2018-11-19 14:13 developer |
patches(IR-2018-11-16).7z (109,071 bytes) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-01-11 17:43 |
|
New Issue | |
| 2018-01-11 17:43 |
|
Assigned To | => msv |
| 2018-01-11 18:34 |
|
Note Added: 0073367 | |
| 2018-01-12 10:11 |
|
Note Added: 0073371 | |
| 2018-01-12 10:14 |
|
Note Edited: 0073371 | |
| 2018-01-12 10:17 |
|
Note Edited: 0073371 | |
| 2018-01-12 10:32 |
|
Note Added: 0073372 | |
| 2018-01-12 11:09 |
|
Note Added: 0073375 | |
| 2018-01-12 11:45 |
|
Note Added: 0073382 | |
| 2018-01-12 11:45 |
|
File Added: invalid deflection.PNG | |
| 2018-01-12 11:46 |
|
File Added: garmon.brep | |
| 2018-01-12 12:48 |
|
Note Edited: 0073382 | |
| 2018-01-12 15:58 |
|
Relationship added | related to 0029203 |
| 2018-01-12 17:29 |
|
Product Version | => 7.2.0 |
| 2018-01-12 18:05 |
|
Note Added: 0073394 | |
| 2018-01-12 18:06 |
|
Assigned To | msv => nbv |
| 2018-01-12 18:06 |
|
Status | new => assigned |
| 2018-01-22 13:17 |
|
File Added: 0001-0028211-Modeling-Algorithms-Boolean-fuse-operation-p.patch | |
| 2018-01-22 13:25 |
|
Note Added: 0073554 | |
| 2018-01-22 13:26 |
|
File Added: git_fragment.PNG | |
| 2018-05-22 09:57 |
|
Summary | Improve 2D-classifier => Make face classifier algorithm stable and robust |
| 2018-07-19 15:34 |
|
Relationship added | related to 0029860 |
| 2018-07-19 15:35 |
|
Relationship added | related to 0023667 |
| 2018-07-19 15:36 |
|
Relationship added | related to 0028800 |
| 2018-07-20 09:36 |
|
File Added: patch to IR-2018-07-13.patch | |
| 2018-07-20 09:38 |
|
Note Added: 0077840 | |
| 2018-10-23 09:58 |
|
File Added: patches (IR-2018-10-19).7z | |
| 2018-10-23 10:00 |
|
File Deleted: patches (IR-2018-10-19).7z | |
| 2018-10-23 10:01 |
|
File Added: patches (IR-2018-10-19).7z | |
| 2018-10-23 11:07 |
|
Note Added: 0080217 | |
| 2018-10-23 11:08 |
|
Note Added: 0080219 | |
| 2018-10-23 11:08 |
|
Assigned To | nbv => msv |
| 2018-10-23 11:08 |
|
Status | assigned => feedback |
| 2018-11-19 14:05 |
|
File Deleted: patches (IR-2018-10-19).7z | |
| 2018-11-19 14:13 |
|
File Added: patches(IR-2018-11-16).7z | |
| 2018-11-19 14:15 |
|
Note Edited: 0080217 | |
| 2018-11-19 14:17 |
|
Note Edited: 0080217 | |
| 2018-11-23 12:57 |
|
Relationship added | related to 0030365 |
| 2019-07-18 18:58 |
|
Target Version | 7.4.0 => Unscheduled |
| 2019-09-06 07:43 |
|
Relationship added | related to 0030947 |
