MantisBT
Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Related Changesets ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0027896Open CASCADE[OCCT] OCCT:Modeling Algorithmspublic2016-09-22 16:422016-12-09 16:39
Reporternbv 
Assigned Toapn 
PriorityhighSeverityminor 
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version[OCCT] Unscheduled 
Target Version[OCCT] 7.1.0Fixed in Version[OCCT] 7.1.0 
Summary0027896: Prm-Prm intersection algo returns wrong result if it is called with start intersection point, which lies in the domain boundary
DescriptionTest bugs modalg_5 bug25319_1(2).

    Draw[]> explode b1 f
    Draw[]> explode b2 f
    Draw[]> don b1_8 b2_17

Without any start point

    Draw[]> bopcurves b1_8 b2_17 -2d
# Tolerance Reached=2.4122298283916123e-006 ==> OK

With start point:

    Draw[]> bopcurves b1_8 b2_17 -2d -p +1.09444207768950010000 +29.00000000000000000000 +0.17740001678466785000 +2.79671571032639710000 -p +0.00000000000000000000 +26.87779254288926400000 +0.17767342824312710000 +2.80622040022304510000

# Tolerance Reached=2.2611960020325053e-007 ==> OK

However, small shifting the start point (by the distance < 1.0e-13):

    Draw[]> bopcurves b1_8 b2_17 -2d -p +1.09444207768949960000 +29.00000000000000000000 +0.17740001678466785000 +2.79671571032639750000 -p +0.00000000000000000000 +26.87779254288926400000 +0.17767342824312710000 +2.80622040022304510000

# Tolerance Reached=0.015634546636864411 ==> WRONG.

Additional information:

1. In both cases initial points are true intersection points (it has been checked with computation of distances).

2. In both (!) cases one initial point is ON UV-bounds of the intersected face. However, behavior of intersection algorithm is slight different.

