View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0030990||Community||OCCT:Foundation Classes||public||2019-09-21 10:29||2020-07-23 12:43|
|Target Version||7.4.0||Fixed in Version||7.4.0|
|Summary||0030990: Foundation Classes - unexpected change in numerical results on bsplines after #29769|
|Description||The problem has been reported by Benjamin Bihler in comments to 0029769, see 0029769:0081087 and further for details.|
|Steps To Reproduce||test bugs fclasses bug30990|
|Tags||No tags attached.|
|Test case number|
bug30990.brep (67,839 bytes)
CR30990.zip (49,050 bytes)
Branch CR30990 has been created by abv.
Detailed log of new commits:
Date: Sat Sep 21 19:24:55 2019 +0300
0030990: Foundation Classes - unexpected change in numerical results on bsplines after 0029769
Added reproducer (DRAW command) and test case
||Differences are caused by changes in implementation of cache of surfaces; changes in cache of curves does not affect the results of the test command.|
The difference is explained by more consistent work of BSpline cache for surfaces after integration of patch for 0029769 (in current master, 7.4.0) as compared to previous state (7.3.0).
I have prepared two patches for investigation of this issue, running the reproducer test case and printing out details on how b-spline evaluation is performed:
- 0001-0030990-pre29769.patch and log_pre29769_ext.txt - patch for commit prior to 0029769 on master, and output produced by running the test case
- 0001-0030990-post29769.patch and log_post29769_ext.txt - patch for commit 0029769 on master, and output produced by running the test case
The comparison of the output shows that on version before 0029769 B-Spline surface cache sometimes does not get updated for points located exactly at knots, and sometimes gets updated unnecessarily (when span index remains the same after update). Version after 0029769 does not exhibit such problems. At the points where the cache is not updated when it should, b-spline gets evaluated using coefficients of neighbour span, which results in deviations from correct value (the deviations are due to different numerical roundings and thus negligible, yet they are the very subject of the original complaint).
The main purpose of the class BSplSLib_Cache is optimization of evaluation of b-spline surfaces by avoiding unnecessary updates of spline coefficients when several points are evaluated in the same spline span. For that BSplSLib_Cache stores the spline coefficients for the last evaluated span, and range of that span (by U and V). Before evaluation of a point, it checks whether it is located on the same span as already cached, and updates cache only when the point is on different span.
The point is considered to be within i-th span if its parameter is within limits [Start=Knot(i), End=Knot(i+1)) where Knot(i) is i-th knot of the b-spline. Note that range includes start knot but not includes end knot. That is, if parameter is equal to knot, the point is evaluated using span that starts at that knot. This behavior is the same for curves and surfaces, and is implemented in BSplCLib::LocateParameter().
BSpline cache has to update span coefficients when point gets into the span different from the current one, and for that the parameter (for surface, for both U and V) P is compared against the range of the current span (see method BSplSLib_Cache::IsCacheValid()).
Formally this comparison is consistent with BSplCLib::LocateParameter() in both OCCT 7.3.0 and current master. However, cache for surfaces (BSplSLib_Cache) in 7.3.0 does not store original span range, instead it stores mid-point of the range and its half length. When check for parameter to be in range is performed, actual range is recovered from stored values, and apparently these calculations may lead to loss of precision. The result is that for parameter equal to the end of the range of the current span that method sometimes returns True. The point is then evaluated using spline coefficients of the previous span.
Within 0029769, this logic has been extracted to separate class BSplCLib_LocateParameter and is now the same for curves and surfaces. Now start of the range is stored as-is (while still the length of the span is stored instead of the end of the range). Even if the latter may potentially lead to similar issues as described above, current implementation is found to be much more stable and shows no errors on the tested cases.
0001-0030990-pre29769.patch (45,289 bytes)
log_pre29769_ext.txt (223,480 bytes)
0001-0030990-post29769.patch (17,081 bytes)
log_post29769_ext.txt (219,144 bytes)
Branch CR30990 has been updated forcibly by abv.
||I have pushed a branch CR30990 containing a test case for reproducing the problem with update of the b-spline cache. It evaluates B-SPline surface by computing points at U and V located exactly at b-spline knots, after evaluation of points inside the spans before and after the knot, and checks that result at the knot is exactly the same regardless of previous evaluation (i.e. the cache is updated as necessary). The test is OK on master while gives 22 errors on version before 0029769. Please review.|
||No objections from my side and no worries anymore. The seeming deterioration of program behaviour was just a phantom. Thank you for your investigations.|
||New test is OK on current master on both Windows and Linux: see Jenkins job CR30990-abv. Please integrate|
OCCT branch : CR30990
master SHA - 42027f4e33e4d81937edc8c2dff9d5b328bae7ef
Products branch : master SHA - cede13b0d79b1c3448ecd68f0db85c2a087762ad
was compiled on Linux, MacOS and Windows platforms and tested in optimize mode.
Number of compiler warnings:
No new/fixed warnings
Total CPU difference: 16834.18000000005 / 16808.79000000008 [+0.15%]
Total CPU difference: 10551.000000000033 / 10561.440000000042 [-0.10%]
Total CPU difference: 18245.234375 / 18298.78125 [-0.29%]
Total CPU difference: 12465.265625 / 12507.671875 [-0.34%]
Image differences :
No differences that require special attention
Memory differences :
No differences that require special attention
Branch CR30990 has been deleted by inv.
occt: master 0a5ec5f3
Committer: bugmaster Details Diff
|0030990: Foundation Classes - unexpected change in numerical results on bsplines after 0029769
Added DRAW command and test case for detection of inconsistent update of B-Spline surface cache
|mod - src/QABugs/QABugs_20.cxx||Diff File|
|add - tests/bugs/fclasses/bug30990||Diff File|
|2019-09-21 10:29||abv||New Issue|
|2019-09-21 10:29||abv||Assigned To||=> abv|
|2019-09-21 10:29||abv||Relationship added||child of 0029769|
|2019-09-21 10:30||abv||Status||new => assigned|
|2019-09-21 10:30||abv||Target Version||7.5.0 => 7.4.0|
|2019-09-21 10:30||abv||Description Updated|
|2019-09-21 10:34||abv||File Added: bug30990.brep|
|2019-09-21 10:36||abv||File Added: CR30990.zip|
|2019-09-21 19:28||git||Note Added: 0087393|
|2019-09-21 21:31||abv||Note Added: 0087397|
|2019-09-23 08:17||abv||Note Added: 0087433|
|2019-09-23 08:18||abv||File Added: 0001-0030990-pre29769.patch|
|2019-09-23 08:18||abv||File Added: log_pre29769_ext.txt|
|2019-09-23 08:18||abv||File Added: 0001-0030990-post29769.patch|
|2019-09-23 08:18||abv||File Added: log_post29769_ext.txt|
|2019-09-23 08:20||git||Note Added: 0087434|
|2019-09-23 08:27||abv||Note Added: 0087435|
|2019-09-23 08:27||abv||Assigned To||abv => BenjaminBihler|
|2019-09-23 08:27||abv||Status||assigned => resolved|
|2019-09-23 08:27||abv||Steps to Reproduce Updated|
|2019-09-23 11:36||BenjaminBihler||Note Added: 0087445|
|2019-09-23 11:37||BenjaminBihler||Assigned To||BenjaminBihler => abv|
|2019-09-24 13:52||abv||Note Added: 0087474|
|2019-09-24 13:52||abv||Assigned To||abv => bugmaster|
|2019-09-24 13:52||abv||Status||resolved => reviewed|
|2019-09-24 14:18||bugmaster||Note Added: 0087477|
|2019-09-24 14:18||bugmaster||Status||reviewed => tested|
|2019-09-29 12:19||bugmaster||Changeset attached||=> occt master 0a5ec5f3|
|2019-09-29 12:19||bugmaster||Status||tested => verified|
|2019-09-29 12:19||bugmaster||Resolution||open => fixed|
|2019-09-29 12:36||git||Note Added: 0087626|