The algorithm that builds outlines ("silhouettes") makes an outline in 2d parametric space of the surface starting from some previously detected point where normal is orthogonal to direction of view. So, the surface is previously discretized into (m*n) sample points and some of them become starting points for future outlines.
If the surface has non-uniform parametrization and/or some local extremums of curvature, the outlines can not be built without breaks, so there are several groups of consequent outlines in this case. Unfortunately, it leads to the situation when current number of sample points becomes insufficient to build all the parts of outlines.
The idea is to detect the "holes" between already constructed parts of outlines and then complete the construction.
New auxiliary draw command for testing of HLR.
Correction according to the remarks.
Update of test case according to the developer's directive
The GeomFill_NSections algorithm cannot create any surface from sequence with single curve only.
Therefore, return is provided in corresponding place of the code. Additionally, some public methods of GeomFill_NSections class checks if the surface has been created earlier.
Test case for this issue has been created.
Compiler error has been eliminated.
Make protection of HLR algo against garbage data in faces. In particular case, there are faces built on a periodical surfaces, which U bounds exceed period thousands times. Such faces are excluded from the process of edges hiding.
In addition, while fitting the intersection point in period for periodical faces, replace looping with the single call to AdjustPeriodic method.
- Add new test case.
- Update tests of HLR according to new numbers of subshapes.
Update of test cases according to the new behavior
1. The reason of exception has been eliminated.
2. Interfaces of DistanceMinimizeByGradient and DistanceMinimizeByExtrema methods of IntWalk_PWalking class has been changed.
Creation of test case for this issue.
TODO has been added with reference to the issue #26329
1. BOPAlgo_MakerVolume - Taking into account the possibility of Same Domain faces
while collecting the faces for building the solids;
2. BOPDS_DS - Making the check on coincidence of edges consistent with the intersection
algorithm which also adds the Precision::Confusion() to the intersection tolerance;
3. Test case for the issue.
4. Adjusting test cases (improvements) to their new behavior.
The matter was that with starting point paased into intersector the walking line goes one point outside of the surface domain. Then during purging this extra point is removed from the line but its geometry is used for the last vertex. This makes a set of points invalid for approximation, and as a result we obtain the curve with reversed tangent direction at the end.
The API of the method IntPatch_WLineTool::ComputePurgedWLine has been changed to insert a new Boolean parameter RestrictLine. If this parameter is false than the step of removing of outside points is skipped, and the result line is not distorted. This flag is determined inside IntTools_FaceFace to tell the intersector if it is needed to limit intersection line by surface domain.
Test case has been added.
2d-tolerance has been bounded above (earlier it was too big for precise computation).
Creation of the test case for this issue.
Adjusting some test cases according to their new behavior.
Adjusting test case according to its new behavior.
- Ensure that the subshapes from the original shape will not be changed after nurbsconvert operation.
For that create the new vertexes (NewPoint(..)) as well as new curves (NewCurve(..)) and new surfaces (NewSurface(..)) before calling of Rebuild() method. Make copies of all vertexes impacted by curve or surface modifications. This eliminates necessity of creation of new vertices during recursive rebuilding of the entire shape.
- Compatibility with the old behavior of BRepTools_Modifier has been retained as an option. For that the new flag MutableInput has been added in the interface of the class.
- This patch also impacts other operations based on BRepTools_Modifier, in the sense that they also become safe regarding input shapes.
- Create new test cases. Some test cases with nurbsconvert command are changed to lock input shapes from modifications.
fix regressions
The algorithm of finding of extrema solutions of a point and a torus in Extrema_ExtPElS has been corrected for the case of torus having major radius equal to zero.
Test cases are added.
The static method CorrectSurfaceBoundaries() in the class IntTools_FaceFace,
which is used for correction of the boundaries of the faces before their intersection,
contains two inconsistent adjustments of the boundaries of the faces based on periodic surfaces.
One of these adjustments has been removed. The remaining adjustment, the one that is based on the
2D bounding boxes of the closed curves, should be sufficient.
Test case for the issue.
Intersection of curves and surfaces in HLRBRep is corrected: parametric limits of face are used instead of parametric limits of surface
Building of outlines (Contap_Contour) is corrected: method ComputeCloseLine is now used in all cases.
Correction of HLRBRep_Surface: usage of UVbounds-option
Correction of test cases according to the new behavior.
The max extension value of the faces in offset operation has been decreased
to 1.e+7 value to avoid the lack of precision in the calculations.
Update of test cases according to the new behavior
1) BRepBuilderAPI_MakeWire::Add (const TopTools_ListOfShape &L) method have been completely rewritten. The order of edges is not significant now.
2) The geometric proximity of free vertices from already existing wire and from input list of edges are also have been taken into account. If such vertices are coincident with each other then they are fused into the one. The original wire remains untouched topologically (yet the tolerances and points can be modified).
3) UBTreeFiller is used to speed up the process of picking of coincident vertices.
4) BRepLib now contains the 'new' method - BoundingVertex(..). The implemenation of this method are taken from BOPTools_AlgoTools::MakeVertex(..).
5) The '-unsorted' argument have been added to 'wire' command.
Conflicts:
src/QABugs/QABugs_20.cxx
Add missing include.
Eliminate warning.
1. IntTools_ShrunkRange::Perform
The algorithm of building shrunk range on the edge has been redesigned to make this range as big as possible.
By new definition it has to have the length not less than Precision::Confusion().
Although, the possibility of splitting of the edge has been taken into account. If it is impossible to put
vertex on edge in such a way that the tolerance spheres of the edge's vertices do not intersect the tolerance
sphere of the putting vertex the edge cannot be split. This possibility is saved in the new field
IntTools_ShrunkRange::myIsSplittable. It can be checked by the corresponding method IntTools_ShrunkRange::IsSplittable().
It returns TRUE if the shrunk range is computed successfully and it has the length more than the value of sum of two tolerance
values of the edge (for putting vertex, as its tolerance should not be less than the tolerance value of edge) and
two Precision::Confusion() values (to make two new edges valid by Shape validity criteria).
IntTools_ShrunkRange::myErrorStatus and IntTools_ShrunkRange::ErrorStatus() have been replaced by
the IntTools_ShrunkRange::myIsDone and IntTools_ShrunkRange::IsDone(). IntTools_ShrunkRange::IsDone() returns TRUE
if the shrunk range has been computed and it has length more than Precision::Confusion().
All computations of the parameters are performed using the GCPnts_AbscissaPoint, but if AbscissaPoint is unable to
compute the parameters the Resolution of the curve is used.
2. Boolean Operations algorithm now partially works with the edges that cannot be split or does not have the ShrunkData
at all (previously such edges have been considered as micro and just ignored). If by the result of some intersection such
edges should be split, i.e. the intersection vertex should be created, the algorithm just ignores them and no vertex is created.
But if such edges coincide with other shapes (other edges or faces) the algorithm uses them for creation of common blocks.
The information of the possibility for the edges to be split is saved in its PaveBlocks, in the new BOPDS_PaveBlock::myIsSplittable field.
It can be retrieved by the BOPDS_PaveBlock::IsSplittable() or BOPDS_PaveBlock::ShrunkData(), but these methods
make sense only after filling of the shrunk data for the pave block.
BOPTools_AlgoTools::IsMicroEdge() has an additional parameter that defines whether it is necessary to take into account
the possibility for the edge to be split or not. By default it is set to TRUE, i.e. by default the edge will be considered as micro
even if the shrunk range is computed, but it is too short for the edge to be split.
3. BOPAlgo_PaveFiller::PerformEF
To avoid creation of too close intersection vertices the intersection ranges of the edges participating in Edge/Face
intersections are reduced taking into account the common ranges computed during Edge/Edge intersections.
Thus, the Edge/Face intersection vertex is not created if it gets into a common range of the Edge/Edge intersection
between that edge and one of the face's edges. The tolerance value of Edge/Edge intersection vertex is increased
to reach the Edge/Face intersection.
4. Unification of the vertices of the section edges considered as micro edges.
If by the result of some Face/Face intersection the section edge is considered as micro edge,
the vertices of this edge will be united and the edge itself will be removed.
5. Test cases for the issues.
6. Adjusting test cases for issue CR27448.
Correction of code to avoid of usage of undefined associated parameters in order not to get exception in constructor.
Creation of test case for this issue
The problem of incorrect CUT is wrong Pcurve after projection onto cylinder of a small edge orthogonal to cylinder's axis. The result of projection is a line along V direction, but it should be along U.
ProjLib_Cylinder has no specific functionality to build projection in most common case, so it should return "not done" flag to start projection based on curve approximation.
Following changes are done:
1. ProjLib_Cylinder returns isDone=false in the following cases:
* the projected line is not parallel to cylinder's axis
* the plane of projected circle is not orthogonal to cylinder's axis
2. Test case added
Minor correction of test case
Computation of correct offset values in order to make correspondence (with adjusting to periods) between Domain of WLine and surface domain.
Creation of test cases for this issue.
Small correction in the test case.
The cause of errors is a non alphabetical order of complex entity, which do not affect export.
Move messages to debug mode.
Replace fail by warning.
Correction of test case bugs/vis/bug23153 according to the new behavior
