
Tue, 02/25/2025 - 13:30
Hi everyone,
I'm encountering a severe performance issue in our assembly graph generation code that uses OpenCASCADE. The function are_connected(shape1, shape2) is responsible for determining if two shapes are "connected" by computing the distance using BRepExtrema_DistShapeShape(shape1, shape2). However, for some STEP files—even some relatively small ones (around 0.5 MB)—this distance calculation can take anywhere from 5 to 10 minutes per iteration, whereas for larger files (around 5 MB) it might only take about 1 second per iteration.
The problem is significant because if I omit this distance check, the resulting graph loses many connections, leading to an incomplete or incorrect assembly graph.
Here's a simplified excerpt of the problematic part:
def are_connected(shape1, shape2):
# Compute tolerance based on bounding box dimensions
tolerance = max(get_tolerance(shape1), get_tolerance(shape2))
# This is where the delay happens on some STEP files
dist_tool = BRepExtrema_DistShapeShape(shape1, shape2)
if dist_tool.IsDone() and dist_tool.Value() <= tolerance:
return True
# Fallback to vertex check if needed
return fallback_vertex_check(shape1, shape2, tolerance)
Tue, 02/25/2025 - 15:51
Hello. Could you share please files and complete sample. What is shape1/2.
Thu, 02/27/2025 - 13:07
Hi sorry for the late reply,
This is how I get the shapes from stepfile;
then I filter the shapes with this:
and finally check the connection like this:
The problem is I am processing a big dataset and for some files BRepExtrema_DistShapeShape(shape1, shape2) this part runs forever. I tried with a timeout method and switch back to vertex based comparison as well but it did not help. I checked the dimensions, surface areas of shapes (simplify if too complex) still did not help. I am using pythonocc-core=7.8.1.1 and attached the problematic step file.