Add Part BOA multiCut, multiCommon and multiSection methods

[triplus]

Have you ever checked my last posting? What I telling you is that the method multiCommon (and multSection) returns a different result for OCC 6.9 compared to OCC6.8.

Yes i did and all the rest of them in the past few years regarding this area. But until the end of the week i can't do any work on this as i don't have the time. I would especially like to test this first and have some data before dismissing multiCommon effort altogether:

Secondly, this makes the function obsolete because one can fuse the tool shapes with multiFuse() and then do the difference with cut() which has no or a negligible performance penalty.

As for:

For 6.9 it does this: s1 AND (s2 OR s2)
For 6.8 it does this: s1 AND s2 AND s2

I guess multiCommon (and multiSection) method can change in a way only OCC 6.9 and up is supported. But you said you would like to have OCC 6.8 behaviour for multiCommon method to make sense to you? Therefore here it would make sense to gather some info on why OCC changed this (hence opening issue report or searching elsewhere for the information).

Or are you telling me you changed your mind based on the discussion conducted and do see multiCommon as viable option? But only for the OCC 6.9 or above? The reason i ask is i will try to focus on the remaining issues and provide answers over the weekend before we dismiss anything too quickly.

[triplus]

One question. In OCC 7 this is new:

Summary:
Tolerances of operands are modified using BOP. Boolean Operation algorithms can now work in ‘protected’ mode when modifications of tolerances of sub-shapes of arguments, necessary in some cases to ensure their proper interferences, do not propagate to input shapes. In this mode, new sub-shapes (vertices and edges) are created when the tolerance of a sub-shape needs to be amended. This new behavior is turned off by default. It can be turned on using two ways:

by setting ‘locking’ flag of the arguments;

by calling method SetNonDestructive(Standard_True) of the API classes.

I have no idea if it makes sense to enable this (OCC 7 and above) or not for multiBOA methods? It was enabled for generalFuse. I looked at some of the examples and in general i guess this is enabled. It doesn’t look like support is there yet when Fuzzy Boolean tolerance is used.

https://www.opencascade.com/doc/occt-7. ... da8a0720a4

In short. Should i enable this for multiBOA methods or not?

[triplus]

For 6.9 it does this: s1 AND (s2 OR s2)
For 6.8 it does this: s1 AND s2 AND s2

I updated the pull request and now multiCut, multiCommon and multiSection methods are available only when OCC 6.9 or above is used.

Secondly, this makes the function obsolete because one can fuse the tool shapes with multiFuse() and then do the difference with cut() which has no or a negligible performance penalty.

I did some tests and to me it doesn't look like multiFuse() + cut() produces equal results as multiCommon (single or multiple arguments) does?

[triplus]

About the SetNonDestructive question. I don't plan to enable it for now. The decision can be made in the future when we will understand better what exactly it does. Therefore current pull request is it.

P.S. Feel free to review it and if any additional work or discussions needs to be done i am fine with that.

[triplus]

In OCC 7.1.0 release notes this section is interesting:

Safe arguments processing by Boolean operations running with fuzzy option

In OCCT 7.1.0, Boolean operations with fuzzy option are protected from increase of the tolerance of the
input shapes. The mode of protection of input shapes from modification (turned on by call to SetNonDestructive) now
supports fuzzy option as well. In the previous version the usage of fuzzy option in this mode was not supported and might lead to wrong results.
Thus, now fuzzy Boolean operations can be safely used in parametric modeling with naming.

And i guess a bit more general description on what SetNonDestructive does:

Prevent modification of original shapes in Modeling algorithms

Many modeling algorithms use the class BRepTools_Modifier. One of its responsibilities is to ensure validity of output shape in terms of correct tolerance values of edges and vertices. In the previous versions increase of the tolerance of a vertex required for validity of the resulting shape could lead to modification of the input shape. In OCCT 7.1.0, when it is needed to increase the tolerance of a vertex belonging to the original shape, the modifier makes a copy of that vertex in the output shape. Thus, now the algorithm ensures that the sub-shapes from the original shape are not changed during creation of the output shape. For this, new vertexes, curves and surfaces are created before calling Rebuild() method and the copies of all vertexes are impacted by curve or surface modifications. Thus it is not necessary to create new vertices during recursive rebuilding of the entire shape. This change concerns the algorithms located in the packages BRepBuilderAPI, BrepFeat, BRepOffsetAPI_DraftAngle, and some algorithms from Shape Healing library. 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 flag can be used if it is needed to prevent copying of vertices for increase of their tolerances.

I therefore wonder if when SetNonDestructive is set and when OCC 7.1.0 is used if we would still need to copy the shape as we do now in multiFuse (multiBOA) and in generalFuse methods:

Code: Select all

// workaround for http://dev.opencascade.org/index.php?q=node/1056#comment-520
            shapeTools.Append(BRepBuilderAPI_Copy(*it).Shape());

Or not.

[wmayer]

Merged.

[triplus]

Great!

If anybody stumbles here in the future and wonders where exactly to find multiCut, multiCommon and multiSection (and multiFuse) methods. Just use regular cut, common, section and fuse ones (OCE 6.9.0 or above is required):

https://github.com/FreeCAD/FreeCAD/comm ... e6f3084c6e

I tested things and this is how i understand them. From GUI point of view BOA commands use single argument and therefore not much has changed for users. From command line user now has the possibility to use multiple arguments (good for parallel performance) and to set fuzzy boolean tolerance. And there is one important thing to understand when using multiple arguments. If shapes are intersecting result might not be what one would expect for common/section operation with multiple arguments:

viewtopic.php?f=27&t=18391#p143925

I did two small changes to improve documentation in this regard in new pull request:

https://github.com/FreeCAD/FreeCAD/pull/418

I think that covers it for now and thanks to all involved for making this happen in this multi-year effort! Especially to @shoogen creating the initial multiFuse method, @DeepSOIC for creating generalFuse method. I could use the work from both as a reference. And to @wmayer to properly place everything in FreeCAD. And last but not least users like @sgrogan and countless other in the past years expressing interest:

viewtopic.php?f=10&t=18179

[femmgeek]

Hi,
I am getting the same issue. I am installing on a new candidate laptop. HP 17z-ak000 AMD a12-9200 quad core w/ 2 radeon 7 gpu/core.

[Jee-Bee]

Which issue I don't see one can you explain?
See also https://forum.freecadweb.org/viewtopic.php?f=3&t=2264