[Dynamo Logic] Foundations of Generative Design: Why Your "Overlap" Check is Failing
Mastering Geometric Placement, Rotation, and Tolerance for Automated Layouts
Here is the clean English blog post without citation marks, ready for immediate copy-pasting.
[Dynamo Logic] Foundations of Generative Design: Why Your "Overlap" Check is Failing
Subtitle: Mastering Geometric Placement, Rotation, and Tolerance for Automated Layouts
Introduction: Before the Algorithm, Comes the Logic Most spaces and facilities in architectural design can be initially represented as simple rectangles. While the end goal is complex generative design (like optimizing a water treatment facility), the foundation lies in mastering the fundamental techniques of arranging these basic forms.
In this post, we explore the "Physics" of Generative Design in Dynamo: how to move objects, how to rotate them, and most importantly, how to teach a computer to "see" overlaps the way a human does.
1. The Illusion of Movement: Vectors & Data Flow In Dynamo, moving an object isn't dragging it; it's a mathematical translation defined by a Vector.
The Grid: We start by creating a grid of points to define potential target locations.
The Translation: Using
Vector.ByTwoPoints, we define a direction from the origin to a specific point on the grid.The Reality: When you move a slider to change the position, the object isn't actually moving. The graph is re-calculating and generating a new rectangle at the new coordinates. This understanding of data flow is critical for building complex loops later.
2. The "Ghost" Problem: Lines vs. Surfaces A common pitfall in automated layout is collision detection. If you place a point inside a Rectangle and check for intersection, Dynamo might say "False." Why?
Linear Geometry: A standard Rectangle in Dynamo is defined by its boundary lines, not its area. From a computational standpoint, a point inside the boundary does not intersect the lines themselves.
The Fix: You must convert the Rectangle into a Surface using the
Curve.Patchnode. A Surface is planar, allowingGeometry.DoesIntersectto correctly identify if a point (or another object) is occupying that space.
3. Defining "Adjacent": The Conflict of Precision When placing a second rectangle (REC2) next to the first (REC1), we often rotate it to find the best fit.
The Human View: We see two rectangles touching at the corners and think, "Perfect, they are adjacent."
The Computer View: Dynamo calculates a mathematically perfect intersection. If they share even a single edge or corner point,
Geometry.DoesIntersectreturns True (Collision).The Solution (Tolerance): To filter for valid adjacencies without invalid overlaps, we apply a small Offset to "shrink" the testing geometry. This forces the computer to ignore touching edges and only flag true, significant collisions.
4. The Power of Combinatorics Why do we need code for this? If we test placing REC2 at the start, midpoint, and end of every line of REC1, combined with multiple rotations, the number of scenarios explodes exponentially.
Example: 3 source points × 4 target lines × 3 target points = 36 scenarios for just two objects.
The Value: A computer can calculate and validate these 36 (or 36,000) scenarios in a fraction of a second, exploring a design space impossible for humans to cover manually.
Conclusion: Building the Engine By mastering these three steps—Surface conversion for accurate detection, boolean filtering for availability, and tolerance offsets for valid adjacency—we build the engine for a robust Generative Design system. In the next post, we will chain this logic to automate the layout of complex, multi-object facilities.
댓글
댓글 쓰기