Archived discussion
Dear Commenter-1,
Attached is an example of a Gaudinean column problem, where a Boolean common is performed between a twisted rectangular column and its symmetrical counterpart.
I have attached a file called shapes.step, that contains the two operand shapes.
And the result of how the Boolean common should look like result_catia_boolean_common.step, this was obtained by executing a body-to-body intersection in catia(it almost blinks, in less than 50 milliseconds).
on other configurations of the same twisted operands, occ works but returns an invalid result that is not a solid, as an incomplete boolean.
I have attached both the operands that return an invalid result and the invalid result in Brep format.
I have also attached the openshapefactory script that generates the operands, its should be fairly simply to deduct the logic in case you would like to replicate it as a draw script for unit testing.
beyond the uncertainty of obtaining a correct result or any result, there is also the performance issue, I tried running the BRepMesh::Mesh() command on both operands prior to running the Boolean operation to see if this improves performance, it still takes around 3-11 seconds to perform the Boolean common on these twisted rectangles, while in catia the result is almost real-time.
Hope this proves to be a useful test case.
I tried this on Occ 6.3 and Opencascade Community Edition version 12, same results for both.
Best,
Alex
Discussion
Posts are displayed in their archived order.
Dear AlexP,
The mentioned version of OCCT (6.3.0) is too much obsolete.
I suggest you to use the recent version of OCCT (OCCT6.6.0).
See the result obtained in OCCT6.6.0. It looks valid.
If you need exactly OCCT6.3.0 you may contact us via the Contact Form http://www.opencascade.org/about/contacts/.
We will try to find a solution/workaround acceptable for you.
Training and e-learning courses are also at your disposal - http://www.opencascade.org/support/training/.
Regards
Dear Forum Supervisor,
Thanks for the quick response.
You where absolutely right switching to version 6.6.0 did work on the operands I had attached.
And Thanks for that.
the other issue is performance, how quick did this operation ran on your end?, it is taking on average 13-22 even 47 seconds on some runs (I have attached the operands that took 47 seconds), I am running on debug mode on windows 7 32 bit Intel core duo 2.4ghz(two processors) .
I tried following the code you use inside the draw commands BOP and BopCommon:
BOPCol_ListOfShape aLC;
BRepMesh::Mesh(Tool, 1000); //added these with the hopes that meshing had something to do with Boolean speed.
BRepMesh::Mesh(Stock, 1000);
aLC.Append(Tool);
aLC.Append(Stock);
Handle(NCollection_BaseAllocator)aAL=new NCollection_IncAllocator;
BOPAlgo_PaveFiller pPF = BOPAlgo_PaveFiller(aAL);
pPF.SetArguments(aLC);
pPF.Perform();
BOPAlgo_BOP aBOP;
aBOP.AddArgument(Stock);
aBOP.AddTool(Tool);
aBOP.SetOperation(BOPAlgo_COMMON);
//
aBOP.PerformWithFiller(pPF);
/*iErr=aBOP.ErrorStatus();*/
Result = aBOP.Shape();
//**************----------
by using a filler first increased the time by two times, now it takes 25 seconds for the same operation as opposed to simply calling: BRepAlgoAPI_Common(Stock,Tool,) also by using the filler is not as robust than by using the BOPAlgo_BOP alone for example the following code yields always a result where the previous code would not:
BOPAlgo_BOP aBOP;
aBOP.AddArgument(Stock);
aBOP.AddTool(Tool);
aBOP.SetOperation(BOPAlgo_COMMON);
aBOP.Perform();
Result = aBOP.Shape();
I also tried Meshing the operands with a coarse mesh size prior to calling the Boolean operation and still takes the same amount of time.
Is there anything I can do to enhance speed of Boolean Operations, I understand this is one of the hotspots of the library, I was just wondering with what is currently there in version 6.6.0 what are the most optimum settings we can setup to make version 6.6.0 run at its optimum.
Just to recap in terms of speed the three options to run booleans are running from faster to slower as follows: BRepAlgoAPI_Common(11-15 seconds),aBOP.PerformWithFiller(22-25 seconds),aBOP.Perform(25-47 seconds);
Also there where isntances where the aBOP.PerformWithFiller did not return a result but the aBOP.Perform() did return a result, is aBOP.Perform running a check on the operands and fixing them as opposed to using the filler, which might be the reason why it takes longer?
Best,
Alex