Thu, 03/05/2015 - 13:06
Hello all,
we have an application that uses parts of OpenCASCADE to perform point membership classification (inside-outside tests) on STEP geometries. The IO test is done using BRepClass3d_SClassifier, however its performance gets extremely low especially when we have a lot of query points and very complicated geometries (for example, a lot of B-Spline surfaces). I have been digging in the sources a little bit and profiled the class, and it turns out that for every test, the most expensive call stack looks as follows:
BrepClass3d_SCLassifier::Perform -> BRepClass3d_SolidExplorer::OtherSegment -> Extrema_ExtPS::Extrema_ExtPS -> Extrema_ExtPS::Perform -> Extrema_GenExtPS::Perform->Extrema_GenExtPS::BuildGrid
When we have a lot of query points, about 80% of the time is spent in BuildGrid function (according to the profiler output). Now, I am not experienced with this part of the code, but as I understand from the sources, the function builds a parametric grid for B-Spline surfaces, and according to my profiling, most of the time is spent on evaluating the surface at given parameters.
Question: is it possible/is it already planned that the result of "BuildGrid" will not be thrown away? I see that that in the function itself there is a check if the grid was already built, and if yes, just returns that. But if we use it through the other pipeline, basically for every inside-outside query, this grid has to be rebuilt.
Is it the intended behavior, or a potential feature request for the next release?
Sorry if the question was too long. I hope it makes sense.
László
Thu, 03/05/2015 - 14:19
Dear Laszlo,
If the specified problem problem is urgent (or critical) for you, you may contact us via the Contact Form http://www.opencascade.org/about/contacts/.
We will try to find a solution acceptable for you (either to optimize OCCT code, or to create a dedicated tool).
Best regards
FSR
Thu, 03/05/2015 - 15:46
Dear FSR,
many thanks for you answer! Indeed, it is a critical point, therefore I decided to fix it myself. In the constructor of BRepClass3d_SolidExplorer I create an instance of the Extrema_ExtPS class for every face of the geometry. Then, these instances are stored in a map where the key to each instance is the TopoDS_TShape underlying for the face. In BRepClass3d_SolidExplorer::OtherSegment , I just find in this map the Extrema_ExtPS that belongs to the given face, and call Perform(queryPoint) on that. This way, the grid is not thrown away. I observed a speed up of 2.4 (but this is in context of our complete application). If you are interested, send me a benchmark example and I could make some more measurements.
Best regards
László
Fri, 03/06/2015 - 20:20
Dear László,
If you are interested in qualification and testing of your solution I can suggest you to make a contribution in OCCT via the Collaborative portal - http://dev.opencascade.org/index.php?q=home/get_involved.
It will allow our experts to analyze it and apply the certification procedure.
You will be able to track it via Mantis BugTracker.
Best regards
FSR.
Fri, 03/06/2015 - 20:31
Another question: is there any chance that the solid classifier will become thread safe in the future?
Fri, 03/06/2015 - 20:37
Dear László,
Yes, it have chance to be thread safe in the future.
You do hope you understand that it takes time ...
Best regards
FSR
Fri, 03/06/2015 - 21:43
Dear FSR,
yes I understand it takes time. Sorry if I seem to be unpatient, I did not mean to be rude or anything. I was just wondering if you guys are aware of the problem that the class (the method) is not thread safe in its current form.
László
Thu, 03/12/2015 - 12:10
Dear László,
Yes, for sure we know about it.
Unfortunately this task has no high priority in our current plans.
Therefore you are also welcome to develop a corresponding patch and make a contribution via the Collaborative portal - http://dev.opencascade.org/index.php?q=home/get_involved.
Best regards
FSR.