Also the sounds of it (usually runs ok the first time, not so much the second time, etc) makes me think it’s a system resources thing. Looking over the shapes and how they were built in the environment, this wasn’t that odd to hear. Due to some overzealous geometry recreation there was something significant redundant builds in the geometry creation, used over what was required - once to make a polyline, to move it to a new location, once to duplicate it for every new location, then making these curves, then making the polylines again, then lofting, then turning the surfaces into a solid, then the solid into BPREP, then BPREP into rhino… Generally speaking if we can make a shape in one move thing will run better than if we make a shape than get a secondary shape, then get parts from the sub shape, than make a secondary shape to get new parts… And all of this geometry creation is happening in a script that basically makes an entire rhino files worth of geometry in the amount of time it took me to walk to the kitchen to wash my coffee cup. All without saving even once.
Sorry if that comes off as harsh - the script is actually really well thought out and works nicely, but it needed some love in terms of how it delt with the complexity of the graph.
When the data sets are small (ie: a section of seats), you can let it run as is and work with this method. But when they get large (ie: the entire stadium) you need to be as efficient as possible. Some tips to do that:
Use code blocks, python, or zero touch nodes to nest functions. This reduces the amount of system resources (remember the results of each run aren’t saved anywhere).
Filter your dataset as quickly and efficiently as possible. If one bool mask removes 50% of the items, and another only removes 10% of the total items, then remove the 50% first.
Keep geometry simple. As @Konrad_K_Sobon pointed out, Revit and Dynamo aren’t really efficient with resources for geometric stuff. This makes sense as Revit is really a database - you can do BM with Formit or Autocad, but Revit exists to put the I in BIM. DesignScript feels faster for geometry than Revit, but it’s still fairly taxing, so best to keep geometry as simple as possible for as long as possible. Points are better than lines, are better than curves, are better than surfaces, are better than solids, are better than meshes… If you have to think hard to perfectly draw several angles of the form, then it’s likely a difficult shape to program as well.
In any case, because I wanted to better my understanding of this type of workflow, push the limit of the tools, and the see the total scope and process, I did some reverse engineering on your graph. I removed the UI++ as I’ve had some issues with them interfering with other software outside Dynamo but in the same ecosystem. So I figured it best to leave them alone incase the Rhino authoring suffered similar troubles, but I saw no improvement after removing them.
When I was done modifying things, I ran it on every seat, closed the dyn (just the file not dynamo) and reopened it, and attempted to run it again. The first run took around 3 minutes and used up a lot of resources which never really freed up afterwards (despite closing the file). The second run took longer as my RAM was used up, but time stamps and file creation have it running in under 8 minutes. This doubled time is likely why things were crashing for you before -
there just isn’t enough power to be inefficient with this stuff, and Revit/Dynamo don’t give back the resources when they are done.
However, since the entire stadium worked quickly on the first run, I’m not sure that there is much need for consecutive runs - just do them all at once as it saves steps which saves time. One time to run the dynamo, one time to export Rhino to navisworks, one time to run the clash detection in navisworks, one time to pass data back into revit… you get the idea. If you really wanted you could port the design script into Python and use some list processing to free things up afterwards, but I’m too green with Python to do that right.
Anyway, the final graph consists of about 8 standard nodes and one code block. I did have one crash during the re-build, which felt as if it was related to the 3dm file being overwritten concurrently. Looked like the memory hadn’t cleared and the nodes feeding the write file node passed the old data and then the new data right away, causing dynamo to tell the file to re-write itself with both data sets simultaneously, which is a no-no in computer speak. To help fix this I added a timestamp to the file name so each run will have a new name.
Collision Detection_JacobSmall_EditForAllSeats.dyn (11.7 KB)
The Design Script Code:
// get the geometry for all filled regions of the given type
//generate the target surfaces from the input region
/*Create a scaling factor from the length of
the target surface and a 8.4/12 ratio*/
/*sets the origin point based on the middle of the target surface*/
/* create the target curves*/
b.GetLocation().Translate(Vector.ZAxis(), 44 / 12);
//Generate a sight vector from the target to each seat
//generate an extruced form for clash detection
//Generate seat number values
b.GetParameterValueByName("Seat Section") +
"__Row: " +
b.GetParameterValueByName("Seat Row") +
"__Seat: " +
CreateRhinoObjects.Create_RhinoColor(0, 0, 0);
)+"AllSeats - "+Timestamp+".3dm";