Is it possible to SetIntersection for lists of Curves? It doesn’t seem to be doing anything.
My solution so far, and it’s pretty ghetto, is to convert the list of curves into strings, compare them to find the indices of common results, and extract the lines based on these. For what I’m doing it should work but I can’t say that with 100% certainty.
Can you share your graph as a screenshot please?
Yep, should’ve known better than to post without example.
I think part of the problem is that, while the lines have the same start and end points, they were created in different parts of the graph. Or rather, one set of lines was created, and then intersected with a surface to create a new set of lines. I only want the lines that fall completely within the surface, not those that are cut into multiple smaller segments.
I think Dynamo sees the lines as if they each have a unique ID and so are therefore not the same even if they are geometrically. Running them through an AlmostEqualTo node isn’t a great option considering there are several thousand lines in each set that need to be compared against each other. I did that once and ended up with more than 12 million in the list by the time the cross lacing is done. Took some time, as you can imagine.
Any thoughts on this? The convert to strings approach works but seems to take awhile on large data sets. Hoping a direct compare would be faster.
I’m somewhat lost by what your end goal is here. can you share a bigger picture?
Sure. Here’s a breakout of the relevant portion of the graph.
Take a room outline, find its corners, and connect all points with lines.
Then intersect these lines with a surface created by the points (using surface by patch doesn’t always return correct results - bypoints seems to be more reliable).
And, finally, get the intersection of the two lists of lines to find only the lines that fall completely within the room!
The graph;
and the DYN; SetIntersection for Curves.dyn (14.8 KB)
I found a way to manage the intersection of the strings and find the indices in Python which made a yuge difference in speed. There are easily 80,000 to 100,000 lines needing to be compared at times!
@Greg_McDowell #sneakpeak Curve.IntersectAll is coming in BimorphNodes v2.1. It will be optimised so should be functional even with large lists of curves/lots of intersections and not suffer from the performance issues that OOTB Geometry.IntersectAll suffers.
The first example is in real-time so you can get an idea of performance. The second example which yields 11K intersections is sped up and took about 40 seconds. ETA Oct 2017:
4 Likes
@Greg_McDowell , if you don’t mind me asking, why would you need to do this intensive comparison in the first place? What is your overall goal here?
1 Like
Looking to do a shortestvwalk from every corner of offset room boundaries to determine longest path for egress.
With a convex room with no holes (or furniture which will make a LOT of holes) it’s trivial. But as soon as you introduce some holes in the boundary or have a concave space, or both, you’ve got some work to do!
It’s not as clean as a straight geometry check but by populating each line with points based on user defined parameter criteria, and checking if all the points intersect the face gives a remarkably fast (for the number of checks) result. It’s prone to error, however, since the number of points can impact the outcome but it’s a trade-off until @Thomas_Mahon finishes up the new node and I get it plugged in.
@Greg_McDowell I’m not sure I understand the broader goal, however see if this helps …
ConnectCorners.dyn (19.4 KB)
ConnectCorners.rvt (1.3 MB)
Thanks for that.
I used a similar method using the Geometry.Intersect node with Surfaces but it was wicked slow with close to 64,000 lines and 114 surfaces. I’ll try this approach and see what difference it makes.
The larger goal is to create a path finder to determine the longest/shortest path to an exit. I saw an example of this using a delaunay triangulation of the underlying surfaces of the main circulation space. I’m looking to take the idea further by going into the rooms, through doors, and to straighten up the lines (the result from the delaunay approach has lots of “jaggies”). I straight line from every corner, to every other corner, and door, gives just the right amount of information to a shortest walk node.
I’ve been discussing this with @jacob.small who suggested going around the outside of the room rather than through the middle with diagonal lines which should work as well but, for now, I’m headed down the triangulated approach.
At this point, it’s really just a time issue. It’s quite slow considering how many lines, surfaces, and polygons we’re dealing with but there isn’t a way that I can think of to globally limit the analysis.
I’ll give this approach a shot and see how it works. I’ll report back!
Yeah, it’s what I figured. That Intersect node is slow when you’ve got this many elements. The point approach almost works but there are times when a line that should be kicked out isn’t because the spacing of the points doesn’t have a point land outside the surface. I can add more points but then the run times are ridiculous.
The polygon containment test actually takes a lot longer than intersect.
Figuring out an alternative to the containment test might help, to a limited extent.
Not a Polygon.ContainmentTest test but a Geometry.DoesIntersect point with surface. Considerably faster… and yet still too slow and inaccurate even with 10 points per line. The last run on a pretty good size project took 30 minutes.
I think I said this before here or somewhere else, but if you can click run before going into a meeting, lunch, or a coffee run, and have the right result waiting for you when you get back, that’s a win. Heck in theory you can open Revit on another system with a unique user name and do the work of two people.
Not saying to give up on making it faster. It will get faster and better in time. But holycrap this is one of my favorite scripts I’ve seen on the forum (did I mention I hate doing life safety plans in Revit yet?).
I still like orthogonal lines though. 
with the new path of travel they heard you crying ;p
1 Like