Hello Dynamo Community,
I’m encountering some anomalies while developing custom nodes. One particular node, intended to encapsulate polygons with a rectangle fully, operates correctly outside the custom node framework. Yet, when it’s converted into a custom node, the rectangle only encompasses part of the polygon. Oddly, upon revisiting the original node file, it works as intended but reverts to the problematic behaviour upon restarting Dynamo. I’ve attached the .dyf and .dyn files for clarity. Has anyone faced such issues?
generate_bounding_rectangle.dyn (132.6 KB)
Parking.GenerateBoundingRectangle.dyf (132.7 KB)
Another inconsistency I’ve spotted concerns the FilterByBoolMask node. The original script effectively filters polygons intersecting with a multi-surface polysurface. However, within the custom node, this only succeeds with single-surface polysurfaces.
It appears the custom node framework might have challenges with intricate geometric tasks. Any insights or experiences shared would be invaluable. Thank you.
I am using Dynamo core 2.17.1.4055
@solamour @jacob.small
Where in the .DYN is the dyf used? It seems to be unrelated or perhaps just not placed yet? In any case, when trying to build a geometry based custom node I recommend utilizing only Dynamo sandbox to get the form and trace it out into the desired output. In order to keep things robust I tend to test with a design script function that more or less does this:
def MakePoly(n)
{
return =
Polygon.ByPoints(
Vector.ByCoordinates(
Math.RandomList(n)*5+5,0,0
).Rotate(
Vector.ZAxis(),
List.Sort(Math.RandomList(n)*360)
).AsPoint()
);
};
From there you call it and generate a random polygon with N corners… Or a series thereof.
With the ability to build a random dataset on demand, we can now get into trying to reproduce the issue, which sadly I could not do.
Can you send a pic of how the tool is failing in the sandbox context? You may want to check if there are multiple definitions being loaded for this (ie: one in the package, one in the definitions folder) as the only time I have seen anything like this it was from an older version being loaded while developing an AU session.
Unrelated, but did you happen to test any other methods for generating this besides thickening a line? Asking as I have found that thickening can be problematic in some Dynamo releases. My preferred method for this involves rotating the polygons on the XY plane, pulling the bounding box, building a vector from the bounding box, using the vector to define a rectangle, rotate the rectangle by the inverse of the rotation, and moving it to the center of the bounding box.
1 Like
Hello Jacob
Thanks for this.
Sorry, I did not clarify that the .dyn file I provided is the scripting logic contained in the custom node. I assumed you would remake the custom node from the .dyn file.
I see the node works well in the Sandbox environment, so perhaps it has something to do with Dynamo - Revit connection or the fact that my Sandbox version is more recent? The end goal is to use the custom nodes primarily on Dynamo Sandbox for VIKTOR, so I will take your advice and develop the nodes there. There are no custom nodes in the definition folder.
I did not use a thickened line in this node. I will use the design script version you provided. It is more straightforward. Thanks for the help!
1 Like
Hi All
I hope this finds you well.
I’ve been developing custom nodes for my parking generator package in the Dynamo Sandbox. However, I’ve noticed some anomalies when converting scripts into custom nodes. I believe there’s an aspect of the custom node environment causing these issues. I’ve attached both a .dyf and .dyn file for your reference.
- .dyf file : This contains the problematic custom node.
- .dyn file : You’ll see the custom node highlighted in blue above the grey line. Below the grey line in the blue group, you’ll find the scripting logic contained in the custom node. The red groups display parking spots and green surface outputs. The desired geometry output is in the red group below the grey line. Issues arise when revealing the outputs from the custom node; parking spots aren’t filtered correctly, and green surfaces appear to be cut oddly. This error surfaces when multiple surfaces are input into the exclusion zone, as it works fine with just one.
The custom node is in the blue group in the red circle, as shown in the image below.
Could you advise if I might be overlooking something? I appreciate your assistance!
If there is a limitation in the custom node environment, how else can I achieve the intended result?
I appreciate the help.
Thank you.
@jacob.small @solamour @GavinCrump
Parking.GeneratePerimeterSpots.dyf (291.5 KB)
GeneratePerimeterSpots.dyn (460.1 KB)
Running an errand on my lunch, but what are the input configurations for the node, and what is the data being provided? (Data type and structure (lists) of each).
The main cause in my experience would be the expected list structure taken in by the node.
If you want to use the data structure as is, use this syntax for the input:
nameOfInput: var[]..[]
Generally I recommend against putting whole scripts inside custom nodes, as users will mistake them for quick/efficient nodes and potentially run their script into heavy operations. I’d say it’s worth exploring Python or Zero touch at this point to find more direct ways to achieve your goals, and I expect tasks like parking divisions etc. would benefit from iterative approaches (for/while loops) and the ability to catch errors/fringe cases (try/except or try/catch).
2 Likes
Hello, Gavin,
Thank you for your feedback. I’ll give the “var…” approach a try.
I haven’t delved much into C# before, it seems like a good time to explore it. I’ve used Python in areas where Dynamo’s capabilities were stretched. I will look into scripting the entire process in Python.
To provide some context, what you’re seeing is just a segment of the script performing a specific function, but I do recognize its extensive nature.
Thanks again for your insights.
Hello Gavin, the var[]..[] fixed it!!
Thank you.
1 Like
