In this example the Curve.SolidIntersection fails for all curves when the curves are sent as a single list but when I send each curve as a separate list only some of them fail. The second method is considerably slower considering there might be several thousand curves to check against.
Bimorph Cuve Solid Intersect.dyn (145.3 KB)
Any thoughts as to why it works one way but not the other? I understood that issues here were the fault o the solid in which case I would have expected none of this work. The same methodology I’m trying here doesn’t work on other solid/line combinations so I’m looking at potentially 3 different processes to get the results I’m looking for… each slower than the last! lol
Hi @Greg_McDowell
If I recall correctly the reason why the node might work as curve per list vs a list of curves is a limitation with Dynamo’s exception handling when using lacing; if the first list or instance is null then the entire lacing output fails/is null. If the first is not null but other instances are null, the node will work.
I suspect this is why you’re seeing inconsistent results. Therefore the solution is: make sure the first input (into any node requiring lacing) is valid.
Interesting.
What qualifies for a valid curve for the Curve.SolidIntersection node? I imagine it’s dependent on the solid to a large degree.
Just make sure the first object (object being anything: list, curve, view etc) is not null and you want to lace. If the curves in your lists are valid then this might be another issue.
Copy. I’ll double check but I’m pretty sure there are no nulls in the curve list.
Share a minimal reproducible case if you can.
DYN is in the first post.
HI Greg I cant run your script. If you can remove all dependencies on other 3rd party packages and Generative Design so it runs / shows the problem with only BimorphNodes I’ll be able to debug. I don’t have time to trackdown and install thrid party packages and I don’t know what the output from the Data.Remember nodes should be.
The beauty of these nodes is that they retain the previous data in the .DYN. The data (in this case geometry) is saved directly into the .DYN itself (you can look into the serialization method if you open it as a text document) for anyone to use it as they might desire.
As such, the output should be automatic unless you have modified Revit/Dynamo/Generative Design.
1 Like
Thanks @jacob.small I’m not up to speed with any of the Dynamo gen design nodes.
@Greg_McDowell the error is caused by Revits short curve tolerance. Its fixed in V5.1.3.
1 Like
Any time. They can be super useful for debugging issues as the necessary Dynamo native content can be readily transferred between users and systems without having to set up a 3rd party tool or get into more complex graphs. I have even used them for simplifying bug reports to just the node which fails. If you find them useful or see ways they could be better let me know and I can pass on that feedback. 
1 Like
Big fan of the Data.Remember node.
If I had one wish for then it would be that they retain the information in a Windows copy/paste (or have some other way to get them to a new graph).
2 Likes
I seldom use Dynamo anymore. If i do use it its almost always the Select Model Element + Python node for Revit API purposes!
Ah, well Revit Automation certainly has value.
