For all issues regarding the Forums use, please, refer to the Forum Rules.

Our Solutions

Need professional assistance?
Consider our:

Support Offerings


Need to speed up your development?
Have a look at our:

Samples & Tools


Need some functionality extending standard OCCT capabilities?
Check out our:

Adv. Components

Related pages

[Blog] Why Boolean Operations are so slooo...ooow ?

Roman Lygin's picture

Open CASCADE Boolean Operations (BOPs) have frequently been claimed to be slow. Have anyone tried to find out why ?


Roman Lygin's picture

Part 2

Roman Lygin's picture

Part 3 (final, and long, sorry)

Please rate this article using the voting buttons under the text.

Lodyzhensky's picture

Dear Roman Lygin

I've read your issue.

In my opinion:

1. The analysis done can not be considered as universal, because it has been done for (to put it mildly) limited number of cases: two. Meanwhile the real number of cases is more than two.

2. The problems to kick up a row (IntPolyh_*) deal with TKGeomAlgo library that is not devoted to BOP Algorithm itself. Thus, sorry, you wander from the subject.

3. The information about how calculate the number of elements of an array will be usefull. At least, I did not suspect that the things are so simple.

4. Have your modifications like IntPolyh_DynamicArray, etc. been approved by Open Cascade? or may be life again " not so simple as sometimes seems" I have in mind the experience with BSpl*.

5. "Go and try Intel tools". Ok, now I'll know, but how it relates with subj.

Nevertheless, it is good thing that
- you've made an attempt to analyse the problem ;
- at least have seen the code itself in contrast to the others (not all of course) that like to raise claims.

Roman Lygin's picture

Hi Evgeny,

I have never claimed this is a universal improvements. There is no point to pretend that. There is at least one case (sent by Pawel K) that was not affected by them, because the bottleneck is in the edge-to-edge intersection part. As explained below in this forum thread, the problem relates to Extrema.
Like I mentioned in the blog, the number of responses was too limited than I hoped. Well, so I used what I got ;-). Anyway, I still welcome any models that anyone would like to send me.

On your #2, you will possibly be surprised to know that TKBO.dll itself took only 1.7s (out of 80s), while TKGeomAlgo.dll - 34.49s, and TKMath.dll - 24.2. The latter two were top time-consuming modules.

#4. I sent modifications to OCC. They will need some time to review and to validate them.

#5. It relates in the way that if you want to make your app run faster, Intel tools can help you in that.

Again, if there are good representative models revealing the problems, I'll be happy to incorporate them into the test database.

--- - blog on Open CASCADE

Roman Lygin's picture

For those who are interested:
Download instructions and further request have been posted in the comments section (


--- - blog on Open CASCADE

David Egan's picture

I think part of the issue is not only are they slow but in many relatively simple cases they fail as well. So the problem is a double edged sword. Speed is one issue but accuracy is another, so when you wait along time for the wrong answer it can get frustrating! I have spent some effort in the accuracy side but no real progress so far- only in I know what surfaces to avoid.If you like I can send you where I am at.

jelle's picture

Hi David,

I'm pretty new to OCC, but recently wrote a small program that takes my Rhino geometry & does the BOP's in OCC.
That worked out really well. I'm curious about the simple cases you mention. Would you be able to post those models?
It would be interesting to see in which simple cases BOP's fails.


Roman Lygin's picture

Hi David,

Of course, please provide a test case for the issues you have met. If you do this, there is no strong hope it will be promptly fixed by the OCC team but unless you do this, it will happen with even a smaller chance ;-).


--- - blog on Open CASCADE

Macedo's picture

Hi Romam Lygin,

Firstly I would like to thank you about your blog, it's bringing to me a lot of information.
Secondly I would like to know why Projection is too slow? (I'm using ShapeAnalysis_Surface class, because it seems the faster, but not enough)

Thanks in Advance.
Best Regards,

Roman Lygin's picture

Hi Thiago Macedo,

I guess this is due to Extrema classes. I have just been making analysis of another test case sent by Pawel K and found out that it is connected with Extrema. Digging around I noticed that Extrema are designed in a way to perform calculations with every initialization (e.g. with curve). In the case of projections or BOPs there are repeating computations with same curves but on different intervals, however Extrema does not reuse knowledge of previous computations. ShapeAnalysis_Surface tries to work-around this by caching Extrema_ExtPS in a member field but possibly due to some Extrema-specific limitations, drawbacks remain. For instance, Extrema uses gp_Pnt::Distance() (instead of SquareDistance()), what adds overhead of sqrt().
We are currently in discussion with the OCC team on what can be done with Extrema. There are chances this can be addressed, but no commitments ;-).


--- - blog on Open CASCADE

David Egan's picture

Will do, I will prepare a couple of models this week,most of my geometry is sensitive so need to make some new ones with the features of concern. But the two areas I have found OCC to be very sensitive to is the knot parametization of the underlying nurbs and the existence of uv tangency on the bounding curves, or near to it. In fairness this does result in a nurb surface of questionable quality , but however this technique is used in engineering extensively.

SINDHU's picture


I have a doubt about the Boolean operations in OCC. I have two wires W1,W2. I have the offset of wire W1 as S1. Now,I want to perform CUT operation on S1 and W2 so as to remove the common portion and get the resultant as a shape 'S'. But the output obtained is either S1 or W2, but not the resultant wire. My code is
TopoDS_Shape res1=W1;
TopoDS_Shape res2=W2;
const GeomAbs_JoinType Join=GeomAbs_Tangent;
Standard_Real dist2 = -1.5;
BRepOffsetAPI_MakeOffset off(W1,GeomAbs_Tangent);
TopoDS_Shape S1= off.Shape();
BOP_WireWire Wire;
Wire.SetShapes (S1,res2);
TopoDS_Shape S=Wire.Result();
Handle(AIS_Shape) ais2=new AIS_Shape(S);

The Shape S should be the result obtained after cut operation.
But S is displaying either S1 or res2. The two wires are intersecting so the resultant obtained should be the combination of two wires with the common part removed. Can anyone help me please. How can I get the resultant wire S as a combination of S and res2?

Thanks a lot,

Paul Jimenez's picture

The first issue is that you are posting in the wrong thread. This thread is about Boolean Operations being slow, why and solutions (given in the Blog). Anyway, it happens quite often and no one seems to care much about it. Still, it makes the forums a little bit messy.

The second issue (the problem you described) seems to be a misunderstanding of what the CUT operation does, or how it does it. CUT can be used, for example, to remove pieces of a face (like cutting paper with scissors), take pieces out of solids (like removing part of an ice cream ball with a spoon) and so on. I do not really understand how you expect to CUT a solid with a wire. If your intention is to 'slice' it (like cutting it in half), then you have to play with the boolean operations using the right shapes. For CUT, you would have to use a solid that encloses the part you want to remove from the other solid. I would suggest you to start a new thread if you still need help, explain better your problem, and, if possible, post links to images that show what you are trying to do.

SINDHU's picture


Please go through this thread and give me the possible solutions to the problem..

Thanks in advance