I am tired of relying on packages to do my dirty work (they break too many times with updates for my liking) and I am trying to create python nodes to recreate many of my tried and true favorites from my go to packages like clockwork.
One that is giving me trouble, clockwork’s passthrough node.
How does this work? What is the code behind the passthrough node?
For example, I have a bit of a dynamo graph that needs to delete existing elements before the next portion of the graph goes and recreates it. Currently, I put the deletion portion of the graph into a passthrough node and it works well to delete and then add.
I can’t quite wrap my head around how to do the passthrough node with python. Do I need to start and end a transaction somehow? Any help would be appreciated.
There’s nothing fancy behind the node, no python required even.
You can do it in a DesignScript code block by doing something like [data,waitFor][0]. This is making a list out of the data you want, and the thing you’re waiting for, then only sending the first index of that list (i.e only the ‘data’ and not the ‘waitFor’).
You could just leave the DesignScript as is in the graph, or make a custom node to contain it.
I guess you could use similar logic to build Python within a custom node expecting 2 inputs but only outputting one.
They’ll break just as often with straight Python, and you’ll have to fox it in every graph instead of getting the right version of the package for your Revit version. Many think they’re making things better for themselves and make it work today, but wind up spending two to four times as much effort when the next build comes out.
Clockwork, Archi-Lab, Rhythm, and Genius Loci are no brainer installations IMO.
Let me expand. Recently I had the clockwork element.location node stop working for a client. I didn’t spend much time digging into why it would not work, but I had a client yelling at me and I had to provide a fix quickly. All I had the node doing was retrieving node endpoints and curves from given structural framing elements. A bit of python code as compared to trying to troubleshoot the clients clockwork install trouble (thinking IT issues, versioning issue, etc.) was well worth the effort.
For me, spending the 2x-4x the time is worth it to ensure the client does not have to worry about package versioning and any potential interactions with the ever elusive IT department.
Plus it helps me understand what’s happening behind the hood a bit more.
looking for end points and curves mostly, here was the python code I put together.
# Load the Python Standard and DesignScript Libraries
import sys
import clr
clr.AddReference('ProtoGeometry')
from Autodesk.DesignScript.Geometry import *
import Autodesk.DesignScript.Geometry as DS
# The inputs to this node will be stored as a list in the IN variables.
members = UnwrapElement(IN[0])
curves = []
endPoints = []
# Place your code below this line
for member in members:
curve = member.Location.Curve
EP1 = curve.GetEndPoint(0)
EP2 = curve.GetEndPoint(1)
DS1 = DS.Point.ByCoordinates(EP1.X, EP1.Y, EP1.Z)
DS2 = DS.Point.ByCoordinates(EP2.X, EP2.Y, EP2.Z)
points = [DS1, DS2] # Convert Revit points to DesignScript points
endPoints.append(points)
curves.append(Line.ByStartPointEndPoint(DS1, DS2))
# Assign your output to the OUT variable.
OUT = curves, endPoints
Fairly sure element.curve should work on beams, and end points are available from there.
If reducing packages is the goal I tend not to recommend just extracting Python in all cases. Location+ is an example of a node which provides a lot of flexibility, but when the input element is known you can get the geometry in most cases using the dedicated geometry nodes/locations for that type of element.
Unless you get good IT support or something like Orkestra I’m unsure I’d call packages a no-brainer (or Dynamo at scale for that matter). Video on the channel in 2 weeks will discuss this in depth if anyone is keen to see my thoughts/take (it wont be as basic as ‘just use pyRevit’ for those worried about that…).
