MantisBT
Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0026474Open CASCADE[OCCT] OCCT:Modeling Algorithmspublic2015-07-23 14:402015-09-24 16:48
Reporteremv 
Assigned Tobugmaster 
PrioritynormalSeverityminor 
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version[OCCT] 7.0.0 
Target Version[OCCT] 7.0.0Fixed in Version 
Summary0026474: Wrong computation of the resolution value
DescriptionWrong 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 Reproducerestore 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

length c
# The length c is 45.000000000010424
TagsNo tags attached.
Test case number
Attached Filescxx file icon GeometryTest_CurveCommands.cxx (53,079 bytes) 2015-07-23 14:40
? file icon curve (45,520 bytes) 2015-07-23 14:40

- Relationships
child of 0026452verifiedbugmaster Infinite loop in Edge/Edge intersection. 

-  Notes
(0045972)
ifv (developer)
2015-09-22 10:24
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[12]> cvalue c 0 x y z dx dy dz
Draw[13]> dump dx dy dz


*********** Dump of dx *************
-1.77399180322545e+021

*********** Dump of dy *************
1.02421464513816e+021

*********** Dump of dz *************
10242208341509.6

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.

(0046013)
msv (developer)
2015-09-22 19:29

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?
(0046085)
ifv (developer)
2015-09-24 14:51
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.

(0046089)
msv (developer)
2015-09-24 15:21

Nothing to change, nothing to test, no need to create test.
Dear Eugeny, please confirm to close this bug.
(0046090)
emv (developer)
2015-09-24 15:42

I confirm.
Dear bugmaster, please close the issue.

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker