Hi,
unlike other components, Bounding box seems to work a bit differently concerning list inputs.
Inputting 5 objects, and 5 planes, does not give me 5 boxes, but 25…?
Grafting solves it of course, but the behavior was unexpected and differs from other components’ logic.
I’m really hesitent to call this a bug - propably this is intentional. But, why?
Bbox list.gh (20.0 KB)
yep, thats strange! never noticed it before
I think it is because it has the per object or for all objects (in one branch) options.
In that sense when it is set to per Object it “sees” 5 objects as inputs, but is set to per object, so looks at each object individually. Since there are 5 planes, each object gets matched with each plane.
But if you graft both inputs then the input matching is clear and actually in that case whether it is set to per Object or Union does not matter.
I think the reason is just to make the component more user friendly 
usually, if you have two lists of different length, you expect the behavior as if the Longest List component was applied to both the Lists, which means the shortest of the two gets its very last item duplicated until its length matches the length of the longer one
but with Bounding Box if I plug 10 geometries and just 3 planes, in my brain it means “for each geometry give me the 3 bounding boxes oriented on my 3 different planes”, so it behaves by default as if the Geometry input was grafted
for sure it’s not standard behavior, but I really do think it saves some clicks (and probably a few lifes )
Yes, you have it set on union box, so it takes all the geometries and combines them and then matches it with the 5 planes, hence you get 5 outputs.
By making it behave differently than others…? I would disagree on this one. I stumbled upon this because it behave differently than I expected.
If I apply the same logic to a Move component - giving 3 vectors to 5 geometries - it gives me expected results. As do other Translation components…
Once recognised, the behavior is something that we can easily live with and ‘fix’. But I would not go as far as calling it user-friendly.
@wim What’s your take on this?
