|Anonymous | Login||2020-09-19 15:20 MSK|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0026474||Open CASCADE||[OCCT] OCCT:Modeling Algorithms||public||2015-07-23 14:40||2015-09-24 16:48|
|Status||closed||Resolution||no change required|
|Product Version||[OCCT] 7.0.0|
|Target Version||[OCCT] 7.0.0||Fixed in Version|
|Summary||0026474: Wrong computation of the resolution value|
|Description||Wrong computation of the resolution value for the attached curve.|
The problem can be reproduced with the new test command implemented in the attached *.cxx file.
|Steps To Reproduce||restore curve c|
cresolution c 1
# Resolution: 2.747529759526899e-022
cresolution c 5
# Resolution: 1.3737648797634496e-021
cresolution c 10
# Resolution: 2.7475297595268991e-021
cresolution c 100
# Resolution: 2.7475297595268991e-020
cresolution c 500
# Resolution: 1.3737648797634494e-019
# The length c is 45.000000000010424
|Tags||No tags attached.|
|Test case number|
|Attached Files|| GeometryTest_CurveCommands.cxx (53,079 bytes) 2015-07-23 14:40|
curve (45,520 bytes) 2015-07-23 14:40
edited on: 2015-09-22 18:38
Calculation of resolution is not wrong.
2d resolution is estimatrd according to expression:
Res2d = Tol3d/(C'max)
C'max is majorizing estimation of curve first derivating.
Since some first curve knots are very small:
1 : 0 9
2 : 1.05755317956988e-022 7
3 : 1.78731240455025e-022 7
4 : 2.97759065402356e-022 7
5 : 3.73286165819553e-022 7
6 : 4.54736616300819e-022 7
7 : 5.82844651988856e-022 7
8 : 6.53579545489009e-020 7
9 : 2.1249198383615e-019 7
10 : 3.55638685921299e-019 7
11 : 1.00859242629379e-016 7
12 : 2.15539638728077e-016 7
13 : 3.14857393542064e-016 7
14 : 5.30298369824571e-016 7
15 : 8.08760874529295e-016 7
16 : 1.0849592894131e-015 7
17 : 1.49225488540852e-015 7
this value is ~ 10^22, for example:
Draw> cvalue c 0 x y z dx dy dz
Draw> dump dx dy dz
*********** Dump of dx *************
*********** Dump of dy *************
*********** Dump of dz *************
So, this estimation is quite valid.
In my opinion, it is better to treat such value of resolution by correct way in application, then modify algorithm of calculation of resolution by any way.
What is your recommendation about how to treat such value of resolution by correct way in application?
As I understand, we can trust global resolution value only for well parameterized curves. If we cannot trust to computed global resolution on some curve, we should propose the alternative approach. E.g., if we want to know which parameter on curve corresponds to the farthest point reached from the start by the vertex tolerance, then we could use the algorithm GCPnts_AbscissaPoint. Can we propose an universal solution?
And the main question remains what criteria should we check to see that resolution is wrong in a particular case?
edited on: 2015-09-24 14:55
The correct treatment of global resolution depends on given task in application, which uses global resolution. There is no universal solution. The global resolution is the lower bound of 2d tolerance along whole curve. I application needs this lower bound only, it is quite correct value. If application needs more precise estimation near point with parameter t (for example to find "real" 2d tolerance of vertex), it is better using "point" resolution ~Tol3d/|C'(t)|. As far as I know, resolution is used by EdgeEdge algo to define step along t for searching common parts of two curves. For this case it is better to set any tmin, for example tmin ~ 0.001*(l-f) and if res < tmin, then use any other algorithms to define step.
Answer on "main question":
resolution, calculated by current algorithm is never wrong, it corresponds knot distribution and other parameters of curve, it is only ~ 1/|C'max|. It only can be wrong for using in given task. The problem is that sometimes we cannot use global resolution and must use "point" resolution instead. To check this it is possible to calculate "point" resolution for some values of t and compare with global resolution. If difference is too large, it is most likely that we must use other approaches to solve given task.
Nothing to change, nothing to test, no need to create test.
Dear Eugeny, please confirm to close this bug.
Dear bugmaster, please close the issue.
|2015-07-23 14:40||emv||New Issue|
|2015-07-23 14:40||emv||Assigned To||=> msv|
|2015-07-23 14:40||emv||File Added: GeometryTest_CurveCommands.cxx|
|2015-07-23 14:40||emv||File Added: curve|
|2015-07-23 14:41||emv||Relationship added||child of 0026452|
|2015-07-23 18:15||msv||Assigned To||msv => ifv|
|2015-09-22 10:24||ifv||Note Added: 0045972|
|2015-09-22 10:24||ifv||Assigned To||ifv => msv|
|2015-09-22 10:24||ifv||Status||new => resolved|
|2015-09-22 18:38||msv||Note Edited: 0045972||View Revisions|
|2015-09-22 19:29||msv||Note Added: 0046013|
|2015-09-22 19:29||msv||Assigned To||msv => ifv|
|2015-09-22 19:29||msv||Status||resolved => feedback|
|2015-09-24 14:51||ifv||Note Added: 0046085|
|2015-09-24 14:51||ifv||Assigned To||ifv => msv|
|2015-09-24 14:51||ifv||Status||feedback => resolved|
|2015-09-24 14:55||ifv||Note Edited: 0046085||View Revisions|
|2015-09-24 15:21||msv||Note Added: 0046089|
|2015-09-24 15:21||msv||Assigned To||msv => emv|
|2015-09-24 15:21||msv||Status||resolved => reviewed|
|2015-09-24 15:21||msv||Resolution||open => no change required|
|2015-09-24 15:42||emv||Note Added: 0046090|
|2015-09-24 15:42||emv||Assigned To||emv => bugmaster|
|2015-09-24 15:42||emv||Status||reviewed => feedback|
|2015-09-24 16:48||bugmaster||Status||feedback => closed|
|Copyright © 2000 - 2020 MantisBT Team|