I am writing a script that converts closed geometry (either in components or groups) within sketchup into rhino native geometry. It works, but sometimes some geometry throws the script off, and Revit crashes.
I uploaded the offending .skp file but with an .xls extension - this forum doesn’t let me upload .skp. The file needs to be renamed .skp upon download.
How do I troubleshoot the file to find out why exactly the polysurfaces.byJoinedSurface node crashes? In general and for the future, what is the way to debug things like this in Dynamo?
I’m confused as to where is the part that transitions over to Rhino is, the posted workflow appears to be only sketchup to Dynamo and no further…
Sadly, I can’t open your sketchup file - it’s too new for my version so i’m unable to really narrow in on the problem. I can shed some light on how I isolated what may be the issue using dynamo in sandbox mode (standalone - don’t launch from within Revit). It’s not very high tech, and likely could be automated better or the results could be reviewed in another way, but it’s fairly scientific, doesn’t take much effort, and doesn’t rely too much on a skilled human to use.
I broke each segment of the graph off one step at a time to see which node caused the issue. Soon as i started to pull groups I had my first crash, so it’s not necessarily the polysurface that’s causing the issues. On second run I got past the groups and tried the polycurve, and then I crashed again. This has me thinking it’s a memory issue due to a bad sketchup element.
I set about isolating the bad sketchup by isolating the individual sections of geometry, and creating a few toggles to stop/start functions which might be causing the issue. I grouped these pieces out of order to create a HUD of sorts. The graph looked like this when I was done:
I set the graph to Auto (I like to live dangerously), and proceeded to work my way up the instance in grouping slider from element 0 to element 9 by dragging the slider slowly. I do this with my task manager on the second monitor so when it crashes I can check my recent resource usage - if my memory or CPU spike, that’s likely my issue. When running auto mode you can move pretty quickly though 10 digits. If your model was more complex I may have tested each group of 10 directly, but the data set was small enough that I didn’t have to look too hard.
So first I ran all 10 with the polysurface off, then I ran all 10 with the polysurface on (flipped the t/f and ran it down the list). Every time I finished a grouping of with and without the polysurface I saved and added another digit to the primary grouping of 10. This worked perfectly for the first grouping of 10. Task manager showed no major blips on the graph and dynamo didn’t crash. Second and third grouping of ten also had no issues. Third grouping of 10… Well that crashed as soon as I rolled the primary grouping over - meaning index 30 wasn’t easily digestible. This actually corrupted my DYN and lead me to a situation where I’d have to restart the effort as a result of not having a backup (the downfall of living dangerously). So I spent 3 minutes rebuilding the workflow, and got it to crash again on index 30, so I tried one last time without the polysurface, and got it to run (pulled index 30 right from the first list), and got a result with no geometry at all, but has 3 or 4 groups nested inside index 30. My guess is that this is the first part of the problem, so try exploding the nested groups and see if that resolves things.