3. If we extend UV-bounds of the face by 1.0e-7 (in order to be for initial point IN the domain (not ON) then intersection result will be OK.
Steps To ReproduceTest bugs modalg_5 bug25319_1(2).

explode b1 f
explode b2 f
don b1_8 b2_17
bopcurves b1_8 b2_17 -2d -p +1.09444207768949960000 +29.00000000000000000000 +0.17740001678466785000 +2.79671571032639750000 -p +0.00000000000000000000 +26.87779254288926400000 +0.17767342824312710000 +2.80622040022304510000
TagsNo tags attached.
Test case numberbugs modalg_6 bug27896
Attached Files

- Relationships
child of 0027895closedapn Open CASCADE Correction in the constructor Extrema_ExtElC::Extrema_ExtElC (const gp_Lin&,const gp_Lin&,const Standard_Real) 

-  Notes
(0058994)
nbv (developer)
2016-10-24 10:48

After fixing the issue #0027441, described problem will lead to regression in bugs modalg_5 bug25319_1(2) test cases. Result shape has become invalid in terms of BRepCheck algorithm (BRepCheck_NotClosed).

There is the gap (in 2D-space) even on the current MASTER. However, it is covered by big vertex tolerance. In the FIX #27441, the vertex tolerance is significantly less than on the MASTER (because the vertex parameter is computed correctly). As result, on the fix, new vertex tolerance does not cover the gap.

There is not any gap(s) on OCCT 7.0.0 version. It has appeared after the fix for issue 0027895. The reason is written in bug description: big edge tolerance leads to the edge be shared with existing one, i.e. to be rejected (the gap is produced).
(0059689)
nbv (developer)
2016-11-01 14:14

As it has been said in the message 0027896:0058994, this bug blocks integration of the issue #27441. Therefore, I increase its importance.
(0059692)
git (administrator)
2016-11-01 14:42

Branch CR27896 has been created by nbv.

SHA-1: 1780360d157f2063ce6ab17440e42ed6957b0578


Detailed log of new commits:

Author: nbv
Date: Fri Oct 28 09:37:38 2016 +0300

    0027896: Prm-Prm intersection algo returns wrong result if it is called with start intersection point, which lies in the domain boundary
    
    Purger has been disabled (in IntPatch_PrmPrmIntersection algorithm) if some points have been added in the Walking line (it is stupidly, first, to insert some points in the line and, after that, to delete points from this line).
    
    Some improvements in IntWalk_PWalking::SeekPointOnBoundary(...) method have been made (see comments in the code for detail information).
    
    Some test cases have been adjusted according to their new behavior.

Author: nbv
Date: Thu Oct 27 19:16:40 2016 +0300

    Small correction in the test case

Author: nbv
Date: Thu Jun 23 17:42:55 2016 +0300

    0027431: [Regression to 6.9.1] Huge tolerance obtained during intersection of cylinder and sphere
    
    The root of the problem is incorrect processing of cases when intersection line goes through the apex(es) of sphere. The fix improves this situation. The algorithm is taken from DecomposeResult(...) function (see IntPatch_ImpPrmIntersection.cxx file). Before the fix, faltering steps were done to solve this problem. As result, it worked in some particular cases. Now, its possibilities have been extended significantly.
    
    Following changes have been made in the fix:
    
    1. Class IntPatch_ALineToWLine has been rewritten cardinally. It touches as interfaces of existing methods as adding/removing some methods/fields. Correction touches both cases: going through seam of Cone/Sphere and through pole(s) of sphere. Old interface did not allow making some actions with analytical line (ALine), e.g. splitting it on several Walking-lines (WLine).
    
    2. Restriction-line support has been removed from Implicit-Implicit intersection result (see IntPatch_Intersection::GeomGeomPerfom(...) method). It connects with the fact that the intersection algorithm itself returns precise intersection line in analytical cases (in compare with parametric intersector). Therefore, we do not need in additional (restriction) line.
    
    3. New class IntPatch_SpecialPoints has been added. This class contains methods to add some special points (such as apex of cone, pole of sphere, point on surface boundary etc.) in intersection line (IntPatch_PointLine). It is based on the static functions, which already exist in IntPatch_ImpPrmIntersection.cxx file (these functions have been moved to the new class).
    
    4. Method IntPatch_WLineTool::ExtendTwoWlinesToEachOther(...) has been renamed to IntPatch_WLineTool::ExtendTwoWLines(...). It is connected with changing main idea of the method. Now it allows extending WLine to the surface boundary or to the singular point (if it is possible): cone apex, sphere pole etc. Interface of this method has been corrected, too. At that, old functionality (extending to each other) has been kept. For implementation of this algorithm, new enumeration "IntPatchWT_WLsConnectionType" has been created.
    
    5. Method IntPatch_PointLine::CurvatureRadiusOfIntersLine(...) has been added. See IntPatch_PointLine.hxx for detail information. It allows correct step computing depended on the local curvature of the intersection line. This method uses geometrical properties of intersected surfaces to compute local curvature. Therefore, it can be applied in wide range of cases even if the intersection curve is not represented in explicit form (e.g. in case of param-param-intersection).
    
    6. Method IntSurf::SetPeriod(...) has been created.
    
    7. Additional check has been added in Draft_Modification::Perform() method for better choice of correct fragment of intersection line for processing DRAFT operation.
    
    8. New overload method IntPatch_Point::SetValue() has been added.
    
    9. Some refactoring of the code has been made.
    
    Creation of test case for issue #27431.
    
    ---------------------------------------------------------------------------------------------
    Some test cases have been adjusted according to their new behavior.
    
       tests\bugs\modalg_4\bug62
    It is really IMPROVEMENT (but fortuitous).
    
       tests\bugs\modalg_5\bug25838
    The behavior of this test has been reverted to the state before fixing the issue #27341. Main problem has not been fixed in #27341. It was fortuitous improvement.
    
        tests\bugs\moddata_2\bug565
    Quality of intersection curve was not checked. And the curve is bad on both MASTER and FIX. Input data are really wrong: plane-like-cone. However, on the MASTER, four intersection curves (the quality is insignificant) are expected. On the fix, not empty intersection result is expected simply.
    
       tests\boolean\volumemaker\A8
    Differences in images and CPU is expected. Difference in images is expected to be fixed in the issue #26020. Now, we should apply this behavior.
    Much CPU time is spent by IntTools_FaceFace::ComputeTolReached3d(...) and GeomInt_IntSS::BuildPCurves(...) methods calling. These methods are not touched by the algorithm. It is the result of change of intersection curve(s) form. However, the new Curve(s) seems to be valid and can be applied. As result, new behavior can be applied, too.
    
       tests\boolean\volumemaker\F8
       tests\boolean\volumemaker\F9
       tests\boolean\volumemaker\G5
       tests\boolean\volumemaker\G6
    CPU difference is expected. Much CPU time is spent by IntPatch_PointLine::CurvatureRadiusOfIntersLine(...) method calling. This method is really new (it does not exist on the MASTER) and is really useful. Therefore, we should apply new behavior.
    
       tests\boolean\volumemaker\G1
    CPU difference is expected. Much CPU time is spent by IntTools_WLineTool::DecompositionOfWLine(...) and IntTools_FaceFace::ComputeTolReached3d(...) methods calling. These methods are not touched by the algorithm. It is the result of change of intersection curve(s) form. However, the new Curve(s) seems to be valid and can be applied. As result, new behavior can be applied, too.
    
       tests\bugs\modalg_6\bug26619
    Differences in images is expected. The test keeps its BAD status on the FIX. But the result on the fix is nearer to expected than on the MASTER. Issue #27014 is still actual. As before, it is not clear, why the number of entities is different. The number of section curves has not been changed. Interfered entities are the same as on the MASTER.
    
       tests\bugs\modalg_5\bug25319_1(2)
    The reason is described in the issue 0027896.

Author: emv
Date: Wed Apr 27 16:28:52 2016 +0300

    0027441: The method IntTools_Context::IsVertexOnLine incorrectly computes parameter of the point on the curve
    
    Choosing the closest bound to the checking point.
(0059694)
nbv (developer)
2016-11-01 14:55

Dear Mikhail,

Please review the branch CR27896.

Please pay attention to the fact that it is rebased on CR27431_5 branch because the real regression will be obtained after the fix #27441.

So, this fix (0027896) should be tested with CR27431_prod branch (from products git-repository). More over, results and explanations given in the messages 0027431:0059658 and below are actual for this fix.
(0059715)
msv (developer)
2016-11-01 17:14

Reviewed.
Please test CR27896 in occt and CR27431_prod in occt-products.
(0059716)
git (administrator)
2016-11-01 17:16

Branch CR27896 has been updated by nbv.

SHA-1: 79fa1657ccb3257d56dbf4b03bb1dc44329e9052


Detailed log of new commits:

Author: nbv
Date: Tue Nov 1 17:00:11 2016 +0300

    Correction according to the last remark

(0059798)
mkv (tester)
2016-11-02 17:20
edited on: 2016-11-02 17:20

Dear nbv,
could you please rebase branch CR27896 on IR-2016-11-02, there are conflict files.
SHA-1: 79fa1657ccb3257d56dbf4b03bb1dc44329e9052

(0059802)
git (administrator)
2016-11-02 17:37

Branch CR27896_1 has been created by nbv.

SHA-1: c78fb35648f525cb2b4b67b1b53994313fb92181


Detailed log of new commits:

Author: nbv
Date: Fri Oct 28 09:37:38 2016 +0300

    0027896: Prm-Prm intersection algo returns wrong result if it is called with start intersection point, which lies in the domain boundary
    
    Purger has been disabled (in IntPatch_PrmPrmIntersection algorithm) if some points have been added in the Walking line (it is stupidly, first, to insert some points in the line and, after that, to delete points from this line).
    
    Some improvements in IntWalk_PWalking::SeekPointOnBoundary(...) method have been made (see comments in the code for detail information).
    
    Some test cases have been adjusted according to their new behavior.
(0059803)
nbv (developer)
2016-11-02 17:38
edited on: 2016-11-02 17:38

Done.

Please test CR27896_1 branch.

(0059863)
mkv (tester)
2016-11-03 16:48

Dear BugMaster,
Branch CR27896_1 was rebased on IR-2016-11-02 of occt git-repository.
SHA-1: c78fb35648f525cb2b4b67b1b53994313fb92181
(0059864)
mkv (tester)
2016-11-03 16:49

Dear BugMaster,
Branch CR27896_1 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested on Release mode.
SHA-1: c78fb35648f525cb2b4b67b1b53994313fb92181

Number of compiler warnings:

occt component :
Linux: 0 (0 on master)
Windows: 0 (0 on master)
MacOS : 0 (0 on master)

products component :
Linux: 63 (63 on master)
Windows: 0 (0 on master)
MacOS : 1121

Regressions/Differences/Improvements:
No regressions/differences

Testing cases:
http://occt-tests/CR27896_1-master-OCCT/Debian70-64/bugs/modalg_6/bug27896.html [^]
http://occt-tests/CR27896_1-master-OCCT/Windows-64-VC10/bugs/modalg_6/bug27896.html [^]
bugs modalg_6 bug27896: OK

Testing on Linux:
occt component :
Total MEMORY difference: 90830898 / 91227129 [-0.43%]
Total CPU difference: 19338.359999999844 / 19512.96000000008 [-0.89%]
products component :
Total MEMORY difference: 30463448 / 30478667 [-0.05%]
Total CPU difference: 5185.969999999971 / 5176.759999999966 [+0.18%]

Testing on Windows:
occt component :
Total MEMORY difference: 57448030 / 57451773 [-0.01%]
Total CPU difference: 18474.855227798602 / 17672.82288659874 [+4.54%]
products component :
Total MEMORY difference: 21510364 / 21473188 [+0.17%]
Total CPU difference: 5270.712186399966 / 5107.691141399945 [+3.19%]

There are no differences in images found by testdiff.
(0059865)
mkv (tester)
2016-11-03 16:49

Dear BugMaster,
Branch CR27896_1 is TESTED.
(0061204)
git (administrator)
2016-12-07 11:25

Branch CR27896 has been deleted by kgv.

SHA-1: 79fa1657ccb3257d56dbf4b03bb1dc44329e9052
(0061205)
git (administrator)
2016-12-07 11:25

Branch CR27896_1 has been deleted by kgv.

SHA-1: c78fb35648f525cb2b4b67b1b53994313fb92181

- Related Changesets
occt: master f73c584c
Timestamp: 2016-10-28 06:37:38
Author: nbv
Committer: apn
Details ] Diff ]
0027896: Prm-Prm intersection algo returns wrong result if it is called with start intersection point, which lies in the domain boundary

