Conclusions About Scripting Complex Geometry in Dynamo
Goals of the project
Several months ago I started a project in Dynamo for REVIT to see if I could create a script to dynamically generate first, truss geometry between two points; and secondly, truss geometry along an arc. It was meant to provide a foundation for further study into structural analysis and optimization at a later date. For comparison, at the same time I also coded the same truss in Mathematica 11.3 (a math-focused programming language). This strategy for comparison is common in the field of computer science to help understand the contrasting behaviour and benefits of different approaches. In the design studio, however, this type of knowledge might be more accurately characterized as digital design best practices. While there are many nuances to each approach, I sought to summarize three of the project’s conclusions below for readers.
1. Dynamo vs REVIT family
Though a proficient Dynamo programmer, I initially attacked the problem by trying to create a computational truss REVIT family. It quickly became apparent, however, that the REVIT Family Editor was deficient, especially when trying to generalize the form into any number of divisions in any number of orientations. It’s almost like the Family Editor was meant to do something entirely different, like trade grain, rather than design architecture. In any case, the complex geometry was quick to accomplish once the REVIT Family Editor was dropped in favour of moving development straight into Dynamo.
2. Mapping functions and other complex list manipulation.
As my programming skills have improved, it’s become clear how much of an obstacle my lack of a formal computer science education is. I haven’t let this stop me, however, as I imagine many in the AECOO industry are in a similar position. One can see the potential benefits computation brings to building design, but lacking the time to tie on another bachelor degree as a working professional. However, gaining insight into computer science fundamentals has a huge impact on one’s ability to code productively and deliver effective solutions.
In this project, the complex organization of points represented by the cross-bracing offers a good challenge to compare the expressiveness of each individual programming language. As points are defined along a curve and reordered, Mathematica 11.3 (and by extension other text-based languages like Python) was, in my opinion, magnitudes easier to organize than Dynamo. This takes into account the fact I choose a text-based approach in Dynamo as well (using DesignScript). Here the impactful difference to note is the availability and types of functions available in each programming language. Dynamo has strong support for geometric manipulation, but feels clumsy when executing more abstract mathematical and computational functions. This makes a big difference, for example, when pre-processing data, because this step often includes the complex cleaning and manipulation of data before it’s ready for geometric use or deeper analysis. These extra functions and computational approaches abstract away the complexity. It is possible to do complex list manipulation using only Dynamo nodes, but I’m not sure how wise such an approach would be since it would require lot of repetition with slight variations; an approach that becomes significantly harder to manage visually as the number of strings connecting nodes multiply.
3. Exporting 3D formats
The unique characteristics of a 3D format has implications for rendering and coordinating 3D models in a project. Mathematica 11.3’s geometry was exported using the OBJ file format, and Dynamo’s through FXB. Close up inspection of each show a lack of a water-tight meshes for Mathematica’s truss exports. This reveals not so much of the deficiencies of any given file format, but also the characteristics of how the underlying mesh was assembled by the programming language. In some applications water-tight meshes are an absolute necessity; other times a nice lightweight package will suffice. Much depends on the intended use; the trick is to find out way beforehand, not minutes before the deadline.
4. Bonus! Unity 2018.3 Rendering
I tacked on this step as a bonus thinking it would be an easy thing to accomplish. In the end, however, this step caused most of my delays with the project. Learning Unity as I went along, many of the problems I encountered required a substantial block of continuous free time to solve. In the end, I’m content with having learned the basic rendering and camera functions of Unity because, assuming one already has the 3D model modelled and textured, the high potential of Unity is clear. To my eye, Unity’s Camera and rendering options is more sophisticated, powerful, and cinematic compared to either REVIT’s or Sketch Up’s offerings. There’s still quite a climb in front of me to get the visual style I want out of Unity. It’s such a pliable platform that the sky’s really the limit. Examples online range from highly-stylized Japanese Anime-inspired renderings, all the way to photo-realistic real-time output.
— — — —
Blair Birdsell is a design technologist in Vancouver, B.C. Please feel free to connect up on LinkedIn. For more comparisons of digital design practices, please see the writer’s The Case of the Randomized Panel Problem, also free on Medium.com.
