Dear Author,
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
Archived discussion
Performance of BRepClass3d_SClassifier
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ó
Discussion
7 archived replies
Posts are displayed in their archived order.
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ó
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.
Another question: is there any chance that the solid classifier will become thread safe in the future?
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
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ó
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.