i want to look after some intersections and want to get a uniform list.
but somehow geometry.intersect gives me for some of the 4 planes multiple surfaces in the last entry?
I think it have something to do with shortest, longest or crossproduct in lists levels… i´ve tried some of them but still don´t know how to solve this…
If you are wanting to compare each solid to each plane, then in your Geometry.Intersect node, set the lacing to longest and the level of the “other” input to @L2.
Lacing and list levels are separate entities. You should be able to get by with just list levels in most cases.
Your current setup has the planes @L1, meaning that each plane in that list will be treated as an individual input with the rest of the solid values in geometry. Each sublist @L3 in your output represents a plane being intersected with the list of solids. The resultant intersection (@L2) is a list since two objects can intersect in multiple places. It just means that Plane[3] and Solid[9] intersect at two places resulting in two surfaces. This is all as expected.
If you’re sure that each plane only intersects a single solid once then that’s a separate issue that we’ll have to look into.
Your suggestion does work, it’s just redundant. The y input is already a L2 list so using @L2 there would be unnecessary. However, the list level plus the lacing forces the list structure. The same could be done with just @L1 or just cross-product lacing.
That’s weird. In my example, I had to set the lacing to longest and the level to @L2 just to get the results as shown. With lacing longest and the level set to @L1 yielded the same results as only setting the lacing longest. But yeah, setting to cross product without any level settings, does yield the same results as shown.
That goes back to my first statement of lacing and list levels doing different things. List levels is kind of like list comprehension. It tells the node to treat a specific list level (sublist structure) like it’s the input being passed to the node and to iterate each list or item at that level individually.
In your example, the + node is already going to iterate over each item in the inputs. By default (auto) it’s going to match lengths, same as shortest lacing. Longest lacing is going to continue iterating with the last value in the shortest list (to match the longest). Using @L1 with longest (or shortest) lacing won’t change anything since the node is already iterating through each item (@L1). Using auto (no) lacing with @L1 allows the node to treat x as a list and y as a single input, iterated for each value, with its natural comprehension.
Gotcha. It pretty much all depends on how you want the iterating to occur. My way returns (10) lists of (4) and yours returns (4) lists of (10). Good to know that though.
Thanks!
Sorry @KevSch for hijacking your post with our sidebar conversation.