Recursive geometry split via Python appears to be hit or miss

Hi all,

This one’s got me a bit stumped. I’m trying to split a series of surfaces using planes as the cutting tool. The code I’m using is below:

curves = IN[0]
heights = IN[1]
planes = IN[2]
vec = Vector.ByCoordinates(0,0,1)
height_skipper = 0
# Place your code below this line
def loop_walls(list_IN,cutter):
	output = []
	for looper in list_IN:
	return DSCore.List.Flatten(output)

def intersect_wall_SSL(curves,heights,planes):
	walls = [] 	
	walls_intersected = []
	temp = []
	for c in range(len(curves)):
		if heights[c] != 0:

	for p in planes:
			temp = loop_walls(walls,p)
			walls = temp
			temp = []
	return walls

OUT = intersect_wall_SSL(curves,heights,planes)

The code above does two things:
a. Extrudes curves to surfaces based on values in the [height] list.
b. Recursively splits the walls using the split tool.

This code works very well for small test models (such as the sample revit projects) but on complex examples it just keeps using CPU cycles and just hangs. Occasionally it will also cause Revit to crash.

Could someone let me know what’s going wrong here ?

Thanks in advance !

It might be due to:

  1. Not disposing of unreturned ProtoGeometry elements
  2. Some memory leak with Dynamo’s Wall Splitter method
  3. Using Try Except. There are a few reasons why and where you use it, but this isn’t one of them. Plus it’s the single worst habit I’ve seen in Dynamo Python scripts. Try except should not be used for flow control plus you might actually be getting useful exceptions which may shed some light on the cause of your problems …but you are sweeping then under the carpet! Also, when the exception is caught…you destroy performance which is why you shouldn’t do it.

Some other comments:

  1. This is an iterative function, it’s not recursive.
  2. Your naming needs improvement; avoid ambiguous or meaningless naming.

Possible solution:
Make Revit API calls directly, get rid of the try except, and avoid the ProtoGeometry library like the plague and you’ll probably find all your problems are solved.

1 Like

Further to Thomas’s comments…

Thanks to John P for the link.



this is good advice - I would like to make the point that if you are trying to get work done and performance is important (hopefully the memory issues are fixed now in 2.5) - that using the api of that application will always be faster than Dynamo’s geometry wrapper. (in general… of course not ALWAYS) -

but if you are writing a library (package) you should consider using protogometry because it has the potential to work across hosts - it takes a lot of work to split code into pieces that work like this - usually requiring multiple packages - and it has a cost, but it’s possible if that’s your goal.

1 Like