Hi All,
@DanielPiker
I’m working on a reciprocal framework setup and using Kangaroo 2 for the optimization process. My approach is based on your Reciprocal K2 script and the LineLine goal from this thread here:
However, I’m encountering an issue: sometimes, some beams “hang” from their counterparts instead of resting on top of them. This is problematic since the structure is intended to be fabricated and assembled.
I would like to know if it is possible to create a custom goal—building on your LineAt-to-LineAt goal—that incorporates a z-direction constraint (or perpendicular to the base surface). My idea is to evaluate the distance between the two line at their closest parameters, and if the delta in the direction normal to the surface is negative (or the inverse), then adjust the move vectors accordingly to enforce that one beam rests on top of the other.
I have attached a screenshot of the current problem and an image of the desired goal. Any advice on how you would go about formulating a goal to ensure the over-under orientation, or your opinion if its even a sensible goal in the first place would be greatly appreciated.
Also in your LineLine implementation, i attempted to use the GrabGoal Component to ‘manually’ solve those problems. Is it normal that dragging doesn’t work - only cliicking near the goal object in hopes of catching the right one?
Thanks in advance!
Best regards,
Lorin
Hi Lorin,
The over/under arrangement of crossings around each triangle is tied to the curvature of the overall shape. Enforcing an arrangement where each one lies on top of the next in a clockwise orientation at every triangle would only allow for a dome-like form with positive Gaussian curvature.
The variation of spacing means this dome doesn’t have to be purely spherical, but it cannot have barrel or saddle like regions with zero or negative Gaussian curvature. To allow these shapes we need to allow some triangles where the over/under arrangement varies.
In the definitions I posted in that thread, by rotating edges about the mesh normal at the midpoint of the edge to generate the approximate geometry before relaxation, we naturally get the appropriate arrangements of over/under to suit the curvature.
If you know you want to keep it all dome-like then yes, a goal to control the orientation of the crossings would be possible.
As for the Grab behaviour. You can only grab points which exist as particles in the simulation, which here will be the ends of the rods. If you are having trouble picking points you might want to adjust the range to suit the scale of your geometry.
If instead you were talking about dragging in the sense of window selection of multiple points - this is not supported with Grab, only individual points.
Dear Daniel,
Thank you very much for your input - it has already clarified things a lot.
For testing purposes, I’m trying to create a custom goal that controls the orientation of the crossings. My idea is to evaluate the closest points between two lines (L1 and L2) and then, based on their vertical (Z‑coordinate) difference, enforce a minimum gap so that L1 always lies above L2.
following is the pseudocode for how I would structure the approach.
// Compute sc, tc for L1 and L2
P_A = L1.PointAt(sc)
P_B = L2.PointAt(tc)
// Evaluate vertical difference
deltaZ = P_A.Z - P_B.Z
// Check if L1 is above L2 by at least target vertical gap
if deltaZ < T:
verticalCorrection = T - deltaZ
else:
verticalCorrection = 0
// horizontal push for separation
separationVec = (P_A - P_B)
horizontalPush = (DesiredSeparation - Length(separationVec))
Normalize(separationVec)
Push = separationVec * horizontalPush
// Define vertical push (only in Z direction)
verticalPush = Vector(0, 0, verticalCorrection * Strength)
// Distribute the moves along L1 and L2 based on sc and tc:
Move[0] = (1 - sc) * -Push
Move[1] = sc * -Push
Move[2] = (1 - tc) * (Push + verticalPush)
Move[3] = tc * (Push + verticalPush)
Could you assertain if this more or less captures the intended behavior?
Thank you for your time!
Best,
Lorin