1
0
mirror of https://git.dev.opencascade.org/repos/occt.git synced 2025-09-08 14:17:06 +03:00

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 #27896.

Small correction in the test case
This commit is contained in:
nbv
2016-11-02 15:25:36 +03:00
committed by apn
parent 416022a12f
commit e2e0498b17
37 changed files with 2575 additions and 2930 deletions

View File

@@ -0,0 +1,125 @@
//! Created on: 2016-06-03
//! Created by: NIKOLAI BUKHALOV
//! Copyright (c) 2016 OPEN CASCADE SAS
//!
//! This file is part of Open CASCADE Technology software library.
//!
//! This library is free software; you can redistribute it and/or modify it under
//! the terms of the GNU Lesser General Public License version 2.1 as published
//! by the Free Software Foundation, with special exception defined in the file
//! OCCT_LGPL_EXCEPTION.txt. Consult the file LICENSE_LGPL_21.txt included in OCCT
//! distribution for complete text of the license and disclaimer of any warranty.
//!
//! Alternatively, this file may be used under the terms of Open CASCADE
//! commercial license or contractual agreement.
#ifndef _IntPatch_SpecialPoints_HeaderFile
#define _IntPatch_SpecialPoints_HeaderFile
//! Contains methods to add some special points
//! (such as apex of cone, pole of sphere,
//! point on surface boundary etc.) in the intersection line.
#include <IntPatch_SpecPntType.hxx>
#include <Standard_Handle.hxx>
class Adaptor3d_HSurface;
class IntPatch_Point;
class IntSurf_PntOn2S;
class math_Vector;
class IntPatch_SpecialPoints
{
public:
//! Adds the point defined as intersection
//! of two isolines (U = 0 and V = 0) on theQSurf in theLine.
//! theRefPt is used to correct adjusting parameters.
//! If theIsReversed is TRUE then theQSurf correspond to the
//! second (otherwise, the first) surface while forming
//! intersection point IntSurf_PntOn2S.
Standard_EXPORT static Standard_Boolean
AddCrossUVIsoPoint(const Handle(Adaptor3d_HSurface)& theQSurf,
const Handle(Adaptor3d_HSurface)& thePSurf,
const IntSurf_PntOn2S& theRefPt,
const Standard_Real theTol3d,
IntSurf_PntOn2S& theAddedPoint,
const Standard_Boolean theIsReversed
= Standard_False);
//! Adds the point lain strictly in the isoline U = 0 or V = 0 of theQSurf,
//! in theLine.
//! theRefPt is used to correct adjusting parameters.
//! If theIsReversed is TRUE then theQSurf corresponds to the
//! second (otherwise, the first) surface while forming
//! intersection point IntSurf_PntOn2S.
Standard_EXPORT static Standard_Boolean
AddPointOnUorVIso(const Handle(Adaptor3d_HSurface)& theQSurf,
const Handle(Adaptor3d_HSurface)& thePSurf,
const IntSurf_PntOn2S& theRefPt,
const Standard_Boolean theIsU,
const math_Vector& theToler,
const math_Vector& theInitPoint,
const math_Vector& theInfBound,
const math_Vector& theSupBound,
IntSurf_PntOn2S& theAddedPoint,
const Standard_Boolean theIsReversed
= Standard_False);
//! Computes the pole of sphere to add it in the intersection line.
//! Stores the result in theAddedPoint variable (does not add in the line).
//! At that, cone and sphere (with singularity) must be set in theQSurf parameter.
//! By default (if theIsReversed == FALSE), theQSurf is the first surface of the
//! Walking line. If it is not, theIsReversed parameter must be set to TRUE.
//! theIsReqRefCheck is TRUE if and only if 3D-point of theRefPt must be pole or apex
//! for check (e.g. if it is vertex).
//! thePtIso is the reference point for obtaining isoline where must be placed the Apex/Pole.
//!
//! ATTENTION!!!
//! theVertex must be initialized before calling the method .
Standard_EXPORT static Standard_Boolean
AddSingularPole(const Handle(Adaptor3d_HSurface)& theQSurf,
const Handle(Adaptor3d_HSurface)& thePSurf,
const IntSurf_PntOn2S& thePtIso,
const Standard_Real theTol3d,
IntPatch_Point& theVertex,
IntSurf_PntOn2S& theAddedPoint,
const Standard_Boolean theIsReversed =
Standard_False,
const Standard_Boolean theIsReqRefCheck =
Standard_False);
//! Special point has already been added in the line. Now, we need in correct
//! prolongation of the line or in start new line. This function returns new point.
//!
//! ATTENTION!!!
//! theNewPoint is not only Output parameter. It is Input/Output one. I.e.
//! theNewPoint is reference point together with theRefPt.
Standard_EXPORT static Standard_Boolean
ContinueAfterSpecialPoint(const Handle(Adaptor3d_HSurface)& theQSurf,
const Handle(Adaptor3d_HSurface)& thePSurf,
const IntSurf_PntOn2S& theRefPt,
const IntPatch_SpecPntType theSPType,
const Standard_Real theTol2D,
IntSurf_PntOn2S& theNewPoint,
const Standard_Boolean theIsReversed
= Standard_False);
//! Sets theNewPoint parameters in 2D-space the closest to
//! theRefPoint with help of adding/subtracting corresponding periods.
//! theArrPeriods must be filled as follows:
//! {<U-period of 1st surface>, <V-period of 1st surface>,
//! <U-period of 2nd surface>, <V-period of 2nd surface>}.
//! If theVertex != 0 then its parameters will befilled as
//! corresponding parameters of theNewPoint.
//!
//! ATTENTION!!!
//! theNewPoint is not only Output parameter. It is Input/Output one. I.e.
//! theNewPoint is reference point together with theRefPt.
Standard_EXPORT static void
AdjustPointAndVertex(const IntSurf_PntOn2S &theRefPoint,
const Standard_Real theArrPeriods[4],
IntSurf_PntOn2S &theNewPoint,
IntPatch_Point* const theVertex = 0);
};
#endif // _IntPatch_AddSpecialPoints_HeaderFile