MantisBT
Mantis Bug Tracker Workflow

View Revisions: Issue #26310 All Revisions ] Back to Issue ]
Summary 0026310: Very slow boolean cut operations on cylinders
Revision 2015-07-16 11:03 by nbv
Steps To Reproduce Branch CR26310_1 already contains four test cases.

Dear testers,

Please make following:
1. Add necessary heads in every test script
2. Show res1 and res2 (in bug26310_3 and bug26310_4) in SEPARATED picture (i.e. res1 in one picture, res2 in second).

And other necessary actions.
Revision 2015-07-06 15:59 by nbv
Steps To Reproduce Attention!

Three test cases have been created and pushed to the branch.


It appears that they are incredibly slow in most circumstances. For cylinders it seems to be related to the resolution of the step size in IntCyCyTrim. Basically for my models the code which increments the variable 'anU1' only increments it by a very small amount each time (~0.003). This is because the variable 'aMinUexp' is always a small variation of the previous value due to the step variable.

In the code there is a while loop starting at line 2368 of file IntPatch_ImpImpIntersection_4.gxx

while(anU1 <= anUl){
.....
}

The issue is that 'anU1' takes thousands of iterations before it is less than 'anUl' for simple cylinders. This can take minutes up to hours to complete depending on the size of the shape, for example semi-infinite prisms can take up to an hour to complete. I have raised the query on the OCC main forum and been requested to re-raise it here.Attached are a pair of cylinders produced by BRepTools::Write that reproduce the problem. If the Cut operation of c from b is executed on 6.5.4 in draw.exe everything runs as expected and quickly. On 6.9.0 the performance is very slow and instead of returning the result shape, the original body is returned, no cut is performed.

I have found that with semi-infinite prisms that have non planar surfaces the same problem occurs but can be reduced significantly by making the prism finite and with a much smaller extrusion. It leads me to believe that the step that is calculated for iterating around the curve of the solid is small compared to the size of the extrusion and causes many executions. This is a wild guess though.

Hope this is enough information and someone can help, I have tried to debug the code and find the reason but it is a little beyond my understanding, I know from performance analysis the time is consumed by the single function CylCylComputeParameters however i think this is simply because it is being called many, many times.
Revision 2015-06-04 11:07 by msv
Steps To Reproduce It appears that they are incredibly slow in most circumstances. For cylinders it seems to be related to the resolution of the step size in IntCyCyTrim. Basically for my models the code which increments the variable 'anU1' only increments it by a very small amount each time (~0.003). This is because the variable 'aMinUexp' is always a small variation of the previous value due to the step variable.

In the code there is a while loop starting at line 2368 of file IntPatch_ImpImpIntersection_4.gxx

while(anU1 <= anUl){
.....
}

The issue is that 'anU1' takes thousands of iterations before it is less than 'anUl' for simple cylinders. This can take minutes up to hours to complete depending on the size of the shape, for example semi-infinite prisms can take up to an hour to complete. I have raised the query on the OCC main forum and been requested to re-raise it here.Attached are a pair of cylinders produced by BRepTools::Write that reproduce the problem. If the Cut operation of c from b is executed on 6.5.4 in draw.exe everything runs as expected and quickly. On 6.9.0 the performance is very slow and instead of returning the result shape, the original body is returned, no cut is performed.

I have found that with semi-infinite prisms that have non planar surfaces the same problem occurs but can be reduced significantly by making the prism finite and with a much smaller extrusion. It leads me to believe that the step that is calculated for iterating around the curve of the solid is small compared to the size of the extrusion and causes many executions. This is a wild guess though.

Hope this is enough information and someone can help, I have tried to debug the code and find the reason but it is a little beyond my understanding, I know from performance analysis the time is consumed by the single function CylCylComputeParameters however i think this is simply because it is being called many, many times.
Revision 2015-06-04 09:57 by srlockley
Steps To Reproduce
It appears that they are incredibly slow in most circumstances. For cylinders it seems to be related to the resolution of the step size in IntCyCyTrim. Basically for my models the code which increments the variable 'anU1' only increments it by a very small amount each time (~0.003). This is because the variable 'aMinUexp' is always a small variation of the previous value due to the step variable.

In the code there is a while loop starting at line 2368 of file IntPatch_ImpImpIntersection_4.gxx

while(anU1 <= anUl){
.....
}

The issue is that 'anU1' takes thousands of iterations before it is less than 'anUl' for simple cylinders. This can take minutes up to hours to complete depending on the size of the shape, for example semi-infinite prisms can take up to an hour to complete. I have raised the query on the OCC main forum and been requested to re-raise it here.Attached are a pair of cylinders produced by BRepTools::Write that reproduce the problem. If the Cut operation of c from b is executed on 6.5.4 in draw.exe everything runs as expected and quickly. On 6.9.0 the performance is very slow and instead of returning the result shape, the original body is returned, no cut is performed.

I have found that with semi-infinite prisms that have non planar surfaces the same problem occurs but can be reduced significantly by making the prism finite and with a much smaller extrusion. It leads me to believe that the step that is calculated for iterating around the curve of the solid is small compared to the size of the extrusion and causes many executions. This is a wild guess though.

Hope this is enough information and someone can help, I have tried to debug the code and find the reason but it is a little beyond my understanding, I know from performance analysis the time is consumed by the single function CylCylComputeParameters however i think this is simply because it is being called many, many times.


Copyright © 2000 - 2020 MantisBT Team
Powered by Mantis Bugtracker