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

About CUT Boolean Operation

Anonymous's picture
Forums: 

Hi everybody.

I've started to use OCC 5.2 libraries in last month, in order to try writing a machining simulation software using MFC on VisualC++ 6.0.
Using some samples found in the OCC SDK and the MFC Wizard, I've created an MDI application with clean and optimized code that perform my task : now I have a simple simulation of a milling tool (an OCC Cylinder) that remove material from a rectangular wood panel (an OCC Box). Everything works fine ... except the time performance !!!
Deeper the tool saw material from the panel, slower its motion is performed ! I've used a profiler over my application in order to estimate the performance of my code and the 'BRepAlgoAPI_Cut' is the big bottleneck of this poor performance...it works very well but it works slow !!!

I've found a lot of topics in this forum about this issue and everybody seems to have many problems with booleans OCC. OCC guys tends to minimize everytime but I think that they can't assert that their Boolean Alghoritm are fast !

Now, two questions :
- I don't ask to solve my problem but si there anybody who knows if there is an optimized mode to use OCC Boolean Op. or I have to use OCC raw functions to create by my self fast boolean operations (as I can use OpenGL functions) ?
- Subscribing to OCC Support can I have access to some OCC secrets that could help me to perform my simulation in a faster way ?

Thanks for your patience and replies.

Andrea Silvagni.

Alessandro Tasora's picture

Hallo,
the problem is that you are using BRep-type booleans between 'high level' topological representations (this of course is not a trivial task even in other kernels). On the other hand, most often, milling simulations are performed on a simple 'triangle mesh' level, that is booleans are done on simple polygonal representations. In fact this is enough for most needs of milling simulations (collision tests, etc.). Anyway you should write your own boolean methods for simple triangle meshes, since I guess that OpenCASCADE has no tools for this.
Best regards

Andrea Silvagni's picture

Hello Alessandro,

I agree with you about simplify the "milling problem" using a polygonal representation of the 3D environment, in case of collision test it will be good enough to achieve this goal.
Using OpenGL Kernel functionality I've implemented some academical algorithms that try to solve that matter with ascending and descending success ... have to say, more often descending success :-) !

In our company we make woodwork machinery from mechanical to software parts, and our milling problem is also to obtain a 3D representation of a milling working session, how tools extract material from the wood panel : we need a virtual representation of reality !
We're actually using an external CAD/CAM SW (AlfaCAM by Lycos, a GB Company) that can achieve this goal with GOOD PERFORMANCE of calculation-time and 3D representation, making a SOLID representations of the wood panel from the beginning to the end of the milling session.
Actually I'm evaluating SDK and Libraries tha can help our software engineering office to realize this kind of simulation inside our company, without realizing a complex 3D-Kernel.

OpenCascade SDK seems at the beginning the perfect solution for my needs...'til I've performed a solid cutting Simulation, as I told you in my past topic ! It's a little shame, cos this package seems to be very weel realized, with a lot of useful CAD functions...and it's also shareware :-), but this poor performance in Boolean Ops has changed my opinion about it ...

Thansk for your reply Alessandro.

Andrea Silvagni.

Forum supervisor's picture

Hello Andrea,

Indeed, step-by-step simulation of the milling process using OCCT Boolean Operations might be slow. However, there are several ways to improve the situation. In case if you wish to work with precise geometry, you may try to create a 'hull' shape from your milling tool and its path, and to cut the part with this hull using single Boolean operation.
Another way is to use tessellated representations, as it was mentioned in this thread. To support this type of operations, Open CASCADE offers several tools such as Open CASCADE Mesh Framework (OMF, to store mesh data for the operations) and Express Mesh (the algorithm to tessellate models). And, what could be more interesting for you, this time we finalize the development of Boolean Operations on mesh - a set of advanced tools that will allow performing Boolean operations on the mesh objects in OMF.

For more details about OMF, please visit http://www.opencascade.org/support/products/omf/.

With best regards,
Forum Supervisor

Philippe Carret's picture

