Archived issue #0025971
Near B-Spline knots get merged after saving/restoring (exporting/importing)
Description
A model coming out of Shape Healing has B-Spline pcurve with knots differing in 17th position. After exporting to STEP it cannot be read back as the precision got lost and knots get fully equal and the B-Spline ctor throws an exception in CheckCurveData().
What happens is the following. The original edge lies on an original longer pcurve and has some shorter range [a,b]. b is very close to an existing B-Spline knot. Then GeomLib::SameRange() called inside FixSameParameter() converts a trimmed curve on the original B-Spline and sets a 3D curve range [A,B]. This B-Spline had a knot very near the split point and although the delta is > Epsilon(K(i)), which is checked in CheckCurveData(), after saving to a text file, the double numbers become fully collapsed.
There are different approaches to address this, for instance:
1. Make various adjustments in multiple algorithms (during import/export, ConvertToBSpline, BSplineCurve::Segment(),...)
2. Create an explicit pre-processing function (e.g. in BSplCLib) which would check and adjust knot array by moving them apart by at least Precision::PConfusion(). Such fixes are often made in IGES and STEP importers.
3. Make BSpline ctor less sensitive to merged knots and for instance have it call to the above function. In this case B-Spline ctor itself could be less sensitive to such round-off errors.
A discussion will be open on dev.opencascade.org to solicit opinions on the best course of actions.
What happens is the following. The original edge lies on an original longer pcurve and has some shorter range [a,b]. b is very close to an existing B-Spline knot. Then GeomLib::SameRange() called inside FixSameParameter() converts a trimmed curve on the original B-Spline and sets a 3D curve range [A,B]. This B-Spline had a knot very near the split point and although the delta is > Epsilon(K(i)), which is checked in CheckCurveData(), after saving to a text file, the double numbers become fully collapsed.
There are different approaches to address this, for instance:
1. Make various adjustments in multiple algorithms (during import/export, ConvertToBSpline, BSplineCurve::Segment(),...)
2. Create an explicit pre-processing function (e.g. in BSplCLib) which would check and adjust knot array by moving them apart by at least Precision::PConfusion(). Such fixes are often made in IGES and STEP importers.
3. Make BSpline ctor less sensitive to merged knots and for instance have it call to the above function. In this case B-Spline ctor itself could be less sensitive to such round-off errors.
A discussion will be open on dev.opencascade.org to solicit opinions on the best course of actions.
Steps to reproduce
restore C:/temp/a_328_1.brep a
fixshape f a 1e-6
explode f e
dump f_4
Knots :
12 : 6.28318530717959 1
13 : 6.28318530717959 4
stepwrite a f C:/temp/f.stp #inside the file there are two merged knots 6.28318530718,6.28318530718
stepread C:/temp/f.stp ff #select 1
numsh ff # no faces
tps c #Exception caught for the shell
fixshape f a 1e-6
explode f e
dump f_4
Knots :
12 : 6.28318530717959 1
13 : 6.28318530717959 4
stepwrite a f C:/temp/f.stp #inside the file there are two merged knots 6.28318530718,6.28318530718
stepread C:/temp/f.stp ff #select 1
numsh ff # no faces
tps c #Exception caught for the shell
Public activity
36 archived notes
Participants are labeled by their role within this record.
Branch [archived branch] has been created by Author.
[revision removed]
Detailed log of new commits:
Author: Author
Date: Tue Mar 24 19:25:28 2015 +0400
0025971: Near B-Spline knots get merged after saving/restoring (exporting/importing)
[revision removed]
Detailed log of new commits:
Author: Author
Date: Tue Mar 24 19:25:28 2015 +0400
0025971: Near B-Spline knots get merged after saving/restoring (exporting/importing)
Conservative fix made which only ensures sufficient delta (Precision::PConfusion()) in BSplCLib::Reparametrize().
The other likely candidate InsertKnots() left unchanged until a first case is encountered.
The fix ensures that new range really gets [U1, U2] as this may be expected by the caller algorithm (e.g. SameRange() or user's). If the delta between the last and last but one knot is less than required threshold, then iterates back trying to adjust the knot reducing their values.
The other likely candidate InsertKnots() left unchanged until a first case is encountered.
The fix ensures that new range really gets [U1, U2] as this may be expected by the caller algorithm (e.g. SameRange() or user's). If the delta between the last and last but one knot is less than required threshold, then iterates back trying to adjust the knot reducing their values.
Another candidate for alignment is ShapeConstruct_Curve::FixKnots().
Reviewed.
Dear Commenter 1,
Branch CR25971 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested.
[revision removed]
Number of compiler warnings:
occt component:
Linux: 18 (18 on master)
Windows: 0 (0 on master)
products component:
Linux: 11 (11 on master)
Windows: 4 (4 on master)
Regressions/Differences:
http://occt-tests/CR25971-master-occt-64/Debian60-64/summary.html
http://occt-tests/CR25971-master-occt-64/Windows-64-VC10/summary.html
de iges_1 P5
de step_2 B8, C9, D6, E7
de step_3 D1
Testing on Linux:
Total MEMORY difference: 88265082 / 88458413 [-0.22%]
Total CPU difference: 50133.61000000006 / 53140.31000000024 [-5.66%]
Testing on Windows:
Total MEMORY difference: 50008751 / 50016623 [-0.02%]
Total CPU difference: 14766.446256099613 / 14819.845398399693 [-0.36%]
There is difference in images found by testdiff:
http://occt-tests/CR25971-master-occt-64/Windows-64-VC10/diff-Windows-64-VC10.html
bugs vis bug24717
Branch CR25971 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested.
[revision removed]
Number of compiler warnings:
occt component:
Linux: 18 (18 on master)
Windows: 0 (0 on master)
products component:
Linux: 11 (11 on master)
Windows: 4 (4 on master)
Regressions/Differences:
http://occt-tests/CR25971-master-occt-64/Debian60-64/summary.html
http://occt-tests/CR25971-master-occt-64/Windows-64-VC10/summary.html
de iges_1 P5
de step_2 B8, C9, D6, E7
de step_3 D1
Testing on Linux:
Total MEMORY difference: 88265082 / 88458413 [-0.22%]
Total CPU difference: 50133.61000000006 / 53140.31000000024 [-5.66%]
Testing on Windows:
Total MEMORY difference: 50008751 / 50016623 [-0.02%]
Total CPU difference: 14766.446256099613 / 14819.845398399693 [-0.36%]
There is difference in images found by testdiff:
http://occt-tests/CR25971-master-occt-64/Windows-64-VC10/diff-Windows-64-VC10.html
bugs vis bug24717
Branch [archived branch] has been updated forcibly by Participant.
[revision removed]
[revision removed]
I have analyzed one of regressions, the test de iges_1 P5. With the fix, several handled exceptions occur in the method CheckCurveData. In the result, several edges are not fixed, and the nature of regression itself is different number of vertices in the resulting shape.
I have caught the problematic knots data in the fixed method BSplCLib::Reparametrize. The input array contains 10 items, with the range [0.67018055240076602,0.70588240000000002]. The requested range is U1=0.70588239799999997, U2=0.70588240000000002. We can see that the new length is equal to 2e-9. There is no room in the range to place 10 knots having distance between them greater than 1e-9. As the result, the procedure ruins the knots sequence, violating ascending order, and this later leads to exception in CheckCurveData.
One possible solution would be to restrict movement of knots after scaling, limiting shift value so that after shifting the ratio between neighboring intervals did not changed significantly. This would preserve the form of the knots sequence and even more so avoid distortion of ascending order.
However, after discussion with ABV, we came to conclusion that the overall fix could be made in another way. If the coinciding knots are created during splitting in the Segment method, it might be better to treat such cases in that code, rather than let Reparametrize distort the knots form on regular base.
Dear Roman, please let me know if you are willing to continue the fix. If so I shall send you private shape data needed to perform the regressed test.
I have caught the problematic knots data in the fixed method BSplCLib::Reparametrize. The input array contains 10 items, with the range [0.67018055240076602,0.70588240000000002]. The requested range is U1=0.70588239799999997, U2=0.70588240000000002. We can see that the new length is equal to 2e-9. There is no room in the range to place 10 knots having distance between them greater than 1e-9. As the result, the procedure ruins the knots sequence, violating ascending order, and this later leads to exception in CheckCurveData.
One possible solution would be to restrict movement of knots after scaling, limiting shift value so that after shifting the ratio between neighboring intervals did not changed significantly. This would preserve the form of the knots sequence and even more so avoid distortion of ascending order.
However, after discussion with ABV, we came to conclusion that the overall fix could be made in another way. If the coinciding knots are created during splitting in the Segment method, it might be better to treat such cases in that code, rather than let Reparametrize distort the knots form on regular base.
Dear Roman, please let me know if you are willing to continue the fix. If so I shall send you private shape data needed to perform the regressed test.
One more point is: if Segment() is called with arguments leading to creation of very small interval (<1e-9), I believe it is better to eliminate this interval instead of trying to increase it to 1e-9. This way we can avoid creation of small parametric intervals which are possible source of problems anyway.
One more point. It would be very nice to prepare a test case that was a starting point to this issue. I mean a draw script with possible shape (or better shape generated on the fly) that reproduce problem of not enough precision of import/export through a file.
Roman, I shall be very pleased if you could prepare a test case.
Roman, I shall be very pleased if you could prepare a test case.
Hi Mikhail,
Thank you for your triaging. The very start point was a customer file which I obviously cannot disclose. Anyway, the synthetic reproducer was already provided in the report and is an excerpt of one of the subshapes with similar issues. Please let me know if there is anything you might need further details on.
My efforts on fixing have been deferred and unless you want to take ownership of this bug and continue on your own, please do send me the private data, so that I or my team could resume at any moment.
Thank you for your triaging. The very start point was a customer file which I obviously cannot disclose. Anyway, the synthetic reproducer was already provided in the report and is an excerpt of one of the subshapes with similar issues. Please let me know if there is anything you might need further details on.
My efforts on fixing have been deferred and unless you want to take ownership of this bug and continue on your own, please do send me the private data, so that I or my team could resume at any moment.
Branch [archived branch] has been updated forcibly by Participant.
[revision removed]
[revision removed]
I have re-based the branch CR25971 on current master and put there the newly added test case "bugs fclasses bug25971" based on the steps to reproduce.
The test case is classified as "Bad" on master and as "Improvement" on the branch.
"Todo" lines are to be removed from the script when the solution is ready to be integrated.
The test case is classified as "Bad" on master and as "Improvement" on the branch.
"Todo" lines are to be removed from the script when the solution is ready to be integrated.
Branch [archived branch] has been created by Author.
[revision removed]
No new revisions were added by this update.
[revision removed]
No new revisions were added by this update.
Mikhail, Andrey,
A new version of the fix (possibly interim) has been pushed as CR25971_1 branch.
The status has not been upgraded to resolved yet, as I would like to try a better fix even if the current one seems to work fine.
Below are some comments:
1. I've followed your recommendation to address the issue upstream in Segment(). There was already a code that tried to stick the split point to existing knot if the distance was within epsilon. Now this epsilon was increased to at least Precision::PConfusion().
2. The fix works fine: no regression on public data and on the IGES case de iges_1 P5.
The STEP cases (
de step_3 D1
de step_2 B8, C9, D6, E7)
now contain the following differences:
(example of de step_3 D1)
Error : 3 differences with reference data found :
Reference data - NBSHAPES : Solid = 0 ( 0 ) Shell = 95 ( 106 ) Face = 95 ( 106 ) Summary = 1451 ( 1665 )
Current data - NBSHAPES : Solid = 0 ( 0 ) Shell = 106 ( 106 ) Face = 106 ( 106 ) Summary = 1665 ( 1665 )
Investigation reveals that prior to the fix there were lost entities (e.g. 11 faces, 95 vs 106) due to exact same error which the bug report 25971 is about - during loopback test, the near knots were saved in a STEP file as equal values and reading back led to exceptions (CheckCurveData() and lost entities).
Now the fix addresses this, B-Splines are different and STEP files are stored differently and can be read back.
Thus, this is an improvement, not a regression and the reference data needs to be updated.
3. The fix is currently applied to Geom2d_BSplineCurve::Segment(). Natural intent would be to apply it likewise to Geom_BSplineCurve::Segment(), however apparently these codes diverged significantly in the past. So an attempt to
synchronize them may likely lead to regressions as this is too sensitive code. Ideally, most B-Spline methods implementations should be template-based and just compile for 2D/3D cases but obviously this is a good effort in its own, and is beyond this bug report. So my course of actions will be:
- try to have a synchronized code
- run regressions tests on public data
- if fails, rollback back to current fix and just insert comments that this 2D-only fix was a deliberate choice
- if succeeds, the fix will be pushed to the repository so that you can cover the entire test suite
- if fails, rollback
- if succeeds, you integrate the entire fix.
Does that sound OK with you ?
Thank you,
Roman
A new version of the fix (possibly interim) has been pushed as CR25971_1 branch.
The status has not been upgraded to resolved yet, as I would like to try a better fix even if the current one seems to work fine.
Below are some comments:
1. I've followed your recommendation to address the issue upstream in Segment(). There was already a code that tried to stick the split point to existing knot if the distance was within epsilon. Now this epsilon was increased to at least Precision::PConfusion().
2. The fix works fine: no regression on public data and on the IGES case de iges_1 P5.
The STEP cases (
de step_3 D1
de step_2 B8, C9, D6, E7)
now contain the following differences:
(example of de step_3 D1)
Error : 3 differences with reference data found :
Reference data - NBSHAPES : Solid = 0 ( 0 ) Shell = 95 ( 106 ) Face = 95 ( 106 ) Summary = 1451 ( 1665 )
Current data - NBSHAPES : Solid = 0 ( 0 ) Shell = 106 ( 106 ) Face = 106 ( 106 ) Summary = 1665 ( 1665 )
Investigation reveals that prior to the fix there were lost entities (e.g. 11 faces, 95 vs 106) due to exact same error which the bug report 25971 is about - during loopback test, the near knots were saved in a STEP file as equal values and reading back led to exceptions (CheckCurveData() and lost entities).
Now the fix addresses this, B-Splines are different and STEP files are stored differently and can be read back.
Thus, this is an improvement, not a regression and the reference data needs to be updated.
3. The fix is currently applied to Geom2d_BSplineCurve::Segment(). Natural intent would be to apply it likewise to Geom_BSplineCurve::Segment(), however apparently these codes diverged significantly in the past. So an attempt to
synchronize them may likely lead to regressions as this is too sensitive code. Ideally, most B-Spline methods implementations should be template-based and just compile for 2D/3D cases but obviously this is a good effort in its own, and is beyond this bug report. So my course of actions will be:
- try to have a synchronized code
- run regressions tests on public data
- if fails, rollback back to current fix and just insert comments that this 2D-only fix was a deliberate choice
- if succeeds, the fix will be pushed to the repository so that you can cover the entire test suite
- if fails, rollback
- if succeeds, you integrate the entire fix.
Does that sound OK with you ?
Thank you,
Roman
For the sake of better clarity, let me add some further details on the original issue:
1. Knots of original 2D B-Spline curve:
[1] -1.5707963267949001 double
[2] -1.4279966607226364 double
...
[10] -0.28559933214452715 double
[11] -0.14279966607226346 double
[12] 2.[revision removed]-016 double
[13] 0.14279966607226369 double
....
[23] 1.5707963267949001 double
2. Edge range on this p-curve:
[-1.5707963267949001, 1.[revision removed]-015]
Eps(k12) = 2.[revision removed]-016 < |1.[revision removed]-015 - 2.[revision removed]-016|
3. Segment() is called with (-1.5707963267949001, 1.[revision removed]-015) and creates:
[1] -1.5707963267949001 double
...
[11] -0.14279966607226346 double
[12] 2.[revision removed]-016 double
[13] 1.[revision removed]-015 double
4. Reparametrize() is called with (4.7123889803846861, 6.2831853071795880) and creates:
new 12 = 6.2831853071795871
new 13 = 6.2831853071795880
Eps (new 12) = 8.[revision removed]-016, also < | 6.2831853071795880 - 6.2831853071795871|
5. Saving to text format collapses new knots 12 and 13:
6.28318530717958
6.28318530717958
6. Restoring throws an exception.
1. Knots of original 2D B-Spline curve:
[1] -1.5707963267949001 double
[2] -1.4279966607226364 double
...
[10] -0.28559933214452715 double
[11] -0.14279966607226346 double
[12] 2.[revision removed]-016 double
[13] 0.14279966607226369 double
....
[23] 1.5707963267949001 double
2. Edge range on this p-curve:
[-1.5707963267949001, 1.[revision removed]-015]
Eps(k12) = 2.[revision removed]-016 < |1.[revision removed]-015 - 2.[revision removed]-016|
3. Segment() is called with (-1.5707963267949001, 1.[revision removed]-015) and creates:
[1] -1.5707963267949001 double
...
[11] -0.14279966607226346 double
[12] 2.[revision removed]-016 double
[13] 1.[revision removed]-015 double
4. Reparametrize() is called with (4.7123889803846861, 6.2831853071795880) and creates:
new 12 = 6.2831853071795871
new 13 = 6.2831853071795880
Eps (new 12) = 8.[revision removed]-016, also < | 6.2831853071795880 - 6.2831853071795871|
5. Saving to text format collapses new knots 12 and 13:
6.28318530717958
6.28318530717958
6. Restoring throws an exception.
Roman, sorry but I have not found the new branch in the repository.
Branch [archived branch] has been created by Author.
[revision removed]
No new revisions were added by this update.
[revision removed]
No new revisions were added by this update.
Branch [archived branch] has been updated by Author.
[revision removed]
Detailed log of new commits:
Author: Author
Date: Fri Apr 17 15:31:32 2015 +0400
0025971: Near B-Spline knots get merged after saving/restoring (exporting/importing)
[revision removed]
Detailed log of new commits:
Author: Author
Date: Fri Apr 17 15:31:32 2015 +0400
0025971: Near B-Spline knots get merged after saving/restoring (exporting/importing)
Unfortunately the attempt to align implementations did not work out - regressions showed up even after an attempt to redesign the 2D case (see enclosed excerpt for Geom2d_BSplineCurve::Segment()). Using the same code for 3D case produced even greater number of regressions.
So the only feasible action at this moment could be to accept the prior fix (in CR25971_1 branch). And at some point in time to allocate a project to align implementations of 2D/3D curve and Geom_BSplineSurface() investigating regressions.
So the only feasible action at this moment could be to accept the prior fix (in CR25971_1 branch). And at some point in time to allocate a project to align implementations of 2D/3D curve and Geom_BSplineSurface() investigating regressions.
Dear Roman,
I did not understand the nature of your trials in 3D case. Did you tried just the same patch as for 2D? Like the below patch:
diff --git a/src/Geom/Geom_BSplineCurve.cxx b/src/Geom/Geom_BSplineCurve.cxx
index 01a3a06..2c9de2a 100644
--- a/src/Geom/Geom_BSplineCurve.cxx
+++ b/src/Geom/Geom_BSplineCurve.cxx
@@ -35,6 +35,7 @@
#include <BSplCLib.hxx>
#include <BSplCLib_KnotDistribution.hxx>
#include <BSplCLib_MultDistribution.hxx>
+#include <Precision.hxx>
#include <Standard_NotImplemented.hxx>
#include <Standard_ConstructionError.hxx>
#include <Standard_OutOfRange.hxx>
@@ -570,7 +571,7 @@ void Geom_BSplineCurve::Segment(const Standard_Real U1,
AbsUMax = Max(AbsUMax, Max(Abs(FirstParameter()),Abs(LastParameter())));
// Modified by Sergey KHROMOV - Fri Apr 11 12:15:40 2003 End
- Standard_Real Eps = 100. * Epsilon(AbsUMax);
+ Standard_Real Eps = Max (Epsilon(AbsUMax), Precision::PConfusion());
InsertKnots( Knots, Mults, Eps);
If not, then I would propose to insert this fix to the branch for testing.
I did not understand the nature of your trials in 3D case. Did you tried just the same patch as for 2D? Like the below patch:
diff --git a/src/Geom/Geom_BSplineCurve.cxx b/src/Geom/Geom_BSplineCurve.cxx
index 01a3a06..2c9de2a 100644
--- a/src/Geom/Geom_BSplineCurve.cxx
+++ b/src/Geom/Geom_BSplineCurve.cxx
@@ -35,6 +35,7 @@
#include <BSplCLib.hxx>
#include <BSplCLib_KnotDistribution.hxx>
#include <BSplCLib_MultDistribution.hxx>
+#include <Precision.hxx>
#include <Standard_NotImplemented.hxx>
#include <Standard_ConstructionError.hxx>
#include <Standard_OutOfRange.hxx>
@@ -570,7 +571,7 @@ void Geom_BSplineCurve::Segment(const Standard_Real U1,
AbsUMax = Max(AbsUMax, Max(Abs(FirstParameter()),Abs(LastParameter())));
// Modified by Sergey KHROMOV - Fri Apr 11 12:15:40 2003 End
- Standard_Real Eps = 100. * Epsilon(AbsUMax);
+ Standard_Real Eps = Max (Epsilon(AbsUMax), Precision::PConfusion());
InsertKnots( Knots, Mults, Eps);
If not, then I would propose to insert this fix to the branch for testing.
Also, the similar simple change can be done in surface methods:
Geom_BSplineSurface::Segment
Geom_BSplineSurface::CheckAndSegment
Geom_BSplineSurface::Segment
Geom_BSplineSurface::CheckAndSegment
Branch [archived branch] has been updated by Participant.
[revision removed]
Detailed log of new commits:
Author: Author
Date: Fri Apr 17 15:31:32 2015 +0400
0025971: Near B-Spline knots get merged after saving/restoring (exporting/importing)
Precision used to consider B-Spline knots identical is restricted to be not less than Precision::PConfusion() in Geom2d_BSplineCurve::Segment().
Affected tests updated (improvements)
[revision removed]
Detailed log of new commits:
Author: Author
Date: Fri Apr 17 15:31:32 2015 +0400
0025971: Near B-Spline knots get merged after saving/restoring (exporting/importing)
Precision used to consider B-Spline knots identical is restricted to be not less than Precision::PConfusion() in Geom2d_BSplineCurve::Segment().
Affected tests updated (improvements)
I have pushed the fix rebased on current master and with corrected test cases to branch CR25971_2
Reviewed, please test
Hello Mikhail, Andrey,
Thank you for your support in moving this forward.
I ran out of cycles and won't have any free ones to continue with this any time soon :-(.
Just for the record, here is what was my course of actions:
1. Tried the 2D-only fix as in the branch CR25971_1 on public and private set - OK.
2. Tried to have a better 2D case - the one which was attached to this bug report - fail.
The need for this reworked/simplified patch is that current code in Geom2d_BSplineCurve::Segment()
is prone to issues - the loop analyzing the distance between existing knots and parameters and
comparing with aEps may choose a wrong far distant knot. For instance:
ki-1, ki, ki+1, ki+2 - all distances < 1e-9
insert U in [ki-1,ki]
the loop will stick U to ki+2, not to ki-1.
Therefore an attempt was to first find an interval for U (via LocateParameter() which itself should
simply call BSplCLib::Hunt() and adjust to ki if U=ki) and then stick to left or right.
3. #0000002 adjusted for Geom_BSplineCurve::Segment() - fail
4. Geom_BSplineSurface::Segment() was in the middle of refactoring (trying to use logic of #0000002) when
all those regressions started to show up.
So in general this rather seems as a significant dedicated effort to align implementations and to
enforce maximum possible code reuse instead of duplication and divergence. You might want to fork
a dedicated feature request as a follow up of this bug report.
Looking forward to getting the complete test run results.
Roman
Thank you for your support in moving this forward.
I ran out of cycles and won't have any free ones to continue with this any time soon :-(.
Just for the record, here is what was my course of actions:
1. Tried the 2D-only fix as in the branch CR25971_1 on public and private set - OK.
2. Tried to have a better 2D case - the one which was attached to this bug report - fail.
The need for this reworked/simplified patch is that current code in Geom2d_BSplineCurve::Segment()
is prone to issues - the loop analyzing the distance between existing knots and parameters and
comparing with aEps may choose a wrong far distant knot. For instance:
ki-1, ki, ki+1, ki+2 - all distances < 1e-9
insert U in [ki-1,ki]
the loop will stick U to ki+2, not to ki-1.
Therefore an attempt was to first find an interval for U (via LocateParameter() which itself should
simply call BSplCLib::Hunt() and adjust to ki if U=ki) and then stick to left or right.
3. #0000002 adjusted for Geom_BSplineCurve::Segment() - fail
4. Geom_BSplineSurface::Segment() was in the middle of refactoring (trying to use logic of #0000002) when
all those regressions started to show up.
So in general this rather seems as a significant dedicated effort to align implementations and to
enforce maximum possible code reuse instead of duplication and divergence. You might want to fork
a dedicated feature request as a follow up of this bug report.
Looking forward to getting the complete test run results.
Roman
If we decide to make the same patch for 3d curve and surface, the following info can be useful.
I have run all tests and got the following 3 regressions:
CASE boolean bcut_complex N6: FAILED (bad shape)
CASE boolean bopfuse_complex E5: FAILED (bad shape)
CASE bugs modalg_5 bug24746: FAILED (error)
I have run all tests and got the following 3 regressions:
CASE boolean bcut_complex N6: FAILED (bad shape)
CASE boolean bopfuse_complex E5: FAILED (bad shape)
CASE bugs modalg_5 bug24746: FAILED (error)
I have uploaded the patch mentioned above as the file Attachment 1 (PATCH).
Dear Commenter 1,
Branch CR25971_2 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested on Release mode.
[revision removed]
Number of compiler warnings:
occt component :
Linux: 18 (18 on master)
Windows: 0 (0 on master)
products component :
Linux: 4 (4 on master)
Windows: 0 (0 on master)
Regressions/Differences:
No regressions/differences
Testing cases:
http://occt-tests/CR25971-2-master-occt-64/Debian60-64/bugs/moddata_3/bug25971.html
http://occt-tests/CR25971-2-master-occt-64/Windows-64-VC10/bugs/moddata_3/bug25971.html
bugs moddata_3(014) bug25971: OK
Testing on Linux:
occt component :
Total MEMORY difference: 95185562 / 94542797 [+0.68%]
Total CPU difference: 53319.87999999919 / 52220.829999999456 [+2.10%]
products component :
Total MEMORY difference: 23733009 / 23676267 [+0.24%]
Total CPU difference: 17536.789999999975 / 17777.469999999976 [-1.35%]
Testing on Windows:
occt component :
Total MEMORY difference: 57139226 / 57149644 [-0.02%]
Total CPU difference: 15989.244494498982 / 16281.184765899072 [-1.79%]
products component :
Total MEMORY difference: 15561089 / 15564896 [-0.02%]
Total CPU difference: 6400.034625599986 / 6585.207812599981 [-2.81%]
There are following differences in images found by testdiff.
http://occt-tests/CR25971-2-master-occt-64/Debian60-64/diff-Debian60-64.html
http://occt-tests/CR25971-2-master-occt-64/Windows-64-VC10/diff-Windows-64-VC10.html
IMAGE de step_2 C9: C9.png differs
IMAGE de step_3 D1: D1.png differs
Branch CR25971_2 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested on Release mode.
[revision removed]
Number of compiler warnings:
occt component :
Linux: 18 (18 on master)
Windows: 0 (0 on master)
products component :
Linux: 4 (4 on master)
Windows: 0 (0 on master)
Regressions/Differences:
No regressions/differences
Testing cases:
http://occt-tests/CR25971-2-master-occt-64/Debian60-64/bugs/moddata_3/bug25971.html
http://occt-tests/CR25971-2-master-occt-64/Windows-64-VC10/bugs/moddata_3/bug25971.html
bugs moddata_3(014) bug25971: OK
Testing on Linux:
occt component :
Total MEMORY difference: 95185562 / 94542797 [+0.68%]
Total CPU difference: 53319.87999999919 / 52220.829999999456 [+2.10%]
products component :
Total MEMORY difference: 23733009 / 23676267 [+0.24%]
Total CPU difference: 17536.789999999975 / 17777.469999999976 [-1.35%]
Testing on Windows:
occt component :
Total MEMORY difference: 57139226 / 57149644 [-0.02%]
Total CPU difference: 15989.244494498982 / 16281.184765899072 [-1.79%]
products component :
Total MEMORY difference: 15561089 / 15564896 [-0.02%]
Total CPU difference: 6400.034625599986 / 6585.207812599981 [-2.81%]
There are following differences in images found by testdiff.
http://occt-tests/CR25971-2-master-occt-64/Debian60-64/diff-Debian60-64.html
http://occt-tests/CR25971-2-master-occt-64/Windows-64-VC10/diff-Windows-64-VC10.html
IMAGE de step_2 C9: C9.png differs
IMAGE de step_3 D1: D1.png differs
Branch [archived branch] has been updated by Participant.
[revision removed]
Detailed log of new commits:
Author: mkv
Date: Thu Apr 23 19:07:00 2015 +0300
Test case for issue CR25971
[revision removed]
Detailed log of new commits:
Author: mkv
Date: Thu Apr 23 19:07:00 2015 +0300
Test case for issue CR25971
Dear msv,
could you please review following test case
bugs moddata_3(014) bug25971
This test case is OK on current master also.
could you please review following test case
bugs moddata_3(014) bug25971
This test case is OK on current master also.
Test case is OK. Really, in current master the test is OK also. It might be due to some recent changes.
Anyway, please integrate this test as it is.
Anyway, please integrate this test as it is.
Dear Commenter 1,
Branch CR25971_2 is TESTED.
Branch CR25971_2 is TESTED.
Branch [archived branch] has been deleted by Participant.
[revision removed]
[revision removed]
Branch [archived branch] has been deleted by Participant.
[revision removed]
[revision removed]
Branch [archived branch] has been deleted by Participant.
[revision removed]
[revision removed]
Related records