View Issue Details

IDProjectCategoryView StatusLast Update
0026474Open CASCADEOCCT:Modeling Algorithmspublic2015-09-24 16:48
ReporteremvAssigned Tobugmaster  
PrioritynormalSeverityminor 
Status closedResolutionno change required 
Product Version7.0.0 
Target Version7.0.0 
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 Files

  • GeometryTest_CurveCommands.cxx (53,079 bytes)
  • curve (45,520 bytes)

Relationships

child of 0026452 closedbugmaster Infinite loop in Edge/Edge intersection. 

Activities

emv

2015-07-23 14:40

developer  

GeometryTest_CurveCommands.cxx (53,079 bytes)

emv

2015-07-23 14:40

developer  

curve (45,520 bytes)

ifv

2015-09-22 10:24

developer   ~0045972

Last edited: 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.

msv

2015-09-22 19:29

developer   ~0046013

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?

ifv

2015-09-24 14:51

developer   ~0046085

Last edited: 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.

msv

2015-09-24 15:21

developer   ~0046089

Nothing to change, nothing to test, no need to create test.
Dear Eugeny, please confirm to close this bug.

emv

2015-09-24 15:42

developer   ~0046090

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
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
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