Aleker is an editor of a woodwork CAD solution
I know exactly what is the functionnality on alphacam you are trying to re-create. It's a very fast and nice feature of alphacam. I'm using OpenCascade for 5 years and I reallly don't knoiw how to achieve this at that speed.

This problem of speed with Boolean op is well known by our customer
Some cabinets with all the modelized holes need 14 minutes to be computed !!!

To Forum Supervisor :
What do you mean exactly by "you may try to create a 'hull' shape from your milling tool and its path"
Are you taking about BRepBuiderApi_MakeSweep ?

My final question :
Is there any trick to do one or more holes on a rectangular box (a panel) with a fast algo. Currently we are doing it with a cylnder + boolean op. Is it the fastest way. We do not need accuracy there. It is just for visualization.

Thanks in advace.

Philippe

Jin Oh's picture

I was googling the Boolean issues in OCC and I found an interesting blog ~ which can answer for the frequently asked question - why boolean is slow in OCC?.

Please check it out.

http://opencascade.blogspot.com/2008/12/why-are-boolean-operations-so-sloooooow.html

I would like to ask OCC team to pay attention to it.

Supervisor, would you make a comment about this?
Thanks!

Silvagni Andrea's picture

Hallo everybody...again ! After one year, I'm here to resume this post. Any news about this "Boolean Operation" thread ?

Last year, in my company we've evaluated some external packages - SDK - based on OpenGL technology, in order to obtain a good performance on milling simulation of our woodworking machines. Performance doesn't satisfy us and we're looking again around to find something else.

I've just downloaded OpenCascade 6.1. I will try to obtain a milling simulation producing a "hull shape" of my tool path, subtracting this from my original wood-piece, as someone suggest above...

If anyone has got some news, I will appreciate to debate together.

Greet, AS.

Pawel's picture

Hi Andrea,

I have the same problem - but just as you not really a solution. What I'm doing now is using some external collision detection library that maybe I can modify to compute material removal.

Another idea is using sweeps with OC objects and runnig boolean operations on the swept surfaces/solids (you don't have to run boolean operations that frequently then). I haven't tried that yet but I'm planning to.

Regards
Pawel Kowalski

Peter Clifford's picture

Doing Boolean operation to simulate milling is slow and always will be.
The further the milling progress goes the computations that have to be performed increase substantially therefore the longer the program, the slower the rendering will be.
Check out this link. http://5axes.free.fr/devel_NCVisu.htm
This method uses the "Needles" method of simulating cutting.

Volker's picture

I have a similar task to solve:
Given an shell (or solid or if necessary the single faces of the shell) and a movement (ie a spine p(t) for the path and a spherical curve n(t) for the rotation=normal vector) I have to find the volume covered by the body during the motion.

Obvisously, the spherical curve may be replaced with an auxilary spine generated as an approximation of p(t)+n(t), which might allow to apply BRepOffsetAPI_MakePipeShell. Unfortunately, I haven't managed to get PipeShell working with an auxilary spine. (The faces to pipe will in general not be planar.)

I would appreciate any hint on BRepOffsetAPI_MakePipeShell at auxiliary spine mode or any proposals in which way the trace volume can be calculated.

arkoala's picture

I am achieving that task using BRepOffsetAPI_ThruSections.

I usually have a wire as a path (CAD system), and several topods_shape as section for each point in that path which I need to reorient in order to get the bisectriz. (I am not getting circular edges, but if any problem occurs, interpolation can be carried out)

This is not very real because the begining and the end are not very realistic, but you can use two cylinder to fix them.

Atthe moment I have enough with that, but problem will arise when I cut a shape with a "tool" (The result of BRepOffsetAPI_ThruSections).

If I get another TopoDS_Shape as a result, how can I achieve the material removal? Wouldn't be a TopoDS_Compound as a result and I would have to select which part keep and which other parts remove? Maybe with a cast to TopoDS_Compound and exploring shapes, maybe not (I am not beginning to research on that, only doubts overcome my head)