Rhynamo Crashes


Thanks for all of your help, not harsh at all my freind.

The stadium in this example is pretty small (only 4k seats). That’s why we chose using it to develop the script. We are usually dealing with much larger seat counts, easily over 10-20k, in some cases around 50k. I would imagine that I would need to run the script by section or sections in that case.

I generally write a script several times before office-roll out. The redundancy is a result of this being a “draft” version, as I am brainstorming and developing concurrently. Also, I’m still pretty new to dynamo (been using grasshopper for several years) and this is among my first real dynamo scripts. Your admonishments are well received.

I will try running this tomorrow morning and let you know how it works.

Since it seemed that most of the issue is with dynamo/revit holding on to resources, and with the Rhynamo node, do you think that writing just the Rhynamo portion in python would solve the crashing issue? That’s something that I was planning to attempt, but I don’t know how to add the proper references in the python node, and therefore, I can’t call any Rhynamo methods in python. Looks like in design script you dont have to add any references.


50,000 is big. I kinda want a sample file to see if it would work. I did some geometry generation and manipulations on something like 40,000 stair treads before and that turned out ok and disasterous at the same time.

Some questions:

  1. Is there any reason behind the shape you extruded? Could a plane or a single line a work? (simplify geometry)?

  2. I can tell you want to check that all seats see ‘center court’, but do you want to check other points or what percent of the overall field they can see as well? If so do you have a method for this yet?

  3. How long is an acceptable runtime for an analysis like this? Would you be willing to let something run for over an hour to check all 50,000 seats against center court and both basketball keys, and percent of the total court?

  4. Would you consider writing the eyepoints to a parameter contained in the seat (most ideal method ) or a separate CSV (less ideal but better than the current method) to allow for faster access?

  5. Are you married to a Rhino to Navisworks workflow or would you be willing to switch to another method of clash testing?


1 and 2. Simply put, the extruded shape is the outline of the playing surface - more specifically, it is the minimum sightline boundary. This script does not simply check for center court/field/stage etc. (That could be achieved with a single line) It checks that a spectator can view the ENTIRE event (end to end) and flags any item that obstructs the view from any direction. This is the purpose of using a volume in lieu of a line. However, surfaces could possibly work, but presents an issue - if an item exists fully inside of the perimeter, it won’t be flagged because it doesn’t touch the surface, even though it is an obstruction. In that case I have to rely on host items, but that complicates the algorithm significantly - if item is obstruction then remove all hosted items based on their proximity to host item, for example.
Later, this logic will be adapted to check views to other items as well (scoreboard, exit signs, windows, etc).

  1. hour or two is fine

  2. yes, that was the original plan. Build as much info into the seat as possible. However, since the seat family has an embedded point (its location), I didn’t see the need to add a point into the family.

  3. I’m open to whatever works for geometry creation. I might even port to grasshopper, which I know runs much faster for this type of thing. I’m just worried about translation of identification info. Clash detection: Navisworks is first choice since we have licenses and experience with it.


Ok, I tried the script that you cleaned up. Unfortunately, I still got a crash. I think that I am going to try to convert to IFC. It seems somewhat complicated but I will give it a shot. If I can make it work I will share with the community.


To anyone following this issue, the posted script has proved the most reliable for exporting to Navisworks. The python node does all of the heavy lifting (while reducing the required resources). In short, I am accessing the Revit API directly in order to create DirectShapes from Dynamo solids (not using DSCoreNodes). I have been running the script repeatedly for several days with no crash.

BareFile.rvt (1.3 MB)
Collision Detection3.dyn (90.5 KB)

import clr
from Autodesk.DesignScript.Geometry import *

from Autodesk.Revit.DB import *

from RevitServices.Persistence import DocumentManager
from RevitServices.Transactions import TransactionManager

import Revit

from System.Collections.Generic import List
#The inputs to this node will be stored as a list in the IN variables.
dataEnteringNode = IN

doc = DocumentManager.Instance.CurrentDBDocument

solid = IN[0]
category = UnwrapElement(IN[1])
names = IN[2]
catId = category.Id
dsId = []


for i in range(len(solid)):
	ds = DirectShape.CreateElement(doc, catId)
	ds.Name = names[i]


fileLoc = IN[3]
fileName = IN[4]

navOp = NavisworksExportOptions()
col1 = List[ElementId](dsId)
navOp.ExportScope = navOp.ExportScope.SelectedElements
navOp.ExportRoomGeometry = False
doc.Export(fileLoc, fileName, navOp)





#Assign your output to the OUT variable.
OUT = 0

Thanks to all, @JacobSmall, @Giovanni_Brogiolo , and @Konrad_K_Sobon for helping me to address this issue.