Mesh Clash component in Grasshopper does not behave well when there are null values included in the input Mesh Lists. Here is a simple script to reproduce. I insert a null value (Wombat plugin in this one to generate a null, use whatever suits you) and doing this does not give any warning or errors, and if I inspect the outcome clash points, the pairing is mixed up due to the null.
For example the Meshes in the screenshot are not clashing. Yet, they are presented as if they were.
regardless, it looks like the component cleans the inputs as if Clean Tree was there (indeed how would you define if a clash exists between a Mesh and a Null?)
outputs for case 1 (10 items + a Null, not as last item to not eventually fake the Bounds) and case 2 (10 items with no Nulls) are identical:
Thanks for pointing that out, it wasn’t my strongest day.
Nonetheless, the problem remains. Nulls in the input mesh lists can stay hidden to the user and there is no warning or anything pointing out that the input mesh lists and output index lists do not match.
Here is a third iteration of the script without the Wombat plugin, so it opens up in vanilla GH. For example the clash index 27 outputs two meshes that are clearly not colliding.
I think you are right in that the Mesh Clash does something similar to Clean Tree under the hood. And of course using Clean Tree before passing the values to Mesh Clash solves this issue, but it feels un-GH-like since there is no indicator of something going “wrong” or unexpected. A simple warning on the component would be way better. Something like: “Please note that the order of indices and the input meshes is not correct due to some null values in the input data”.
I confirm as I open your last definition what I see on my screen is exactly like your screenshot, same result
with the current behavior, I believe it would be better if the component would just turn red and not work at all if a Null is present in any input, like many components do (I guess that would also probably require a relatively small coding on the McNeel-side because looks like the component is already coded in such a way to just clean Nulls anyway @wim )
the usual problem with this kind of changes, where a component that used to work in a certain way, suddenly starts working in a tiny different way, is that they might have HUGE -devastating- impact on existing definitions… and that is something that is usually evaluated very carefully
so maybe it should just turn orange and message out something like you propose
on a side note, just keep in mind Nulls are like the jolly joker of items
as I open your last definition what I see on my screen is exactly like your screenshot, same result
