First, thanks again to Thomas for the updated package. This is going to make a graph I’ve been dealing with much faster.
I’ve got a series of curves intersecting a solid (some fully within, others partially, some completely outside) and the Curve.SolidIntersection node works well except I’ve got one solid, and one curve out of 529 that might intersect that solid, that won’t play nice. If I yank the curve it works great but I don’t see why that curve in particular is causing the problem.
Hi @Greg_McDowell you’re welcome, it’s great to hear the new nodes are alreadying having a positive impact, minus that one annoying curve!
My suspicion is it’s likely to be a hermite spline which can’t cast correctly - I hit a similar problem with the CurveFromCADLayers nodes (meaning I have the infrastructure in place to resolve this rapidly).
Can you upload an example file with the offending curve and I’ll debug?
The curve is being generated from a larger graph and is just a line between two points. I’ll see if I can reduce the graph to just this issue and send it along with a RVT file.
It’s as small as I could make it and still get the same result (though the index of the line moved).
The RVT is too big for the site so here’s a link to the zip on Dropbox. It includes the RVT that the DYN uses to create the lines, the DYN itself, and an unpublished node I’m using in the graph.
Thanks for sharing the files - I’m getting errors with the Geometry.ClosestTo nodes so I cant troubleshoot. Any chance you can simply process the lines your end, extract the start/end points to Excel and then I can simply rebuild the lines my side and select the relevant room? It will make this process much quicker and easier.
I’ve replicated the problem, however its not good news as the issue appears to be triggered by Revits awful handling of tolerances which prevents any meaningful solution other than to just ignore the exception should it be thrown.
Here you can see the problem curve and another copy I’ve made of it slight offset to the left. It works without issue:
The only solution therefore, is to catch the exception and ignore it so all the other valid curves are processed. The downside of catching it without warning the user is that they may think the node is malfunctioning if it cant output the correct intersections due to this error. The upside is any valid curves will be processed and the node will output the segments.
Yeah that’s a good idea, so an output like “failure”, and the curve is returned? What if the user wants to simply identify which curve(s) from their list is/are the problem? An alternative which may be better would be to return the indexes of any curves that fail. Thoughts?
I like that better. Much more flexible. You need the curve… grab it from the list by the index. Or you can use the index elsewhere if it’s needed. Good idea!
@Greg_McDowellBimorphNodes v2.1.3 is now available on the package manager with the new exceptions[] output for both Curve.SolidIntersection and Element.IntersectsSolid. In the example below, List.GetItemAtIndex can be used to return the curves that fail so you are able to troubleshoot without the Element.IntersectsSolid node throwing an exception:
A thing of beauty, is a joy forever. This result used to take many hours to achieve in this model. This time it took maybe 15 minutes or so with most of that time spent in determining shortest path.!
