Added protection against null pointer dereferencing.
Modified BRepOffset_MakeOffset::MakeThickSolid method.
Fixed the problem with negative volume values.
Fixed several unit tests and added a new one.
Integrated DE plugin functionality.
Reworked DE components:
- TKDESTEP: Handling STEP file format.
- TKDEOBJ: Handling OBJ file format.
- TKDEIGES: Handling IGES file format.
- TKDEGLTF: Handling GLTF file format.
- TKDEVRML: Handling VRML file format.
- TKDEPLY: Handling PLY file format.
- TKDESTL: Handling STL file format.
Reworked DE DRAW components:
TKXSDRAWSTEP: Container for DE command to work with STEP.
TKXSDRAWOBJ: Container for DE command to work with OBJ.
TKXSDRAWIGES: Container for DE command to work with IGES.
TKXSDRAWGLTF: Container for DE command to work with GLTF.
TKXSDRAWVRML: Container for DE command to work with VRML.
TKXSDRAWPLY: Container for DE command to work with PLY.
TKXSDRAWSTL: Container for DE command to work with STL.
TKXSDRAW rework to be base DRAW plugin to keep DE session and utils.
Updated documentation
Updated samples
test bugs modalg_7 bug22821 failed on fillet shape with 5-th edge.
Experimentally has been found that reducing of parameter
ChFi3d_Builder::tolesp for this task solves the issue.
So, as soluton it is proposed to link parameter toleps with parameter range of
spine curve. So, production coefficient has been set to pass all tests and
2 teset was extended: tests/blend/complex/A6, tests/bugs/modalg_7/bug22821
first has been extended to test different scaling factors,
second has been extended to make fillet on all edges from 12.
Additionally:
- fixed misusage of tolesp in contexts where tolerance of point in 3d is excepted;
In some context usage of tol_esp is irrelevant, because its essentiality - tolerance of the parameter on the 3d curve.
So, in such context it has been replaced with new parameter tol3d (with fix value 1.0e-4).
Get rid of tolapp3d duplication constant - tol_3d
- tolesp = 5.0e-5 * (umax - umin)
- tolesp replaced by tolpoint2d/tolpoint3d in several classes.
Blend_Walking
BRepBlend_SurfRstLineBuilder
BRepBlend_RstRstLineBuilder
Blend_CSWalking
Instead `tolesp` - `tolgui` is employed in contexts where tolerance of guide curve parameter is excepted.
Instead `tolesp` - `tolpoint2d` or `tolpoint3d` is employed in contexts where tolerance of point in 2d or 3d space is excepted.
- Replace tolesp with tolpoint2d/tolpoint3d in BBPP function argument.
- Use tolapp3d instead tolesp in BonVoisin function,
distmini of two edges returns two solution points instead one.
Second unneeded solution point is the same as first.
The problem was in fact that second edge has continuity C0.
In this case additional extremas analysis performed in special procedure
PERFORM_C0
And second point found in this procedure.
Folowing code of
BRepExtrema_DistanceSS::Perform (variant for Edge/Edge)
we should this additional solution extremas set
to be object of test TRI_SOLUTION before pushing
into main list of solution.
This solves the problem.
Corresponding test and compound with edges has been created.
Additionally, in the function
PERFORM_C0
an obvious error has fixed.
BRepOffset_MakeOffset.cxx - tolerance control for building planar faces is implemented,
updating tolerance for initial entities is avoided
BRepAlgo_Loop.cxx - "total" setting tolerance 0.001 is removing
BRepLib.cxx - checking of "locked" for vertex is removing in static function UpdShTol
QABugs_20.cxx - add new command OCC26441 for checking tolerance differenses between two "identical" shapes
tests/bugs/modalg_7/bug30054 - case now is "BAD", because really result shape is invalid: many faces has not closed wires with huge gaps between ends of edges. Result was "OK" only because tolerances of vertices were increased by algorithm to cover all gaps.
tests/bugs/modalg_8/bug26441 - new test case added
Other test: B3, C8, A7, C8: they were "BAD" and now are "BAD", only some problems are changed.
Problem: From the point of view of the STEP format (and others), it is allowed
to describe a face on a surface with natural boundaries (torus, sphere) without
specifying these boundaries. Thus, a face on a closed surface and containing
an inner wire (or several) is correctly defined and describes a face with a
cutout defined by this wire. At the same time, there is a function
(ShapeFix_Face::FixOrientation) in the ShapeHealing procedure that corrects the
orientation of the wires, and it starts before the function of adding natural
boundaries (ShapeFix_Face::FixAddNaturalBound). There are many shapes that have
incorrectly oriented wires and this procedure successfully heals them, but on a
correctly specified face with single inner wire on closed surface, we do not get
the entire surface with a cutout, but a part of the surface defined by the wire.
This fix is intended to resolve this ambiguity.
Change:
1. Added function isNeedAddNaturalBound that returns TRUE if face needs to add
natural bounds.
2. Corrected condition in FixOrientation to ignoring faces that needs to add
natural bounds.
3. For tests in which one wire was incorrectly oriented on a closed surface,
flag AddNaturalBound was disabled.
5. Test with cutout from torus was created: bugs step bug28414.
Result: By default, it is correct to add natural boundaries, because this case
is correct from the point of view of the STEP format and others.
Adapt test case, the problem is not reproduced any more.
Problem is fixed by the commit: 46478ffe32cfca537a35b744700e082f59ec4c4c (0030008: BRepMesh does not respect angular deflection in internal area of bspline surface)
Added new option '-C' with possibility to set value of Angular and linear tolerances to 'mksweep' command to correct input spine by merging smooth connected neighboring edges
Add choosing the intersect point taking into account the tangentCross when prev UEdge and next UEdge has more than one intersect points;
Add exact correction of edge tolerance (it fix problems with edge tolerance on Linux);
Add exact check of edge tolerance in testcase
1. Modify method IntPatch_ALineToWLine::MakeWLine: add correction of end points of each line on 2 surfaces if an end point is a pole on a surface.
2. Modify method IntPatch_WLine::ComputeVertexParameters: adjust a point on curve to corresponding vertex the following way: set 3D point as the point of the vertex and 2D points as the points of the point on curve.
* Add status flag to GeomFill_Pipe
* Add myIsPerform flag to GeomFill_Pipe
* Add checking vectors in GeomFill_CorrectedFrenet
* Add boolean return to SetCurve virtual methods
* Add test case
* Fix error on computing V first derivative on a cone (take into account the slope of the conical generatrix).
* Add DRAW command 'sderivative' to compute certain derivative on a surface.
Do not limit the normalization factor of the highly anisotropic parametric space when filtering start points in the algorithm of walking line construction.
Additionally check the knots are in the increasing orders when merging two B-spline curves
GeomInt/GeomInt_IntSS.cxx, IntTools/IntTools_FaceFace.cxx - setting deflection 0.01
for case of two bspline surfaces
IntPolyh/IntPolyh_Intersection.cxx, IntPolyh/IntPolyh_Intersection.hxx - status IsParallel is added
BndLib/BndLib_Add3dCurve.cxx, IntTools/IntTools_TopolTool.cxx - fix small bugs
Correction of test scripts according to current behavior of algorithms
lowalgos/intss/bug32849 - test case added
Use distance criteria additionally to parameter criteria when verifying the extrema solution to belong to the edge boundary.
Refactor the BRepExtrema_DistanceSS class to remove the excessive methods with mirrored parameters.
move algorithm of obtaining results from function gproject to method ProjLib_CompProjectedCurve::Perform;
fix tolerances in ProjLib_PrjResolve::ProjLib_PrjResolve;
new treatment of myMaxDist;
use extend bounds in approximation;
add test;
test case "bugs modalg_5 bug25980", "bugs modalg_7 bug24185" have been changed according to new behavior.
Corrected Geom2dConvert_CompCurveToBSplineCurve::Add in Geom2dConvert_CompCurveToBSplineCurve.cxx;
Added the test for this problem;
Corrected "gluing" curves in ProjLib_ProjectedCurve.cxx.
Fixed exception when trying to calculate line and edge normal in methods HLRBRep_Data::OrientOutLine and HLRBRep_Data::OrientOthEdge, added a check for the existence of the normal before subsequent calculations. A correct check for zero derivative, correction of floating point error and division by zero determinant directly in HLRBRep_EdgeFaceTool::CurvatureValue was set.
IntPatch/IntPatch_WLineTool.cxx - adding control of maximal ratio of distances between 3 sequential points.
tests/bugs/modalg_7/bug32569 - new test case added
tests/lowalgos/intss/bug29972_1 test case is modified according new behavior of intersection algorithm
Update information about ON/IN sub-shapes for all touched faces when intersection with shapes of lower types (edges and vertices) complete.
Previously only the faces participating in the Face/Face intersection were updated.
0030620: Tests - perf/bop/buildfaces does not match description (broken)
Allow using meaningful parameters for the commands bbop and bapibop:
* common - for Common operation
* fuse - for Fuse operation
* cut - for Cut operation
* tuc/cut21 - for Cut21 operation
* section - for Section operation
Add description for the commands dealing with Boolean/GF/Split operations.
Validate arguments of these commands.
Correct test case perf/bop/buildfaces to perform GF execution in parallel and serial modes - compare the results.
The following classes have been removed as obsolete:
- BRepAlgo_BooleanOperation
- BRepAlgo_Fuse
- BRepAlgo_Cut
- BRepAlgo_Common
- BRepAlgo_Section
The corresponding classes from BRepAlgoAPI package have to be used instead.
Draw commands:
- fuse
- cut
- common
- section/psection
have also been removed as obsolete.
The corresponding commands for modern Boolean operations algorithm (bfuse/bcut/bcommon/bsection) have to be used instead.
Adjustment of the test cases to use the commands for modern algorithm.
Update BOP commands to use progress indicator
Deleted wrong usage of progress indicator from bop operations
Added UserBreak() method to break execution boolean operation if progress indicator is used
Added method AnalyzeProgress() to calculate steps of progress indicator
Introduce BOPAlgo_ParallelAlgo which has myRange as a field to be used in parallel vector.
Provide suitable way of keeping the progress steps of operations.
Give meaningful names to progress scopes.
Propagate progress indicator into deeper methods of BOA.
Add progress indicator to BOPAlgo_BuilderFace and BOPAlgo_WireSplitter, BOPAlgo_BuilderSolid and BOPAlgo_ShellSplitter
