I’ve run into this case a couple of times where i want to test if all geometry elements in a list intersect with at least one other element. I can never seem to get the lacing right for multiple collections when i do it with Nodes or Design Script.
Here’s an implementation in python that seems to work
# Load the Python Standard and DesignScript Libraries
import sys
import clr
clr.AddReference('ProtoGeometry')
from Autodesk.DesignScript.Geometry import *
# The inputs to this node will be stored as a list in the IN variables.
lists = IN[0]
results=[]
trace = []
# Place your code below this line
# this snippet expects a list of lists geometry elements
# each list l represents a collection of geometry to test for self intersection
# return True if an element intersects at least one other element in the set. return False if an element intersects NO elements
for l in lists:
res = []
for e in l:
rest = list(set(l).difference({e}))
#trace.append(len(rest))
myres = []
for r in rest:
myres.append(Geometry.DoesIntersect(r,e))
#trace.append(myres)
res.append(any(myres))
results.append(res)
# Assign your output to the OUT variable.
OUT = results
also not completely sure how to optimize this because it double counts right now, and for large sets, it’s probably useful to not do that (e.g. if A[0] intersects with A[1], then i don’t need to test A[1] against A[0])
I‘m not sure I understand the type of collision testing you are trying to perform, but it looks like you have a group of objects that need to be tested for a group of other objects. Do you need to maintain the grouping of the objects in both lists to run the collision check?
If not, you could just run the collision against a completely flattened list.
Otherwise, maybe removing the chopped list, and maintaining the list order at level one will get the results you want.
If the collisions are between elements which are converted to geometry to get collision results, I would recommend using either bimorph nodes to run a collision between elements (which is much more efficient than generating the geometry and using geometric collisions.
Another alternative would be to run the collision test from the revit collaborate tab, export the html, open in excel, and remove the headers/index to simplify the imported data…and then use the element ids to find how many collisions are occurring. This is the most cumbersome way since you need to do things manually…but it will give you element ids, type names, marks, and worksets which could also be used for grouping objects and counting list lengths.
It’s a bit late where I am…so I don’t have the energy to actually build a script out to test any of these ideas.
I think i’m more curious about the structure of the list operation than the exact application to geometry. Functionally, i think this is similar to the ‘unique items’ test where each item in the list is compared against every other item in the list. Positive results on each pass remove required tests on successive iterations. I think there’s a more generic way to describe this pattern, but i don’t know the term.
i tried the chop → set difference approach because i think it deals with the self counting that happens if you input the list into both ports a comparison node on cross laced. But, i also haven’t been successful in articulating this.
the specific application for this is verifying that each selection of elements are all adjacent (only one cluster) before performing further operations on those elements. I’ll check out the bimorph nodes
Assuming you have solids or surfaces and not curves, build a polysurface or unioned solid from all surfaces EXCEPT the one you want to test, and then test the polysurface/unioned solid against the single item; if that works your selection in ‘in the chain’, and if not, it’s detached.
Note that if you’re working with Revit it would be faster to utilize the Revit API directly rather than do computationally costly geometry conversions.
