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

Performance of BRepClass3d_SClassifier

Laszlo Kudela's picture
Forums: 

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ó

Forum supervisor's picture

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

Laszlo Kudela's picture

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ó

Forum supervisor's picture

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.

Laszlo Kudela's picture

Another question: is there any chance that the solid classifier will become thread safe in the future?

Forum supervisor's picture

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

Laszlo Kudela's picture

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ó

Forum supervisor's picture

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.

Contact us

Attention: DO NOT use this form for all kind of request for the removal of your personal data. Please follow this link for such cases.