Mobius geometry is easier to create in Dynamo vs, Revit
Have there been new geometries possible since the introduction of Python 3.x using Dynamo?
Show me pls.
I’m very interested in the Free form capabilities @Karam_Baki exposed on LinkedIn and his youtube channel
Hey @Marcel_Rijsmus well I haven’t personally yet dive into Python 3.x capabilities, but in theory every math problem can be translated into either a design script, python or C# code at the end.
A library that generates many standard well-known complex shapes is indeed a nice way to represent the geometrical computational capabilities in Dynamo and utilize them for different projects.
I would suggest going with C# to easier maintainability and upgradability across future software releases.
@Vikram_Subbaiah has some pretty creative mind as far as I remember for working with math and design script, he might provide some insights for this endeavor as well.
Well, let me add some interesting observation here, based on previous encounters with complex geometry, I realized that in practice, an optimized Python code is even sometimes faster than the C# one, especially if everything is squashed inside the same python script node.
However, C# helps the coder to be organized, handles all nulls and empty lists, along with all edge-cases. and the overall results is a more stable and robust node that can be mixed with others to create another creative workflow, (Which is the whole idea behind visual scripting)
So, if we’re comparing raw speed, the difference is practically by calling the function in Dynamo, it is clear that calling C# nodes is faster, initially, but once they are called, the “Geometry” processing speed is almost the same.
Recently I was on a project that needed me to build a planar hill for a list of non-planar points. My first POC was with nodes and a bit of Design Script as that is fastest to sketch code with. It worked to a point, but got too slow for my needs when the data set reached a certain size. Call it speed 100.
My next attempt was as a design script function built from the same previous nodes. It was faster, but not fast enough. Call it speed 80.
Next I moved to Python and go faster still. The first pass was say speed 50 and worked with larger data sets. I made a lot of structural changes to make it more ‘Python native’, and to it to say 35 on subsequent runs. First run time was closer to 50, but that is another conversation.
Next I moved to C# as a zero touch node and found that I was actually at slower than the Python, approaching the design script speed around 70. Everyone always said C# should be faster! Why am I going in reverse!!!
Well in a review with a colleague it wound up being how I handled my loops; the base structure was still closer to how I handled my Python - which is likely my 2nd strongest language, with my C# being a good way behind it. After a refactoring I got down to 20, and could work with sets so large the the limiting factor was actually Dynamo’s point generation not my ability to generate the hull.
So the lesson about speed is this: The fastest performing node isn’t determined by the language you write the code in, but in how you use the language you select.
However C# will usually have an advantage in being closer to the route libraries used (Revit, Dynam, Civil 3D, pretty much all the tools we use daily are effectively in the same language instead of translations), and in that the engine is started when. You launch Dynamo, while Python’s engine has to be started once per node placement (adding time to the first run as noted above).
Are you 2 gurus able to supply some sort of reading to learn how to best optimize python code? ( i suppose c# as well) but i am bias to my current goals.
Ignoring performance and speed concerns/advantages for the time being, if there are features that enable something fresh I’d be interested too
Thanks for the kind mention @Karam_Baki
For design related scripting, I will probably continue to use Design Script, for as long as it is available. Probably biased as I haven’t even considered Python for the purpose.
If @Marcel_Rijsmus posts examples (as he’s done so well in the past) we could probably explore different approaches.