Hi everyone,
I’d like to suggest a potential enhancement for the Tekla Object Pipeline component: a GetObjectsByBoundingBox method.
Not sure if it’s technically possible, but having a BoundingBox input to limit the search area could help a lot with performance on large models by avoiding full model queries.
Curious if this could be considered.
Thanks!
I like this idea, I guess it can be done already but you have to get all objects and check if they are inside the box.
Hi, good suggestion! This would be a lot quicker indeed.
Only thing I need to sort out is how to handle filtering, since there’s no GetFilteredObjectsByBoundingBox method.
If the box contains a lot of objects it’s excessively slow to test if they match the filter one by one, and it’s faster to just fetch the filtered objects from the entire model at once and then compare those against the objects in the box. The cutoff seems to be 5-10 % of the model objects but I don’t think there’s a way to know what to expect beforehand and chose the faster method. But maybe you normally would expect just a few objects within the search box?
Cheers,
-b
For my workflow, I only really need to get all custom parts within a bounding box — with just a filter by type (like custom parts). That alone would already be super helpful and a big performance win on large models. Any further filtering (like by name) I can easily handle later in the Grasshopper script.
Thanks!
In my current workflow, I’m using the component like this:
But what I imagine is something like this, where I just get all CustomParts in a bounding box:
Usually, I expect only a few parts in the bounding box, so even just having a type filter like CustomPart would be more than enough. That way I could skip the full model query and handle any further filtering (like name or attributes) in later steps.
Do you think this approach would actually perform faster?
Hi, here’s an update with an added Box input. Give it a go and see what kind of results you get:
Ok that’s great, checking the object type like CUSTOM_PART isn’t costing much. It’s just applying a filter that can become slow if there are lots of objects in the bounding box. If there’s only a handful of objects within the bounding box it should be at least an order of magnitude faster for decent sized models.
-b
That’s exactly what I needed—just ran a first test and it works amazingly well. Huge thanks for this!
Nice one mate, I’ll try it out now.
Hi Sebastian,
The new Box input—total game-changer for me! Could the component return an empty list when Box is null instead of scanning the whole model? It would avoid accidental full-model queries.
Thanks again!
I don’t agree, no box should definitely scan the entire model. Would be pretty silly having to generate a giant box every time you want to run the geo pipline on the entire model.
The box should just be a way of restricting, exactly like it is now.
Hi Oscar,
Just to clarify—my suggestion applies only to the explicit null value.
I’m using the Tekla Object Pipeline in a Grasshopper component, and I don’t have a way to dispatch/disable the pipeline. In that case I’d prefer the component to do nothing, rather than fall back to scanning the entire model.
When there’s no input connected, it should keep behaving exactly as it does now.
Thanks for looking into it!
Hi,
Yes, ok. I see what you mean now, it still runs even though all inputs are Empty or Null. Yeah I would be nice it if would not run or if you could have a Run toggle input?
As a workaround I insert a dummy bounding box far from (0, 0, 0) instead of null; while this keeps things running, it’s not the most elegant solution, which is why I’m suggesting native null handling. Or even better Run toggle 
Hi, good points once again.
Here’s a new update with a Run input.
It’ll remember the collected objects in the off state. This allows you to trigger it with a button which I think is nice. However I’m not sure if this actually messes with your use case - should the output rather be empty if Run is set to false?
Alternatively use null inputs - now if there are invalid or null inputs for the filter, type or box the component won’t return any objects. If there’s no input (= empty input), all objects (that match the other inputs) are returned, as before.
Great work Seb!
