|Anonymous | Login||2018-03-20 14:48 MSK|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0029421||Open CASCADE||[OCCT] OCCT:Modeling Algorithms||public||2018-01-11 17:43||2018-01-22 13:26|
|Product Version||[OCCT] 7.2.0|
|Target Version||[OCCT] 7.4.0*||Fixed in Version|
|Summary||0029421: Improve 2D-classifier|
|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|
|Attached Files|| invalid deflection.PNG (11,585 bytes) 2018-01-12 11:45|
garmon.brep (1,472 bytes) 2018-01-12 11:46
0001-0028211-Modeling-Algorithms-Boolean-fuse-operation-p.patch (725,209 bytes) 2018-01-22 13:17
git_fragment.PNG (8,088 bytes) 2018-01-22 13:26
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.
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.
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.
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.
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.
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.
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-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|
|2018-01-22 11:37||nbv||Relationship added||related to 0026842|
|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|
|Copyright © 2000 - 2018 MantisBT Team|