Boolean Difference MultiThreading


Does anyone succeeded in multi-threading boolean difference for breps?

In my case I have a datatree of single breps per each branch, and other tree with solids to substract.

I know that for one solid difference opration is impossible to make faster, but for many objects is it?
Is it thread safe?

I tried to search in the forum but same issue is repeating. I stopped betting on solid difference for meshes since any case when faces, edges or vertices are touching would likely to fail.

If not, can someone give me guidelines how to perform solid difference in a fastest way?

The geometry I am cutting is a box with another list of boxes. Boolean brep for 9 boxes cut from one box takes 0.5 second.

@Petras_Vestartas Have a look at this link:

Maybe this will be helpful.

Is there C# version as well?
It seems that it is failing for CSharp.

Any ideas why?

The C# version worked fine for me:

Threaded (457.7 KB)

But it is important to notice that booleans can only be performed sequentially, which also this component does in that it processes one branch per thread, meaning, all the spheres in the corresponding branch are booleaned sequentially against one flat Brep (= the regular foreach-loop inside the outer parallel loop).

Separate branches otoh can be processed in parallel, one branch per thread.

// Rolf

The performance seems somehow very odd:

C# parallel loop is slower than normal component.
And python works faster. Is it because it does intersection between one and many breps at once?

Could someone explain how we can setup Parallel loop in C# for these booleans?

However, it is interesting that appending all breps into one brep (D input) before performing boolean operation speeds up things quite significantly but as well failing in result also quite significantly :hear_no_evil::

If you run both components at the same time, utilizing all cores, how can you then know which component is the fastest? They would fight about available processing power and there’s probably no guarantee that the resources are distributed evenly. I’d check them in independent runs. If the difference remains, then that is that. Differences could depend on how the wrappers are implemented under the hood of C# resp. Python, or if the C# component isn’t a wrapper at all(?).

// Rolf

1 Like

I ran separately.
Possibly brep booleans are just slow and nothing can be done.

This is the case for 4 boxes and 50 spheres:

And this is after appending to one brep all the spheres. The parallel version wont change and non parallel is a bit better. But it is not the good way of doing booleans, because you do not know when the failure occurs:

It is interesting that for cutting boxes the solution is even slower. It means that it does not matter if you are cutting curved or flat surfaces, the speed is relative to face count:

Have you tried doing Intersection and cut with the resulting curves and… well, handmade Boolean?

// Rolf

Getting intersection curves is quite fast.
But then if you use Brep.Split method the speed is again as slow as before. Image below.

Mesh difference if obviously faster, but it wont work for more complicated cases when mesh properties are touching vertex-to-vertext, face-to-face, edge-to-edge

Yes, I also just tried Boolean (4s / 5breps) and Split (5s / 5breps)

// Rolf

1 Like

I assume then the conclusion is that Boolean Operations is what it is :slight_smile:

1 Like