Boolean Operations With Multiple Arguments

Forums: 

1. Introduction

The Boolean Operator of Open CASCADE (≤6.8.0) allows treating of two and only two arguments (shapes) to process [1]: S1 (Object), S2 (Tool). In modeling tasks the very frequent situation is when multiple shapes are to be processed from both sides, Object and Tool. For example, when we have to make in a body of Object multiple cutouts, we need to pass to the Boolean Operator one shape as the Object and a set of shapes as a Tool. The developer has to organize a cycle for repetitive cut from the Object shapes of the Tool one by one. Besides the fact that it is inconvenient for the developer, it applies additional extra expenses in the form of auxiliary temporary data structures that are filled in each instance of Boolean Operator.

2. Changes in Boolean Operator

In the current development version the Boolean Operator is able to treat two groups of arguments with arbitrary number of shapes, possibly having intersections with each other. The updated API takes on input a list of shapes on each side, Object and Tool. Each shape from the list meets usual requirements from [1]. The class BRepAlgoAPI_BooleanOperation contains the corresponding API for the usage of the new feature. The methods SetArguments(…), SetTools(…) provide the possibility to pass multiple arguments. The new feature of the Boolean Operator gives the following benefits:

  • Possibility to perform the operation in a single pass
  • Simplification of the caller procedure
  • Improving the performance due to usage of one data structure
  • Improving the whole performance for the cases with few number of actual intersections

3. Test Results

Testing of new functionalities has been performed for the cases where the old code had to be used in the mode of multiple sequential Boolean Operations, i.e. the result of one operation is the argument for the next one. The test results show the considerable improvement of the performance achieved by Boolean Operator with multiple arguments comparing with old sequential “two-arguments” approach. The following environment has been used to obtain the results below:

  • Processor: IntelВ® Core(TM) i5-3450 CPU @ 3.10 GHz
  • Installed memory (RAM): 16GB
  • System type: 64-bit Operating System
  • Operating System: Windows 7 Professional Copyright 2009 Microsoft Corporation. Service Pack1
  • Compiler: Microsoft Visual Studio 2010 Version 10.0.40219
  • Open CASCADE: 6.8.1 development, optimized mode
  • All computations have been done in non-parallel (single-thread) mode

Example 3.1

The Figure 3.1.1 shows fragment of Objects (gold) and Tools (silver)

Figure 3.1.1

The parameters of the operation are in the Table 3.1.1

Table 3.1.1
No Parameter Values
1 Objects 1 face
2 Tools 120 faces
3 Operation Cut

The performance values are in the Table 3.1.2

Table 3.1.2
Operations With multiple Arguments Using sequential treatment of two Arguments Gain
CPU user time, sec 1.00 6.67 6.67

The fragment of the result is shown on the Figure 3.1.2

Figure 3.1.2

Example 3.2

The Figure 3.2.1 shows fragment of Objects (gold) and Tools (silver)

Figure 3.2.1

The parameters of the operation are in the Table 3.2.1

Table 3.2.1
No Parameter Values
1 Objects 1 solid
2 Tools 30 solids
3 Operation Cut

The performance values are in the Table 3.2.2

Table 3.2.2
Operations With multiple Arguments Using sequential treatment of two Arguments Gain
CPU user time, sec 4.77 12.73 2.67

The fragment of the result is shown on the Figure 3.2.2

Figure 3.2.2

4. Conclusion

The Boolean Operator of Open CASCADE has been extended to be able to treat multiple arguments. The extended operator allows to:

  • perform the operation at single pass
  • simplify the caller procedure
  • Improve the performance of the operator

5. References

1. OCCT 6.8.0 Boolean Operations User's Guide

Sebastian Hoogen's picture

Can I leave the Tools list empty? As it doesn't make sense to me, to divide the arguments for the Fusion and Common operations into two groups?
EDIT: nevermind

Peter KURNEV's picture

The number of arguments is always greater than 1.
So the arguments have been already divided.
Just consider some of them as Objects and all remaining as Tools.

Mikhail Sazonov's picture

There are some fine points that are needed to be understood. They follow from the matter of Set theory and Boolean operations. They force that the algorithm must accept both Object and Tool. It is because split pieces must be unambiguously classified against Object and Tool. (E.g., when the shapes in the Object have intersections they are resolved automatically but the shapes are not joined into one bigger shape. Another example is that if you make common between a set of shapes and an empty set the result will be empty). The more details will be described in the user guide that is planned to be updated later.

Rostislav Khlebnikov's picture

Hello,

when migrating to 6.9.0 I have noticed that the boolean operations on two arguments (in my case using BRepAlgoAPI_Fuse) are actually slower than in 6.8.0. Setting SetRunParallel(Standard_True) does not really help either.

Here are some timings for example:
6.8.0 : 22s
6.9.0 - SetRunParallel(Standard_False) : 36s
6.9.0 - SetRunParallel(Standard_True) : 34s

Could you please tell me why this happens and if there is any way around it?

Thank you,
Rostislav.

PS: the example models that I use can be found here - http://1drv.ms/1AAbYWt
My setup:
Processor: Intel Xeon E5-1620 @ 3.60 GHz
Installed memory (RAM): 16GB
System type: 64-bit Operating System
Operating System: Windows 7
Compiler: Microsoft Visual Studio 2013
Open CASCADE: 6.9.0, optimized mode

Eugeny Maltchikov's picture

Hello Rostislav,

I cannot reproduce the problem on my workstation:
Processor: Intel(R) Core(TM) i5-3450 CPU @ 3.10 GHz
Installed memory (RAM): 16GB
System type: 64-bit Operating System
Operating System: Windows 7
Compiller: Microsoft Visual Studio 2012
OpenCASCADE: 6.8.0 and 6.9.0, optimized mode

The results are the following:
OCCT6.8.0 - 22.3519774405 Seconds
OCCT6.9.0 - 23.1420919721 Seconds

The parallel version of Boolean operations can't really help on this case, as there are only two intersections to calculate - one of the type Edge/Face and one of the type Face/Face.

Regards,
Eugeny.

Rostislav Khlebnikov's picture

Hello Eugeny,

thanks for such a quick answer!

I think I figured out what happened. The slower result was achieved when I passed by two solids to the fuse operation through the constructor (now marked as obsolete). When I passed them to SetTools and SetArguments - the performance actually became better than 6.8.0.

I find it quite strange though that these two approaches to setting the operation arguments are not equivalent, so I hope you can understand my confusion.

Thank you again,
Rostislav.