Purger has been disabled (in IntPatch_PrmPrmIntersection algorithm) if some points have been added in the Walking line (it is stupidly, first, to insert some points in the line and, after that, to delete points from this line).

Some improvements in IntWalk_PWalking::SeekPointOnBoundary(...) method have been made (see comments in the code for detail information).

Some test cases have been adjusted according to their new behavior.
mod - src/Draft/Draft_Modification_1.cxx Diff ] File ]
mod - src/IntPatch/IntPatch_ImpPrmIntersection.cxx Diff ] File ]
mod - src/IntPatch/IntPatch_PrmPrmIntersection.cxx Diff ] File ]
mod - src/IntPatch/IntPatch_WLine.cxx Diff ] File ]
mod - src/IntWalk/IntWalk_PWalking.cxx Diff ] File ]
mod - src/IntWalk/IntWalk_PWalking.hxx Diff ] File ]
mod - tests/bugs/modalg_5/bug24585_1 Diff ] File ]
mod - tests/bugs/modalg_5/bug25319_1 Diff ] File ]
mod - tests/bugs/modalg_5/bug25319_2 Diff ] File ]
add - tests/bugs/modalg_6/bug27896 Diff ] File ]

- Issue History
Date Modified Username Field Change
2016-09-22 16:42 nbv New Issue
2016-09-22 16:42 nbv Assigned To => msv
2016-09-22 16:43 nbv Relationship added child of 0027895
2016-09-22 16:50 msv Assigned To msv => nbv
2016-09-22 16:50 msv Priority normal => low
2016-09-22 16:50 msv Status new => assigned
2016-10-12 09:30 nbv Description Updated View Revisions
2016-10-24 09:24 nbv Relationship added related to 0027431
2016-10-24 10:32 nbv Relationship deleted related to 0027431
2016-10-24 10:32 nbv Relationship added related to 0027441
2016-10-24 10:48 nbv Note Added: 0058994
2016-10-24 15:55 msv Relationship added related to 0027431
2016-11-01 14:11 nbv Priority low => high
2016-11-01 14:11 nbv Severity trivial => minor
2016-11-01 14:14 nbv Note Added: 0059689
2016-11-01 14:42 git Note Added: 0059692
2016-11-01 14:55 nbv Note Added: 0059694
2016-11-01 14:55 nbv Assigned To nbv => msv
2016-11-01 14:55 nbv Status assigned => resolved
2016-11-01 17:14 msv Note Added: 0059715
2016-11-01 17:15 msv Assigned To msv => bugmaster
2016-11-01 17:15 msv Status resolved => reviewed
2016-11-01 17:16 git Note Added: 0059716
2016-11-02 15:40 mkv Assigned To bugmaster => mkv
2016-11-02 17:20 mkv Note Added: 0059798
2016-11-02 17:20 mkv Assigned To mkv => nbv
2016-11-02 17:20 mkv Status reviewed => assigned
2016-11-02 17:20 mkv Note Edited: 0059798 View Revisions
2016-11-02 17:37 git Note Added: 0059802
2016-11-02 17:38 nbv Note Added: 0059803
2016-11-02 17:38 nbv Note Edited: 0059803 View Revisions
2016-11-02 17:38 nbv Assigned To nbv => msv
2016-11-02 17:38 nbv Status assigned => resolved
2016-11-02 17:39 nbv Assigned To msv => mkv
2016-11-02 17:39 nbv Status resolved => reviewed
2016-11-03 16:48 mkv Note Added: 0059863
2016-11-03 16:49 mkv Note Added: 0059864
2016-11-03 16:49 mkv Note Added: 0059865
2016-11-03 16:49 mkv Assigned To mkv => bugmaster
2016-11-03 16:49 mkv Status reviewed => tested
2016-11-03 16:50 mkv Test case number => bugs modalg_6 bug27896
2016-11-09 15:43 nbv Relationship added related to 0028076
2016-11-09 17:43 apn Changeset attached => occt master f73c584c
2016-11-09 17:43 apn Assigned To bugmaster => apn
2016-11-09 17:43 apn Status tested => verified
2016-11-09 17:43 apn Resolution open => fixed
2016-12-07 11:25 git Note Added: 0061204
2016-12-07 11:25 git Note Added: 0061205
2016-12-09 16:30 user533 Status verified => closed
2016-12-09 16:39 user533 Fixed in Version => 7.1.0


Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker